devopsy.kinsta.cloud

Category: Blogs

  • KubeCon 2023: Telemetry and Data Management

    KubeCon 2023: Telemetry and Data Management

    Speaker 1: This is Techstrong TV.

    Alan Shimel: Hey everyone. We’re back here at KubeCon and it’s bustling, man. It’s a crazy big floor with a lot of people walking around, so we hope you like this. This is a little different than we usually do. Usually people can’t see the background because the cameras face this way, but we usually have sort of the typical background that you see at some of these other booths. But we wanted to give people kind of a flavor that we’re alive here.

    Tucker Callaway: We’re in the middle of it.

    Alan Shimel: We’re in the middle of it. So kind of like if you ever watch Sunday night football, they always have that. So that’s what we were shooting for. But anyway, let me introduce you to Tucker Callaway. Tucker is the CEO of a company called Mezmo. Now, some of you may have heard of, I think it was Log DNA.

    Tucker Callaway: Before. Yep.

    Alan Shimel: And they pivoted. Was it about four years ago?

    Tucker Callaway: About two years ago now.

    Alan Shimel: Two years ago.

    Tucker Callaway: I’ve been here for four, but big change was two years ago, renamed.

    Alan Shimel: Renamed to be Mezmo and a slightly different mission, let’s call it. And then I had a chance to catch up with Tucker at RSA last, I guess it was last April.

    Tucker Callaway: April. Yeah.

    Alan Shimel: This year it’s May. So I think it was around then last year. And for those of you who want to catch that interview, it’s actually available on Techstrong TV. If you look up RSA 2023, it’s there. But so Tucker, before we get into that, let’s back up. Mezmo. Not everyone out here. Look, not everyone out here knew Log DNA either, so don’t worry about it.

    Tucker Callaway: Fair enough. Yeah.

    Alan Shimel: Let’s start there. Let’s talk about the mission.

    Tucker Callaway: Yeah, so the mission of Mezmo is essentially to help people with their telemetry data. So we’ve found that there’s really kind of three main problems in the telemetry data space. There’s too much of telemetry data. It’s not in the right format. It’s not in the right location. So that was kind of one of our founding kind of principles of solving.

    Alan Shimel: Yeah, I think that.

    Tucker Callaway: Solving the problem.

    Alan Shimel: Those were three rock solid.

    Tucker Callaway: Hard to debate.

    Alan Shimel: Hard to debate. That’s the good way of putting that. And also, quite frankly, all three problems are like they compound each other.

    Tucker Callaway: They do.

    Alan Shimel: So it’s like you have too much data. That’s a big problem, but we have too much data that we don’t know how to categorize, so that exponentially makes that problem worse. So these are-

    Tucker Callaway: Compounding problems. No question about it.

    Alan Shimel: No doubt about it. So when we were at RSA, you felt like you were kind of on the cusp of a realization, right? You were going to help customers. Why don’t you? Well, you tell the story better than me.

    Tucker Callaway: So as we were talking about earlier, we had just launched this new product capability, the telemetry pipeline at RSA. We’ve got a lot of great customers and great experience since then. When we think about the core value of what it provides, it helps people with cost, it helps people get better insights and helps people enforce compliance. What we were surprised by though in the last couple months, is how little people actually understand of their data.

    In fact, we’ve put a lot of time and effort as an industry into getting control of our applications and getting control of our infrastructure, but we haven’t really gotten control of our telemetry data yet, and that’s like the big opportunity that we see. But with that, in order to get that value I described, people didn’t need to understand their data better. And so that was a big revelation for us.

    And we just launched our data profiling capability that helps people categorize and understand baseline, to do the schema management for their data, which is a really strong foundation for data ops principles applied to telemetry data. Then the next thing we found after we solved that problem was now that people understood their data and they were able to optimize it because they understood it. They also realized that the context and telemetry data changes rapidly. So for example, you don’t want to store all this data because you don’t need it until you need it, and then you really need it.

    Alan Shimel: I’ll take a little, they do want to store the data because people are data hoarders.

    Tucker Callaway: The data hoarder. Yeah.

    Alan Shimel: It’s when they get hit with the bill for storing all that data, they say, “Wait a second, I don’t need all this data. Not at that price.”

    Tucker Callaway: Something has to give somewhere.

    Alan Shimel: Exactly.

    Tucker Callaway: And so what we realized though was if you take the bookend of this value, we think of as understand, optimize and respond, we talked about understand and optimize the response stage was a really important one for us. So when new context comes in, the pipeline can change its behavior and change its optimizations to account for the current flow of data and the current needs. So if you’re sampling down to 20% and you see an event, you see performance, you can rehydrate, reprocess, dynamically change the responsiveness of the pipeline and get all the data to the right location for the right people, which helps address the cost problem, but also gives you the full visibility that you need.

    Alan Shimel: If one was going to do a business school case study on this, someone who’s not from this industry would say, “Hey, just the fact that you discovered that most of these organizations don’t even know how much data or what data they have would be enough to build a company around.”

    Tucker Callaway: Yeah, I’d like to think so.

    Alan Shimel: No, it’s logical. It makes sense, but it’s not, it’s the threshold. Because I think you’d hit the nail on the head here, Tucker, which is once they recognize that, now there’s a whole new vista of realization for them of, “Holy mackerel, I got all this data, now I want to start understanding it. Wow. I’m seeing stuff I never thought I’d see. Maybe I intuitively thought I had, but I got the goods now.”

    Tucker Callaway: We like to think of that as being mesmerizing, right?

    Alan Shimel: Okay, I love it. Mesmerized by Mezmo.

    Tucker Callaway: I couldn’t not take the shot, but that was just-

    Alan Shimel: Yeah, that was your shot.

    Tucker Callaway: That’s the derivative of the name.

    Alan Shimel: I feel used. I feel used.

    Tucker Callaway: I got back into it a little bit.

    Alan Shimel: So now you’re mesmerized and now like, “Oh my God, what can I do with this?” And that really becomes the business. And I guess that’s now where you are.

    Tucker Callaway: The next step for us is clearly that. Yeah, and I think there’s two plays on that, too. There’s a, “What do I do with it? Help me, tell me what to do. Give me the best practices that from all of your customers, what should I do?” And so we’ll be coming out probably later in the spring with something that actually allows you to simulate how that data might look when optimization’s applied to it so you can start to make those decisions more effectively.

    But then the second phase of that, too, is that also won’t be sufficient for certain organizations that want to look at their data as a strategic advantage. And they’re going to be looking for ways to take actions and drive more insights out of that data. And so the way we see that, we see that through recipes. We’ll give you the standard offerings, but then you have the ability to go in and edit as code and go do the things you need to do to go drive more value out of that data. If you’re ready for advanced yoga moves in the data space.

    Alan Shimel: Got it, got it, got it. My background is security.

    Tucker Callaway: Yep.

    Alan Shimel: Started a security company in 2001, and it was right when we were moving from IDS to IPS. So intrusion detection to intrusion prevention. Same thing with vulnerability management. We were moving from just finding vulnerabilities to patching, remediating, not always patching, remediating. Seemed like who wouldn’t want that? No brainer, right? Just don’t tell me I’m getting attacked. Block the thing. By the time you tell me, the attack went through. Don’t just tell me you found a vulnerability, make sure I’m not getting exploited. But a funny thing that I learned in that was a lot of people say, “Go slow here. I can’t afford, because sometimes the vulnerability or the attack or the data that you want me to act on can affect something that I consider more valuable.”

    Tucker Callaway: Yeah, fair enough.

    Alan Shimel: And I like to go slow when it comes to letting a program or an application or a product, just do things. Just give me my menu and I’ll decide what I want to do. Now, of course, that was before the world of AI and ML and a lot of the automations. And quite frankly, the speed of business was probably a little slower then. Do you see a way station where people are going to want that? Just give me best practices and I’ll decide when, how, and where I want to implement it. Or do we move right to, “Hey man, make it happen for me.”

    Tucker Callaway: I think there’s a way station, when we think about the data management, telemetry, data management in general, the word that’s the most important to us is trust, right? So it is one thing to optimize the data, but you have to trust that data is constantly being optimized and handled in the right way for all those varying needs you described.

    So I do see that the first step is a suggestion with a human in the loop. You want to hit that button still to say “go”, and then as you build trust in that data and you know that the algorithms are working, then you’ll let that go. Probably with some backstops on the side, I’m going to let it go, but I’m [inaudible 00:09:52] just in case. And then you’ll start to optimize it more and more. And I think naturally, almost like a realtime data platform, operating system will start to evolve.

    Alan Shimel: So really the key there is trust.

    Tucker Callaway: Key is trust.

    Alan Shimel: To build trust in the next. So as the CEO, how do you build that trust?

    Tucker Callaway: Well, trust is always a tough.

    Alan Shimel: I’m interested, you tell me.

    Tucker Callaway: Yeah. I think like anything else in life, you deliver trust through consistent delivery. And so that’s where I think that human in the loop step is important. It has to be sustaining. It can’t be a moment in time, it can’t be the very first implementation. It’s something that you earn over time where people can count on you or could count on the data or count on the ways that you treat data to get you to the outcome that you want to go through. So it’s really only through the delivery of outcomes to the customer that they will trust the systems and all those things.

    Alan Shimel: Makes sense?

    Tucker Callaway: Yeah.

    Alan Shimel: All right. Got to do a little housekeeping.

    Tucker Callaway: Okay, let’s do it.

    Alan Shimel: People who want to know more about Mezmo.

    Tucker Callaway: Come to the website. We’ve got an offer out there to profile anyone’s data for free right now.

    Alan Shimel: Do you really?

    Tucker Callaway: Yeah. Come to mezmo.com or stop by our booth.

    Alan Shimel: M-E-Z-M-O.com.

    Tucker Callaway: M-E-Z-M-O.com

    Alan Shimel: Out there in TV land or if you hear a coupon.

    Tucker Callaway: Come by the booth. I forget the number, but it’s over there.

    Alan Shimel: You know what, if you look on the, I don’t have it. If you look on the back of your ID thing, you could actually look stuff up like that.

    Tucker Callaway: Yeah, it’s back there. If you connected to the wifi here at KubeCon, it’s Mezmo Data.

    Alan Shimel: I’ve noticed that.

    Tucker Callaway: Is the wifi.

    Alan Shimel: I was like, “Wow, what a cool thing.” Yeah.

    Tucker Callaway: You have see us. Come see us. Profile your data will give you insight and understanding into that and talk to you about the next steps.

    Alan Shimel: All right, check it out at Mezmo. Tucker, thanks.

    Tucker Callaway: Thanks for having me.

    Alan Shimel: Actually, we’ll see you. Are you going to be at AWS?

    Tucker Callaway: Yeah, we’ll be there. Yeah, I’ll be there. Yeah.

    Alan Shimel: We’ll be doing videos, not on the show floor. It’ll be a little quieter in a private suite. And then of course you’ll be at RSA.

    Tucker Callaway: We’ll be at RSA.

    Alan Shimel: We’ll be there as well.

    Tucker Callaway: We might not be on the show floor at AWS just because of-

    Alan Shimel: It’s a little crazy there isn’t it? A little pricey.

    Tucker Callaway: Yeah.

    Alan Shimel: Yeah, I hear you. That’s why we’ll be at the wind in the studio.

    Tucker Callaway: I’ll see you there.

    Alan Shimel: Come on up. I’ll have coffee.

    Tucker Callaway: Sounds good.

    Alan Shimel: But RSA will be at broadcast alley and we’ll be doing our DevSecOps thing on Monday. And the usual kind of RSA craziness.

    Tucker Callaway: Looking forward to it.

    Alan Shimel: Absolutely.

    Tucker Callaway: Okay.

    Alan Shimel: Check out Mezmo.com.

    Tucker Callaway: Thanks everybody.

    Alan Shimel: Tucker Callaway here on Tech Drunk TV. We’re going to take a break. I guess it’s almost lunchtime here, but it’s still busy.

    Tucker Callaway: Near enough.

    Alan Shimel: Stay tuned. We’re here all day. We’ll be back. Bye-Bye.

  • Sonar Adds Secrets Detection to Code Analysis Portfolio

    Sonar Adds Secrets Detection to Code Analysis Portfolio

    Sonar has added a secrets detection capability to its portfolio of tools for analyzing code and DevOps workflows.

    Designed to be applied to both finding secrets in code repositories and as applications are developed using an integrated development environment (IDE), this capability is being added to SonarLint, SonarQube and the managed SonarCloud service to identify, for example, passwords, application programming interface (API) keys, encryption keys, tokens, database credentials and other private information.

    Sonar co-CEO Olivier Gaudin said the goal is to eliminate secrets that are accidentally or maliciously stored in source code to improve software supply chain security.

    While it’s important to discover secrets in codebases, Sonar is making a concerted effort to make it simpler for developers to discover secrets before they find their way into a codebase that is one step away from a production environment, noted Gaudin. The SonarLint static analysis tool the company provides can now discover secrets in microseconds using the syntactic and semantic analysis engines the company has now extended, he added. No developer is going to wait five to 10 minutes for a code scan to be completed, said Gaudin.

    A Learn as You Code tool also explains how each secret found in a code segment poses a security risk. The overall goal is not only to remove secrets but, ultimately, reduce the number of instances where secrets are discovered in code, said Gaudin.

    Most organizations today are at varying stages of embracing DevSecOps best practices to improve software supply chain security. It’s not clear how readily secrets management is being embraced as part of those modernization efforts, but as cybercriminals routinely scan for application secrets stored in clear text that can be used to compromise application security, the need to encrypt secrets becomes a higher priority.

    There is, of course, no shortage of tools for detecting secrets. Sonar is now simply making a case for managing secret detection as part of a larger effort to reduce vulnerabilities in code that cybercriminals can exploit. That approach should help reduce the total cost of securing a software supply chain at a time when forthcoming regulations are going to make organizations that deploy software more accountable for application security.

    In the meantime, thanks to the rise of generative artificial intelligence (AI), the volume of code that needs to be scanned will likely exponentially increase. The issue with general-purpose AI platforms such as ChatGPT is they were trained using code of varying quality that often contains vulnerabilities that are now sometimes incorporated into the code they generate. On the plus side, however, many developers have little to no application security expertise, so it’s just as feasible that ChatGPT will create more secure code than a human developer. Regardless of how the code was created, however, no one will know for sure how secure it is without scanning it first.

    Hopefully, as AI progresses, the quality of the code being generated will only continue to improve. Until then, DevOps teams should continue to assume all code is suspect until proven otherwise.

  • Massdriver Adds Cloud Cost Controls to Internal Developer Platform

    Massdriver Adds Cloud Cost Controls to Internal Developer Platform

    Massdriver has made available tools for tracking cloud costs and generating a cloud infrastructure bill of materials (Cloud IBOM) to internal developer platforms (IDPs) as part of an ongoing effort to streamline platform engineering workflows.

    The Cloud IBOM makes it possible, with a few clicks, to map hybrid cloud resources such as databases, machine learning pipelines and serverless computing frameworks.

    Massdriver CEO Cory O’Daniel said collectively, these tools reduce expenses by preventing misconfigurations that result in unexpected costs. Rather than solely providing a summary of costs incurred, the tools provided by Massdriver surface how much cloud services are going to cost at the time the developer is invoking them, he noted.

    In the absence of that context, developers will nearly always overprovision cloud resources to ensure maximum availability regardless of cost, says O’Daniel. The overall goal is to help organizations reduce the total cost of IT by providing developers with insights into costs in real-time, he added.

    Earlier this year, the company launched an IDP that comes with platform engineering tools that, for example, make it possible for DevOps teams to build a catalog of infrastructure components that developers can access within the context of guardrails they define. The platform also includes observability and visualization tools that make it simpler to track metrics and monitor the usage of cloud resources.

    Massdriver is making a case for an IDP that provides built-in tools and workflows that enable organizations to embrace platform engineering as a methodology for managing DevOps workflows at scale. The goal is to reduce the level of expertise required to build and deploy applications in cloud computing environments, said O’Daniel. One of the primary reasons there are not more applications running in the cloud today is that these environments are still too complex to successfully manage, he added. An IDP abstracts away that complexity within a set of workflows that have been vetted by a DevOps team, he added.

    There are, of course, multiple approaches to building an IDP, but rival approaches require too much effort to set up and maintain, said O’Daniel. A proprietary platform provides a more turnkey approach that doesn’t require DevOps teams to either build their own or customize an open source platform, he added.

    It’s not clear at what pace organizations are embracing platform engineering, but there is a clear need to strike a balance between delivering IT services managed by a centralized team and the desire a developer might have to embrace new tooling whenever they see fit. Today, too much responsibility for provisioning IT environments has been pushed left toward developers who now have less time than ever to write code.

    There is, naturally, no guarantee that reducing the cognitive load for developers will increase productivity. Building applications requires streaks of inspiration, but, in theory, an IDP should provide more time for inspiration to strike. DevOps teams, as part of that effort, should be continuously working toward eliminating any bottlenecks that have emerged in their DevOps workflows.

  • What Is the Future Workforce and How Will it Impact DevOps Teams?

    What Is the Future Workforce and How Will it Impact DevOps Teams?

    The rapid changes in technology, work patterns and demographics are ushering in a new era for the labor market known as the future workforce. In this context, DevOps teams—tasked with developing and delivering software quickly and efficiently—are facing novel challenges and opportunities. 

    This article will explore the key characteristics of the future workforce, from remote working to the gig economy, and explores how these changes will impact the roles, practices, and skill sets of DevOps teams. Understanding these dynamics is crucial for both staying competitive and fostering innovation in an ever-evolving professional landscape.

    What Is the Future Workforce?

    The future workforce refers to the evolving nature of the labor market, shaped by factors such as rapid technological advancements, demographic shifts, and changes in work patterns and organization. It’s a concept that’s important to understand given its profound implications for businesses, employees, and society at large.

    The future workforce is already here, and it’s changing the way we work. With every passing day, traditional work models are being challenged and redefined, leading to a professional landscape that’s increasingly diverse and dynamic.

    By exploring the future workforce, you’re not just preparing for changes that may affect your career or business. You’re also discovering opportunities for growth and innovation. Whether you’re an employee looking to future-proof your career, a business owner seeking to attract and retain top talent, or a policymaker aiming to foster economic development, understanding the future workforce is crucial.

    The Composition of the Future Workforce

    Remote Workers

    One of the most significant shifts in the future workforce is the rise of remote workers. As technology continues to evolve, more and more people are choosing to work from home or any location of their choice. This trend is driven by many factors, including the desire for a better work-life balance, the need to save time and money on commuting, and the opportunity to work in a more comfortable and personalized environment.

    Remote working isn’t just good for employees; it’s also beneficial for businesses. Companies that embrace remote work can tap into a global talent pool, reduce overhead costs and increase productivity. 

    However, managing a remote workforce requires a different set of skills and strategies. For instance, businesses must invest in technology to facilitate communication and collaboration, establish clear expectations and performance metrics and foster a culture of trust and accountability.

    Gig Economy

    Another key feature of the future workforce is the gig economy, characterized by temporary, flexible jobs often facilitated by digital platforms. The gig economy includes a wide range of work arrangements, from freelance work and contract-based projects to short-term jobs and on-demand services. In the gig economy, you’re not tied to a single employer or a rigid work schedule, giving you greater flexibility and control over your work.

    The gig economy offers many benefits, such as the ability to earn additional income, the flexibility to work when and where you want, and the opportunity to pursue a variety of work experiences. However, it also comes with challenges. Gig workers often face job insecurity, lack of benefits, and financial instability. Therefore, navigating the gig economy requires careful planning and management.

    Diverse Demographics

    The future workforce is also marked by increasing diversity. This includes not just racial and ethnic diversity but also diversity in terms of age, sexual orientation, disability status and other characteristics. As society becomes more diverse, so does the workplace. This trend reflects not just demographic shifts but also changes in societal attitudes and legal frameworks.

    Diversity in the workforce is not just a matter of fairness and equality, it’s also a business imperative. Numerous studies have shown that diverse teams are more innovative, creative, and effective. Companies need to foster an inclusive culture, implement fair recruitment and promotion practices, and address unconscious bias and discrimination.

    Future Workforce and the Implications for DevOps Teams

    As the nature of the workforce evolves, DevOps teams, traditionally centered on rapid and efficient software development, are increasingly distributed across various locations and time zones. This shift towards a distributed workforce presents unique challenges and opportunities for DevOps practices.

    Distributed Team Dynamics in DevOps

    The essence of DevOps lies in a continuous cycle of collaboration and improvement. In a distributed setting, this requires enhanced communication strategies to ensure that team members are consistently aligned with project goals and timelines. Utilizing collaborative tools and platforms becomes crucial in bridging the geographical gaps. Regular virtual meetings and real-time collaborative environments are pivotal for maintaining team cohesiveness.

    Continuous Integration and Deployment (CI/CD) in a Distributed Setting

    Managing a CI/CD pipeline in a distributed team demands meticulous planning and coordination. DevOps must adapt to different time zones and work schedules, ensuring that the pipeline remains efficient and uninterrupted. This involves automating as many processes as possible and establishing clear protocols for code integration, testing, and deployment, thus reducing bottlenecks and ensuring continuous delivery.

    Infrastructure Management Across Borders

    In distributed teams, infrastructure management must focus on clarity and accessibility. This means maintaining comprehensive documentation ensuring all team members, regardless of location, have a clear understanding of the entire infrastructure. Emphasizing cloud-based solutions can offer a centralized and accessible platform for all team members, thus simplifying remote infrastructure management.

    Emphasizing Security in a Distributed Environment

    Security challenges are amplified in a distributed setup, as team members may access company resources from various, potentially unsecured networks. DevOps teams must implement stringent security protocols and regular training to mitigate these risks. This includes the use of VPNs, regular security audits, and ensuring that all team members are up-to-date with the latest security practices.

    Nurturing a Unified Culture

    Despite physical distances, cultivating a strong, unified team culture is vital. This involves not just the regular technical sync-ups but also creating opportunities for informal interactions and team building. Encouraging open communication and transparency can help in building trust and a sense of community among team members.

    Skill Sets for DevOps in a Future Workforce

    As DevOps teams navigate the future workforce, there are several key skill sets that will become increasingly important.

    Security Skills

    As mentioned earlier, security will be a major concern in the future workforce. DevOps teams will need to have strong security skills, including understanding of security principles, knowledge of security tools and technologies, and the ability to implement secure coding practices.

    It will also be important to stay up-to-date with the latest security threats and trends, as the landscape is constantly evolving.

    Soft Skills

    While technical skills are undoubtedly important, the value of soft skills in the future workforce should not be underestimated. Skills such as communication, teamwork, problem-solving, and adaptability will be essential for success.

    As teams become more distributed and work becomes more complex, the ability to effectively communicate and collaborate will be key. Additionally, the fast-paced nature of technology means that adaptability and the ability to learn quickly will be highly valued.

    Collaboration and Project Management

    In the future workforce, collaboration and project management skills will be crucial. DevOps teams will need to be able to work effectively with a diverse range of stakeholders, from developers and operations staff to business leaders and customers.

    This involves being able to manage projects effectively, from planning and execution to monitoring and controlling. Knowledge of project management methodologies, tools, and techniques will be highly beneficial.

    Conclusion

    In conclusion, the future workforce will bring about significant changes to the professional landscape. As we navigate this new terrain, it’s important for DevOps teams to be aware of these changes and to develop the necessary skills to thrive. By focusing on continuous integration and deployment, infrastructure management, unified communication, and security, DevOps teams can stay ahead of the curve and continue to deliver high-quality software products.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Indeed.com

    MedStudy
    Remote
    Senior DevOps Engineer
    $125,000 to $165,000

    SimplyHired.com

    Raytheon
    Tewksbury, Massachusetts
    Technical Fellow – DevSecOps/Cloud Native
    $122,000 to $155,000

    CareerBuilder.com

    State Street Corp.
    Quincy, Massachusetts
    Azure DevOps Engineer
    $120,000 to $202,500

    Dice.com

    USEReady
    New York, New York
    Senior Azure DevOps Engineer
    $120,000 to $160,000

    LinkedIn

    Northrop Grumman
    Dulles, Virginia
    Senior Principal DevOps Engineer
    $107,300 to $199,600

  • ScienceLogic Unveils Revamped AIOps Platform

    ScienceLogic Unveils Revamped AIOps Platform

    Via an early access program, ScienceLogic this week made available a Hollywood update to its artificial intelligence for IT operations (AIOps) platform that, among other capabilities, provides root cause analysis capabilities that can be invoked via a natural language interface.

    For the first time, this release of the ScienceLogic SL1 platform incorporates predictive and generative AI technologies the company gained with the acquisition of Zebrium in 2022.

    Michael Nappi, chief product officer for ScienceLogic, said Zebrium provided ScienceLogic with an AI model that surfaces insights in a way that is simpler for IT teams to understand and act on. In addition to recommending automated workflows to run, the platform gives IT teams the option to automatically run them when, for example, there is an IT incident that an existing workflow has been defined to address, he added. Each organization will need to determine its level of comfort in automating those processes based on the level of potential risk to the business, noted Nappi.

    In addition, the SL1 user interface displays IT operational information at the business service level to provide IT teams with a guided experience that makes it simpler to prioritize tasks based on their relevance to the business, noted Nappi. There is also now an SL1 toolkit that DevOps teams can use to build or customize PowerPacks templates for monitoring specific processes and services.

    Finally, SL1 is now integrated with Slack and WebEx to streamline collaboration across IT teams. Previously, the platform only supported Microsoft Teams.

    In effect, SL1 now provides IT teams with a cockpit through which they can invoke AI to autonomously manage a wide range of tasks, said Nappi.

    It’s not clear how much advances in AI might one day soon democratize the management of IT, but it is clear the level of expertise required to manage complex IT environments is declining. The overall goal is to reduce dependency on IT professionals, such as software engineers, who are hard to find and retain.

    The rate of change being made to complex IT environments is now also occurring faster than IT teams can track without the aid of AI, noted Nappi. ScienceLogic, in the longer term, is working toward making it possible to interact with a chatbot in real-time to enable IT teams to meet that challenge, he noted.

    Each IT organization will need to decide for itself how heavily to rely on AI to manage IT functions, but in time, many IT professionals are not going to want to work for organizations that don’t provide some level of AI to reduce the level of toil they regularly encounter today. Rather than having to manually perform a series of monotonous tasks, AI should enable IT professionals to act more like supervisors in an IT environment.

    It may be a while before that aspiration is fully realized, but in the meantime, IT teams would be well-advised to start identifying which tasks will soon be automated using AI because roles and responsibilities will evolve. The challenge and the opportunity now is determining how IT teams can add more value to the business as those transitions occur.

  • The Future of Jenkins in 2024

    The Future of Jenkins in 2024

    As software development practices evolve, the tools that support them must also adapt to stay relevant. Jenkins, the venerable automation server used by many DevOps teams, is at such a crossroads as it faces the changing landscape of cloud-native applications and Kubernetes adoption. 

    This article examines Jenkins’ current utility, particularly its features that have made it a staple in CI/CD practices, and addresses the question of whether it will maintain its relevance in 2024 and beyond.

    How Jenkins is Used by DevOps Teams

    CI and CD

    Jenkins has become an integral part of many DevOps teams due to its CI/CD capabilities. Continuous integration (CI) is a software development practice where developers regularly merge their code changes into a central repository. Continuous delivery (CD) is the practice of delivering the software in short cycles to ensure that it can be reliably released at any time.

    Jenkins supports the CI/CD approach in a number of ways. First, it allows developers to automate code integration. This means that whenever code changes are pushed to the repository, Jenkins can automatically build and test the project. Second, Jenkins allows for the continuous delivery of software by automating simple deployment processes (although it lacks full deployment orchestration capabilities).

    Build Pipeline Visualization

    Another key feature of Jenkins is its build pipeline visualization. This feature allows DevOps teams to visually represent the process of software delivery from code integration to deployment. The pipeline visualization provides a clear and intuitive representation of the software delivery process, making it easier for teams to understand and manage the process.

    Build pipeline visualization in Jenkins is customizable, allowing teams to tailor it to their specific needs. For example, it can be customized to show the status of each stage of the delivery process, from code integration to testing to deployment. This allows teams to quickly identify any issues or bottlenecks in the process and address them.

    Automated Testing

    Automated testing is another area where Jenkins shines. With Jenkins, DevOps teams can automate the process of testing their code by running scripts and integrating with automated testing tools as part of the build process.

    Jenkins supports a wide range of testing frameworks and tools, allowing teams to choose the ones that best fit their needs. Moreover, Jenkins can be configured to automatically run tests whenever changes are made to the code. This ensures that any issues or defects in the code are detected early and can be addressed promptly.

    Workflow Scripting

    Workflow scripting is another key feature of Jenkins in DevOps teams. With Jenkins, teams can script their workflows, automating the process of software delivery. This allows teams to standardize their workflows, ensuring that each delivery process is consistent and predictable.

    Jenkins supports the Groovy scripting language for workflow scripting. This means that teams can use the power and flexibility of Groovy to script their workflows. Moreover, Jenkins provides a user-friendly interface for scripting workflows, making the process easy even for those who are not familiar with Groovy.

    Current Usage and Adoption Statistics

    As of 2023, Jenkins remains a leader in the CI/CD space. With its extensive plugin architecture and large user base, it is used by thousands of organizations worldwide. According to the 2022 DevOps Survey by the Cloud Native Computing Foundation (CNCF), Jenkins was used by over 50% of respondents for automation and CI/CD, maintaining a significant presence in the market.

    According to the Jenkins website, there are over 1 million active Jenkins users and more than 200,000 active installations worldwide, with the platform handling 1 million+ jobs per day. It had about 44% of the global market share for CI/CD in 2023.

    The growth trajectory of Jenkins, however, has shown signs of plateauing when compared to newer, more cloud-native-focused CI/CD tools. This observation is backed by Google Trends data, reflecting a steady but not sharply increasing interest in Jenkins over recent years.

    Despite facing competition from emerging tools designed for cloud-native development, such as GitHub Actions, GitLab CI and CircleCI, Jenkins has responded by evolving its ecosystem. The creation of Jenkins X is a strategic move to cater to Kubernetes users and address some of the criticisms related to cloud-native development. However, as we’ll discuss, Jenkins X has not been readily adopted by the industry as of yet.

    Limitations of Jenkins in Cloud-Native Environments

    While Jenkins is a powerful tool for DevOps teams, it has serious limitations in cloud-native environments. These limitations stem from the fact that Jenkins was originally designed for traditional, monolithic applications, not for the dynamic and distributed nature of cloud-native applications.

    Statefulness

    One of the critical limitations of Jenkins in cloud-native environments is its inherent statefulness. Cloud-native architectures typically favor stateless applications, which are easier to scale and manage in dynamic environments like Kubernetes. 

    Jenkins, however, relies on maintaining state—it stores configuration, build history and user data, making it challenging to scale and manage efficiently in a cloud-native setup. This statefulness requires persistent storage, which complicates deployments in distributed systems where resiliency and horizontal scaling are key. Moreover, the risk of data loss or inconsistency increases in cloud-native environments, particularly during scaling operations or when recovering from failures.

    Configuration Complexity

    Jenkins is often criticized for its complex configuration requirements. Setting up Jenkins in a cloud environment involves intricate configurations that are not only time-consuming but also prone to errors. This complexity is exacerbated when integrating with modern cloud-native tools and services, requiring extensive customization and maintenance of plugins. 

    In addition, Jenkins’ traditional master-slave architecture was not designed for dynamic cloud environments, where resources need to be provisioned and deprovisioned rapidly. This leads to a significant operational overhead for DevOps teams.

    Immutable Infrastructure

    Adopting an immutable infrastructure approach is a cornerstone of cloud-native environments, promoting the idea of replacing or rebuilding servers rather than modifying them. 

    However, Jenkins’ traditional model does not align well with this principle. It typically requires modifications to its runtime environment for updates or changes, contrasting with the cloud-native approach of immutable deployments. This can make it challenging to maintain consistency and reliability in cloud-native systems where automation and minimal manual intervention are paramount.

    Microservices Limitations

    Jenkins was originally designed for monolithic architectures and doesn’t naturally fit into microservice-based applications, which are prevalent in cloud-native environments. In microservices architectures, applications are broken down into smaller, independently deployable services. 

    Jenkins, however, tends to treat applications as monolithic units, making it less efficient for handling multiple, independent microservices. This limitation affects its ability to provide fine-grained control over individual services’ build, test and deployment processes. Consequently, Jenkins may struggle with the high degree of automation, flexibility and scalability required in microservices environments.

    What is Jenkins X?

    Jenkins X is an open source project that provides pipeline automation, built-in GitOps, and preview environments to help teams collaborate and accelerate their software delivery at any scale. It is an improved version of the original project, designed specifically for Kubernetes, a popular container orchestration platform.

    Jenkins X streamlines the technical aspects of building, testing, and deploying software. It automates the installation of popular tools like Helm and Draft, making it easier for developers to get started. It also provides pre-configured pipelines so teams can start delivering software right out of the box.

    Jenkins X also introduces a new Jenkinsfile format, Jenkinsfile.yaml, which provides a more straightforward and human-readable way to describe pipelines. This new format, combined with the automation provided by Jenkins X, helps reduce the complexity of pipeline configuration and management in Kubernetes.

    Limitations and Criticisms

    Jenkins X has not been widely adopted by the software industry and has not achieved the respect and prominence of its predecessor, Jenkins. Let’s review the main limitations and criticisms of the tool.

    Lack of Maturity

    Jenkins X’s relatively recent entry into the market means it has not had the time to mature like its predecessor. This lack of maturity can manifest in several ways, including fewer features compared to established tools, fewer community-tested plugins, and potentially more bugs or unresolved issues. Due to the fast-paced evolution of cloud-native technologies, tools need time to adapt and stabilize; Jenkins X is still in this phase of its lifecycle.

    Moreover, a mature tool typically has extensive documentation and a large community of users who can offer support and share best practices. While Jenkins X has seen growth in its user base, it still lags behind more mature CI/CD solutions in these areas. This can lead to challenges when teams are looking to solve complex problems or when they require advanced support.

    Limited to Git Projects

    Another criticism of Jenkins X is that it’s limited to Git projects. While Git is the most popular version control system, it’s not the only one. Some teams may use other systems like Mercurial or SVN, and these teams would be unable to use Jenkins X.

    Even within the world of Git, Jenkins X has limitations. For example, it doesn’t support all Git hosting platforms. While it works with popular platforms like GitHub and Bitbucket, it doesn’t support others like GitLab. This can be a significant limitation for teams that use unsupported platforms.

    Community Support

    Finally, there are concerns about community support for Jenkins X. While the project is open source and theoretically has the potential for wide community involvement, some critics argue that it’s primary source of support is CloudBees, the company behind Jenkins.

    These critics worry that if CloudBees were to withdraw its support, the project could falter. They also argue that the project’s focus on certain tools and platforms (like Kubernetes and Git) reflects CloudBees’ business interests more than the needs of the broader DevOps community.

    Conclusion

    In conclusion, Jenkins’ role in the CI/CD landscape has been pivotal, and its continued evolution with projects like Jenkins X demonstrates an effort to adapt to the needs of modern, cloud-native environments. While Jenkins X has yet to reach the widespread adoption and maturity of its predecessor, its specialized focus on Kubernetes and GitOps reflects the shifting priorities in software development.

    Jenkins, despite showing signs of plateauing in growth, still possesses a strong user base and an established presence in the market, supported by a vast plugin ecosystem and a robust community. Its limitations in cloud-native contexts—such as managing statefulness, configuration complexity, and supporting immutable infrastructure—pose challenges that Jenkins X seeks to address.

    As we approach 2024, the relevance of Jenkins will likely hinge on its ability to integrate more seamlessly with cloud-native technologies and the willingness of the community to evolve its ecosystem. The breadth of its adoption and the depth of its integration in existing development pipelines mean Jenkins will continue to be a significant player in the DevOps toolchain. However, its long-term relevance will depend on the project’s ability to innovate and remain adaptable in a landscape that is rapidly embracing cloud-native solutions.

  • Platform Engineering is a ‘Golden Path’ to FinOps

    Platform Engineering is a ‘Golden Path’ to FinOps

    Cloud costs. This simple reality has given rise to all manner of toolsets now being focused on modern IT stacks to shore up resources, reduce waste, optimize identified efficiencies and to monitor system wellbeing at the highest, widest and broadest level.

    Across cloud computing landscapes now being reinvented for generative AI functions, the rise of machine learning operations (MLOps) practices is aiming to bring software engineering in line with operations engineering and—perhaps above all—cost engineering.

    Before MLOps, There Was FinOps

    But before we tread too deep into MLOps territory, perhaps we should remind ourselves that FinOps (operations aligned to consider the financial impact of all systems architecture and software engineering decisions) is really the foundational practice that should oversee all matters in this field.

    CloudBolt is one organization that’s been very vocal in its desire to help businesses optimize, automate and control hybrid cloud and multi-cloud environments by providing cloud financial management, automation, orchestration and governance solutions for global enterprises. The firm runs several industry reports around various aspects of multi-cloud complexity. 

    Institutionalized Platform Engineering

    CloudBolt’s Kyle Campos, chief product & technology officer (CPTO), suggests that as businesses continue to sharpen their focus on efficiency–scrutinizing every expenditure and tool–by December 2024, most forward-thinking CIOs will ‘institutionalize’ platform engineering and establish corresponding teams. These teams will not only manage technology assets but also prioritize them to accelerate business value. This strategic shift aligns with the broader industry trend of optimizing technology stacks for agility and efficiency, offering a multi-dimensional approach to business.

    “FinOps silos that drive friction and [the presence of] unrealized optimization promises will reach a breakthrough as the conversation and solutions shift from ‘motivation’ to ‘facilitation’ in the coming year,” said Campos. “With platform engineering fully adopted as a technology approach by the majority of forward-thinking IT organizations by the end of next year, FinOps practices will become a native part of the journey to ‘golden paths,’ on par with security and observability, as the trifecta of defaults in the delivery process.”

    The Ultimate Performance Metric

    After decades of profligate spending on hardware, software and services, Campos said he thinks that 2024 will become the year that the cost to run an application becomes the ultimate performance metric. Why does he make this assertion? Because the traditional metrics that are focused on commodities (CPU, memory, disk, network) will actually become less important, he said. 

    As digitally transformed organizations continue their advance to the cloud, the cost-of-goods-sold will get linked intrinsically with operational and services measured at a finer-grained level; looking at specific tools, services and algorithms for cost savings.

    “As organizations grapple with intricate financial challenges in 2024, consumers will increasingly demand flexibility, compelling cloud providers to offer more consumer-centric pricing and services,” said Campos. “The FinOps FOCUS initiative instituted this year is just the beginning. The collective voice of the user community will continue to be a game-changer in leveling the playing field between cloud providers and consumers.”

    AI/ML Disrupts Linear FinOps

    Campos concluded by saying that currently, there is a direct correlation between user complexity/friction and capabilities/cost granularity in the FinOps solution ecosystem. 

    “Increases in the latter make the former that much more complex,” he argued. “But advances in AI/ML will continue to disrupt the status quo, lowering the barrier and time to value for users. What used to take hours of custom configuration, trial and error, will be a low-friction conversation. Additionally, AI/ML will facilitate unit cost solution inversion such that unit cost is provided to the user, not from the user.”

  • RBAC For Your CI/CD Pipeline: Why and How

    RBAC For Your CI/CD Pipeline: Why and How

    Role-based access control, or RBAC, is an approach to managing access and permissions in a system based on the roles of individual users. This concept is integral to information security and access control strategies, where specific roles are assigned to users and each role has its permissions and restrictions.

    RBAC is a powerful tool to ensure that only authorized users can access specific resources, perform certain tasks, or make changes within a system. It eliminates the need for assigning permissions to each user individually, simplifying the administration of security policies.

    In the context of a CI/CD pipeline, RBAC means providing access rights to various stages of the pipeline according to user roles. For instance, a developer may have access to the code repository and the ability to initiate builds, while a deployment manager may have permission to push changes to the production environment.

    In this article, we’ll explain why RBAC is so important for CI/CD pipelines, and provide general guidelines and best practices for implementing RBAC into your pipeline.

    Why Do You Need RBAC in Your CI/CD Pipeline? 

    The adoption of DevOps and CI/CD practices has revolutionized the way software is developed and deployed. However, this has also raised new security challenges. One of them is maintaining control over who has access to what in the CI/CD pipeline. That’s where RBAC comes in.

    Preventing Unauthorized Access

    RBAC is critical for preventing unauthorized access in the CI/CD pipeline. It ensures that only users with the appropriate roles can make changes to the code, initiate builds, or deploy to production.

    By defining specific roles and assigning them to users, it’s possible to provide fine-grained control over access to various parts of the pipeline. This can significantly reduce the risk of unauthorized users making changes that they shouldn’t, whether unintentionally or maliciously.

    Minimizing Insider Threats

    Insider threats are a significant concern for any organization. These can come from disgruntled employees, careless staff, or even hackers who’ve managed to gain access to an insider’s account.

    RBAC can help minimize the risk of insider threats by limiting what each user can do within the CI/CD pipeline. If a user’s account is compromised, RBAC ensures that the attacker can only do what the compromised user is authorized to do. In other words, they won’t have free rein over your entire pipeline.

    Ensuring Accountability and Auditability

    Another benefit of RBAC is that it can facilitate accountability and auditability. When every user action is tied to a specific role, it’s easier to track who did what, when and why.

    This can be particularly helpful in a post-incident investigation. If something goes wrong, you can quickly identify who had access to the affected parts of the pipeline and narrow down the list of potential culprits. Similarly, during an audit, you can easily demonstrate who has access to what, helping to satisfy compliance requirements.

    Compliance with Regulations

    Speaking of compliance, many industry regulations and standards require organizations to implement strict access control measures. RBAC can help you meet these requirements by providing a clear and manageable way to control access to your CI/CD pipeline.

    For instance, regulations such as the GDPR, HIPAA and PCI-DSS all require organizations to limit access to sensitive data. By implementing RBAC, you can ensure that only authorized users can access, modify, or delete sensitive data in your pipeline, helping you stay on the right side of the law.

    How to Implement an RBAC Mechanism Across Your CI/CD Pipeline

    To effectively implement role-based access control (RBAC) in your CI/CD pipeline, it’s essential to integrate an RBAC mechanism that aligns with the specific tools and technologies in use. This requires a combination of technical setup and policy enforcement. 

    Here are the key steps involved in adding RBAC to a large-scale CI/CD pipeline:

      1. Integration with identity providers (IdP): Begin by integrating your RBAC system with an existing identity provider, like LDAP, Active Directory or OAuth provider. This ensures that user identities and roles are centrally managed and consistently applied across all stages of the CI/CD pipeline.
      2. Role definition and assignment: Utilize your CI/CD platform’s native RBAC features or incorporate third-party RBAC management tools. Define roles such as developer, QA tester, security auditor, operations, etc., in the system.
      3. Refine access control: After creating the roles, define permissions at a granular level. For instance, Developers might have ‘read’ and ‘write’ access to the source code repositories but only ‘read’ access to the deployment configurations.
      4. Tool-specific configuration: For tools like Jenkins, GitLab CI or CircleCI, use their specific RBAC configuration options to set up these permissions. Leverage the APIs of your CI/CD tools to programmatically manage access, and utilize plugins or extensions that enhance RBAC capabilities.
      5. Separate environments: Physically or logically separate different environments (like development, staging, production) and apply distinct RBAC rules for each. Implement conditional access policies, where access to critical environments like production can require additional authentication or approvals.
      6. Enable temporary elevated access: Allow temporary elevation of access rights under controlled conditions, such as during incident management or critical deployments, with automatic reversion to standard privileges after a set time.
      7. Continuous monitoring and adjustment: Regularly audit access logs and monitor for unusual activities. Tools like Splunk or ELK stack can be used for monitoring and alerting on RBAC-related events.

    Best Practices for Implementing RBAC in CI/CD 

    Here are a few best practices that can help you implement RBAC more effectively and securely.

    Adopt the Principle of Least Privilege

    The principle of least privilege (PoLP) is a critical aspect of RBAC. It states that a user should be given the least amount of privileges necessary to perform their job functions. This minimizes the risk of accidental or intentional misuse of privileges.

    To implement PoLP, you should start by conducting a thorough audit of the current permissions in your CI/CD pipeline. Identify any over-privileged accounts and rectify them. Additionally, ensure that every new account is created with the least amount of privilege necessary.

    Automate RBAC Enforcement

    One of the challenges with RBAC is ensuring that the defined roles and permissions are consistently enforced. Manual enforcement can be time-consuming and prone to errors. Automating RBAC enforcement can help overcome these challenges.

    Automation can be achieved using scripts or specialized software. These tools can automatically assign roles and permissions based on predefined rules. They can also monitor the system for any deviations from the defined roles and permissions, alerting the relevant personnel when such deviations occur.

    Implement Strong Authentication Methods

    Authentication is the process of verifying the identity of a user or system. It’s the first line of defense against unauthorized access. Authentication comes one step before RBAC — first verify a user is who they say they are, and then RBAC provides the relevant authorization.

    Strong authentication methods can include multi-factor authentication, biometrics, or digital certificates. These methods provide an additional layer of security by requiring more than just a username and password to access the system.

    In addition, it’s important to ensure that the authentication process is secure. This includes encrypting sensitive data, protecting against brute-force attacks, and regularly updating and patching the authentication system.

    Maintain Comprehensive Audit Trails

    Audit trails are records of activity in the CI/CD pipeline. They provide visibility into who did what, when, and why. Audit trails can help detect unauthorized activity, investigate incidents, and demonstrate compliance with regulations. They can also provide valuable insights into the effectiveness of the RBAC system and highlight areas that may need improvement.

    Most user identity systems provide built-in audit trails of RBAC activity. In addition, you should log all user activity in the CI/CD pipeline, including successful and unsuccessful authentication attempts, changes to roles and permissions, and any deviations from the defined roles and permissions.

    Regularly Review and Update the RBAC System

    Finally, it’s important to regularly review and update the RBAC system. This includes reviewing the defined roles and permissions, the effectiveness of the enforcement mechanisms and the completeness of the audit trails.

    Regular reviews and updates can help ensure that the RBAC system remains effective and relevant. They can also help identify and address any emerging threats or vulnerabilities.

    In conclusion, implementing RBAC in your CI/CD pipeline can help ensure secure and efficient operations. By following the best practices outlined in this article, you can create a robust and effective RBAC system. Remember, the goal is not just to prevent unauthorized access but also to enable authorized access securely and efficiently.