devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Despite DevOps, Software Supply Chain Security Challenges Persist

    Despite DevOps, Software Supply Chain Security Challenges Persist

    A survey of 397 IT, cybersecurity and application development professionals conducted by Enterprise Strategy Group (ESG) found that while most respondents work for organizations that have adopted DevOps practices, multiple software supply chain security issues and DevSecOps concerns have yet to be addressed.

    The survey, conducted on behalf of Data Theorem, a provider of a platform for securing application programming interfaces (APIs), the survey also found 82% of respondents have adopted DevOps, with 51% reporting they make extensive use of DevOps workflows (51%). Nearly three-quarters (73%) are deploying code weekly and 31% are deploying code daily.

    However, securing DevOps workflows remains a work in progress, with 41% reporting security teams lack visibility and control of development processes. Other issues include new builds deployed to production with misconfigurations, vulnerabilities and other security issues (40%), developers skipping security processes (39%), software released without going through security checks and/or testing (38%), lack of security process consistency across different development teams (38%), security team can’t keep pace with release cadences (34%) and developers’ reluctance to work with security (29%).

    API security is also becoming especially challenging, with 92% of respondents dealing with at least one API security incident in the last 12 months. Well over half (57%) have dealt with multiple API security issues in the last 12 months.

    On the plus side, the survey also found that more than half (54%) of teams responsible for securing APIs are involved with development as soon as or before the APIs are published. A full 97% said developers either have a good (22%) or high level (71%) of API security knowledge. A total of 89% reported their organization provides formal API security training to their development teams. More than three-quarters (78%) can remediate an API vulnerability within a day, and 39% reported they can do so within hours. A total of 60% reported a dedicated budget has been specifically allocated to API security, with another 30% identifying it as a discrete item within their cybersecurity budget. Two-thirds (66%) said spending on API security would significantly increase in the next 12 to 18 months.

    The use of APIs is only going to increase in the months and years ahead. Well over one-third (36%) of respondents are using APIs across all their applications, with 50% expecting this to be the case in two years. Another 44% reported most of their applications are using APIs., with 32% expecting this to be the case in two years. More than three-quarters (76%) of organizations reported that they have an average of 26 APIs per application and 53% have more than a quarter of their APIs facing the internet.

    More than a third (35%) are updating APIs daily while another 40% do so weekly. A full 61% are using APIs to connect microservices.

    Data Theorem COO Doug Dooley said those APIs are now being targeted by cybercriminals that routinely test the weaknesses of every API after each deployment and update. The most common types of API attacks reported by survey respondents included exposure of data (32%), account takeover (31%), denial of service (DoS) attack (31%), attack on misconfigured API (30%), fake account creation (28%), API injection attack (28%), ransomware (27%), data breach (26%) and content scraping (26%).

    Despite these issues, however, nearly three-quarters (74%) of survey respondents said they believe their organizations have a robust API security program in place, with 22% reporting they have some process in place. Organizations are using a mix of approaches including API security tools (59%), web application firewalls (WAFs) (57%) and API gateways (50%), distributed DoS mitigation (48%) and bot management solutions (42%).

    Challenges included managing multiple tools (29%), visibility into and control of APIs (28%), inventorying APIs (27%), inconsistent adoption of APIs (27%), API security testing (27%), data governance/exposure (26%), discovering and remediating misconfigured APIs (26%), keeping pace with threats (26%) and accurately tracking API usage (25%).

    Significant API security concerns included API authentication issues (41%), account takeovers (39%), identifying and tracking third-party APIs (38%), using tools not purpose-built for security (38%), shadow/undiscovered APIs (38%), abusive behavior bypassing app security tools (38%), denial of service attacks (38%), data governance and/or data exposure issues as a result of insecure APIs (37%), abusive behavior bypassing bot management (37%) and outdated/unneeded APIs, also known as zombie APIs. (33%).

    The type of vulnerabilities that are of the greatest concern are sensitive data exposure (34%), access control vulnerabilities (31%), API business logic flaws (31%) and DDoS attacks (30%).

    More than 79% of respondents, however, are relying on manual testing and review processes to ensure APIs don’t expose sensitive data (79%), with 63% having automated alerting capability for when sensitive data is exposed.

    Overall, it’s apparent that more resources as being applied to securing software supply chains in general and APIs specifically. However, given the amount of software being built and deployed, it may be a while before organizations see the return on those investments.

  • ServiceNow Adds Observability Platform to SaaS Portfolio

    ServiceNow Adds Observability Platform to SaaS Portfolio

    At its Knowledge 2023 conference, ServiceNow launched an observability service that runs on its software-as-a-service (SaaS) platform.

    Based on the observability platform the company gained with its acquisition of Lightstep, the ServiceNow Cloud Observability platform makes it possible to collect and analyze data collected from software running on infrastructure and also from workflows created using ServiceNow applications.

    Pablo Stern, senior vice president and general manager for technology workflows products at ServiceNow, said the goal is to make it simpler to investigate IT issues involving applications and workflows that have multiple dependencies. That makes it possible to quickly diagnose an issue, determine the root cause and then dispatch the right site reliability engineering (SRE) team to troubleshoot it, he added.

    ServiceNow Cloud Observability uses both open source OpenTelemety agent software to collect logs, metrics and traces in addition to a log management tool that ServiceNow gained last year with its acquisition of Era Software.

    In addition, ServiceNow is employing a Service Graph Connector that makes it simpler to pull data from, for example, OpenTelemetry and Kubernetes clusters into the ServiceNow IT Operations Management (ITOM) without requiring any additional tooling. ServiceNow is also making available its Unified Query Language to make it possible for IT teams to query the data residing in ServiceNow Cloud Observability.

    As application environments become more complex, the need for entire IT teams to have access to an observability platform is growing. While observability has always been a core tenet of DevOps best practices, Stern said it’s clear that these capabilities also need to be made available to IT administrators. In fact, as observability becomes more democratized, it will drive the rise of services operations that will enable IT teams to be better aligned around specific processes, he added.

    Most IT organizations today employ a wide range of tools that enable them to monitor a set of pre-defined metrics. Observability platforms, in contrast, enable IT teams to collect data from systems in a way that can be investigated using a query tool.

    It’s still early days as far as the adoption of observability platforms is concerned, but as the collection of logs, metrics and traces becomes more unified, an opportunity to better converge IT practices based on DevOps principles and the ITIL framework that many IT administrators rely on to manage IT will emerge.

    The challenge, regardless of what methodology is used, is that IT teams need to be able to frame the queries they use to discover the root cause of an IT issue before any potential disruption occurs. In the long term, however, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify those issues.

    Regardless of how an IT issue arises, the metric that matters most is how quickly it can be resolved—no matter who in the IT team is tasked with resolving it. The issue is finding a way to provide IT teams with better tools to achieve that goal.

  • Standardize: It’s Not the Where. Sometimes it’s Not the What

    Standardize: It’s Not the Where. Sometimes it’s Not the What

    In our industry’s attempts to follow best practices that marketers assure us we must have or we are going to lose to our biggest competitor … No, wait, we’ll lose to that startup no one ever heard of … No, hold on, we’ll lose to foreign competition … No, wait … (okay, I’ll stop. You get the picture), many of us have gotten completely unreasonable in our IT approaches.

    Like asking a vendor, “Where can I run your application?” Well, the more “where” options the better, because every organization has different needs. But a vendor has to start somewhere, and you can tell when they get to a certain size because they don’t want to talk about it. “We’re SaaS,” was the en vogue thing to say six months ago; now we’re back to “containers” or even “cloud,” thanks to a whole slew of cloud-first offerings out there. But what all of these vendors really need to be able to say (and a disappointingly small number of them actually can) is, “We run on containers, so we don’t have to care where you deploy us.”

    Those are the types of scenarios that forward-looking enterprises need to start anticipating—the broadest, easiest-to-implement, longest-lasting solutions that can be found. The days of “devs picked this DB no one ever heard of because it was 0.0000001 microseconds faster on a hundred-line query,” need to be gone. Standardize on highly usable tools across the DevOps toolchain from libraries approved for use in apps to deployment technology.

    A big part of this approach right now is my pretty common refrain: Advanced automation. The more a system can do, the more time staff has to do other important things. All forms of testing are finally within our grasp because of advanced automation technology ranging from Kubernetes programmability and controllers to ‘AI’ filtering of results (Side note: What most IT folks currently call AI is not; we need to stop calling it that and give it a more accurate name. Machine learning is better; advanced automation is more to the point, IMO). But whatever you call it, it enables massive pre-release testing. From functional to security, it offers the ability to make these tests useful by speeding up testing and results processing so staff need only look at issues considered critical. No one cares where the test engine runs, just that it can run tests wherever the application resides.

    The same is true for a whole lot of other ‘whats.’ Vulnerabilities are probably the best example. Tools are starting to look for them in an automated fashion. Very few organizations have a comprehensive list of which vulnerability databases a tool must support. Any given organization might have one or two databases in their list, but most just require that the functionality be available.

    So don’t get bogged down in the details, and don’t select five different tools to do the same job on five different teams. Start standardizing again. Oh, standardization won’t last when something evolutionary comes along in the space, but it will leave you less clutter to clean up and more specific expertise in-house.

    And that leaves you more time to keep wowing the business. Keep those systems running smoothly and keep cranking out more useful stuff for the organization. Most orgs show their appreciation these days, but some still do not. In those cases, we thank you for them. We know what you’re going through—we are going through it, too, and yet the lights are still on. Keep rocking it.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    devopsy.kinsta.cloud 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:

    Dice.com

    ERP International
    Fort Meade, Maryland
    Senior DevOps Infrastructure Engineer
    $150,000 to $180,000

    LinkedIn

    Lark Health
    Remote
    Lead DevOps Engineer
    $127,700 to $183,900

    Simply Hired

    Shake Shack
    Remote
    Senior DevOps Engineer
    $123,000 to $155,000

    Indeed.com

    Peraton
    Arlington, Virginia
    DevSecOps Data Automation Engineer
    $112,000 to $179,000

    CareerBuilder.com

    Booz Allen Hamilton
    Fort Meade, Maryland
    DevOps Engineer and Release Manager
    $73,100 to $166,000

  • The Right Tool for the Job: AI Edition

    The Right Tool for the Job: AI Edition

    (Actually, the right job for the tool.)

    We are currently in a really weird space with regard to AI capability. For my AI friends, I will make the disclaimer that what we call AI today is not actually AI, it is more akin to LiSP “AI” than actual intelligence (and, in reality, is firmly somewhere in between). In short, we have great language processing tools that we call AI but that have no cognitive ability—but, man, are they useful.

    And the suddenness with which the rest of the world realized they were useful was nothing short of astounding. One day we are using AI algorithms to process test results and filter security data; next thing you know, our business people are bringing up AI and how advanced it is in every meeting.

    They’re not wrong, but we need to differentiate the technologies. The promise and danger of chatbots is not the same as the promise and dangers of AI in security (where it can be used by attackers as easily as defenders, btw). We’re going to have to work out the concerns and benefits in real-time, but we need to start by pushing back and making clear that it is not a panacea, any more than the last 50 technologies that came along. It has great promise to change the world, but so did VMs and Java and containers and …

    This one seems bigger, but that’s largely because it came on so fast and with seemingly broad applicability. But in the end, it is good at processing large datasets and noticing both patterns and anomalies in the data. This is a great, hugely powerful tool, but for things with sparse data? Totally useless. This is critical to remember moving forward. AI that monitors a certain aspect of security in the organization can detect patterns and anomalies, but unless the dataset is massive, there will be a lot of false positives along the way, and a more traditional tool is preferred. If that same AI (same software, algorithm, etc.) is being trained on data from hundreds of companies? Sign the check, it’s probably going to be better and more forward-looking than your current solution.

    And that’s the key. It took the entirety of the World Wide Web—including, I might add, The Gutenberg Project—to train the language processors, so unless that security AI has a massive dataset, it’s not likely ready for prime time.

    In IT, look to AI today (and this will change relatively rapidly, so check back often) for large dataset processing and for advanced automation. Those are the two real use cases. More will come, but right now, the ability to find patterns in large datasets or to say, in real-time, “A+B+C = block that port!” are the biggest viable use cases.

    Over the years, I have grown ever more skeptical of claims about removing the need for developers. Those claims have been made so many times that my friends and I have a stable of jokes about them. Java, XML, 4GLs, RoR, UI generation tools—the list goes on and on. And each one created even more code. I expect AI will be the same, but there is no denying it can offer initial frameworks, much like mobile UI generation tools do. We’ll have to see how much change that bit introduces.

    And keep rocking it. While I hope my readers don’t need reminding not to upload their source code to any of these AI tools, I will point out that your (Dev and Ops) source is so proprietary and critical that employers freak out when it is uploaded to an AI chatbot. No one cares what is done with chatbot-generated source, but the DevOps team’s source is considered critical. Sleep well knowing that.

  • 7 Benefits of Self-Contained Apps for BPM

    7 Benefits of Self-Contained Apps for BPM

    According to Gartner, “As business needs change, organizations must be able to deliver innovation quickly and adapt applications dynamically—reassembling capabilities from inside and outside the enterprise. To do this, organizations must understand and implement the ‘composable enterprise.’”

    This is an appealing concept for companies looking for a good balance between highly centralized and highly distributed technologies and information systems.

    For enterprise IT, the use of composable infrastructure – built up of independent components that can be swapped out when needed – is already widely applied. Another place to look for the advantages of composability: Business process management  (BPM) automation. Why? Because IT teams, DevOps teams and leadership are facing a number of pressures:

    • Business teams need responsiveness and speed from IT as everyone continues to look for ways to maximize go-to-market.
    • Current business process automation platforms deploy applications that are all dependent on shared resources. The DevOps team must take interoperability and integration among a group of applications using shared resources into consideration for new developments, new deployments and maintenance. This can be complex, time consuming and can require extensive testing before updates can be deployed.
    • Similarly, whenever the process application platform is upgraded to a new version to take advantage of new features, or when maintenance on a single application is needed, all applications are affected and the need to offline and upgrade everything can impose a high cost in downtime.
    • Scaling grouped business process applications can add unnecessary cost as it is applied across the board even if not all of those applications need to be scaled.
    • The approach of building business applications from interoperable elements promises to address some of these key issues.

    Modularity and component-based systems have already been successfully applied for many years in IT and software development. Infrastructures are composed; we no longer buy machines but CPU, memory, disk space, bandwidth and so on. In software development we see composability applied through containerization, an approach that is already widely used and becoming the standard for DevOps teams, as shown for example by the growing use of platforms such as Docker and Kubernetes.

    Self-contained applications is setting the same trend for composable BPM process-based applications. BPM technologies already fit perfectly into the approach of composable architectures. Applications themselves are also already internally made up of composable elements: Processes, sub-processes, connectors, services, reusable pieces of code, business rules and UI fragments, just to name a few.

    Self-contained apps combine the benefits of containerization approaches and technologies with the power of its BPM application platform technologies for application development. The BPM base offers wide extensibility to integrate with enterprise IT, with good auditability, traceability and compliance; deployment of individual applications using containers offers faster delivery, portability and easier management.

    DevOps teams can deploy complex applications more easily, deliver continuously, and thus support innovation and faster time to market. Each self-contained app can be deployed individually, independently and quickly to deliver increased value through improvements as quickly as the business requires.

    DevOps teams, IT leadership and CIOs will be happy to see self-contained apps because:

    • The containerized approach included with self-contained apps is already familiar to CIOs and their technical teams.
    • The less complex, independent development and deployment of self-contained applications means faster application delivery to production overall. As it’s not necessary to take interoperability and integration among a group of applications into account during development, development is faster, testing is easier and the resulting application is easier to maintain.
    • Scaling an independent application is simpler and it can be applied to each application individually.
    • Application maintenance costs are reduced, as smaller and more regular updates are now possible.
    • Because it’s easier to implement multiple projects, development teams’ efficiency and productivity, and therefore ROI, increase.

    Business will be happy to see self-contained apps because:

    • Automation and business application projects are more easily adapted to business changes; the IT team can respond more quickly and with more confidence due to the smaller scope and less interdependence among other applications.
    • Faster innovation and competitive advantage offers a faster response to new business needs.
  • How LinkedIn is Investing in Developer Productivity and Satisfaction

    How LinkedIn is Investing in Developer Productivity and Satisfaction

    More and more companies are beginning to examine the role developer experience has in improving engineering productivity and morale. And one company often referenced as a model for developer productivity engineering is LinkedIn—its engineering leadership has invested heavily into reducing time-consuming developer tasks and constructing an internal platform to gauge developer satisfaction on the tools they use.

    Engineers at LinkedIn recently shared how the company has invested in measuring developer productivity and happiness as well as their strategies for automatically cherry-picking commits. I also met with LinkedIn engineering leadership for a closer look at how the organization is working to improve the developer experience across its internal platform.

    Below, we’ll take an inside look at LinkedIn Engineering’s efforts to enhance developer happiness. We’ll explore their approach to improving their internal software development trends and consider the benefits LinkedIn has gained throughout the process.

    A Look at LinkedIn Internal Developer Solutions

    Productivity is challenging to measure, said Jared Green, VP of engineering, head of developer productivity and happiness at LinkedIn. So, the company opted to take a different approach by including happiness as a variable in the equation. Thus, they measure not only how fast a workflow is but continually monitor how enjoyable the process is to ensure developers have a delightful experience.

    “We don’t just strive for productivity, but for productivity and happiness,” said Green. And to his point, on-the-job satisfaction can have real-world results—on average, happy workers are 13% more productive, according to a University of Oxford study.

    LinkedIn now oversees a custom-built internal platform for evaluating the sentiment of developer tools. The platform, known as iHub, is a holistic listening channel to gauge developer satisfaction across various tools. It collects real-time qualitative feedback from users and correlates it with objective quantitative telemetry. It then surfaces this data in a UI dashboard for team leads and individual contributors to view.

    But there’s an art to engendering the trust required to collect accurate feedback, says Max Kanat-Alexander, principal staff software engineer at LinkedIn. For example, individual contributors need to be sure the data won’t be used for performance reviews. Once that trust is established, folks are more willing to give genuine feedback, he said.

    Benefits of Investing in Developer Enablement

    The benefit of centralizing developer experience metrics with a shared platform means that tech leads can make data-backed decisions on how to improve their DevOps processes. “It’s really about thinking about giving people insights versus giving them data,” said Green. The idea is that frontline engineers can rapidly investigate any metric to expose problems and see trends. “The optics have given leaders ways to improve various parts of developer experience,” he said.

    Through their investment into developer experience, LinkedIn Engineering has discovered and streamlined hangups in the Git flow, exposed inefficiencies in their code review processes, and fixed specific developer build times. LinkedIn Engineering reported it has reduced time spent on certain time-consuming developer tasks by 99.6%.

    To construct iHub, LinkedIn Engineering wrote its own front end. The hub pre-computes data dimensions and stores them in an offline data store, increasing speed, said Kanat-Alexander. The system uses a sophisticated survey technology to collect the data and hides the complexity of manual collection in a sleek dashboard.

    LinkedIn managers have already leveraged iHub data to identify macro trends and resolve specific points of friction. For example, Kanat-Alexander describes how one director noticed that developer build time was worsening in their organization. They were able to isolate it to a single developer who wasn’t using remote development, which was spiking the metric. Leaders then assisted in unblocking them.

    Takeaways For Your Organization

    Most companies could benefit from a UI like iHub, explained Kanat-Alexander. But, you really must have a large engineering organization to see the benefits of the work. Plus, up to 80% of the legwork is simply data integrations—this involves hooking into systems, cleaning up data and deciding how to measure certain metrics. “Whatever you can measure, you can improve,” said Green.

    LinkedIn Engineering has flirted with the idea of open sourcing iHub, but it’s a bit too custom to LinkedIn to be valuable to other enterprises. “There’s a lot of variance in build technologies nowadays, and large-scale engineering systems are bespoke,” said Green. Implementing such a dashboard also requires a deep understanding of developer personas and how people work, which can be entirely unique for each organization.

    Although other organizations can’t fork LinkedIn’s efforts, there are some takeaways that could help others invest in their internal DX. First, Green recommended starting with the fundamentals. “Having a core of understanding about what you’re trying to move the needle on is important, as is coming up with ways to talk about it consistently.” This forethought should help establish what you want to measure.

    Turning DX Metrics Into Action

    Studies indicate that more companies are seeking to implement platform engineering or similar developer productivity engineering initiatives. The end result of these efforts should be to empower people and ensure they are satisfied with their work and not just a cog in the system.

    On that note, it’s critical that there are mechanisms for action to happen on the data that is collected, said Kanat-Alexander. Someone needs to monitor the insights and make changes to improve the metrics over time. “Then you can win hearts and minds.”

  • FIDO/WebAuthn Passkeys is Inevitable: Get on the Train ¦ IBM CEO Hates WFH

    FIDO/WebAuthn Passkeys is Inevitable: Get on the Train ¦ IBM CEO Hates WFH

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: The Passkeys authentication standard gets a huge boost, and IBM’s Arvind Krishna wants workers back in the office. (more…)

  • DevOps Onramp: Security on the Rise

    DevOps Onramp: Security on the Rise

    I don’t normally advertise stuff in my blog, because that’s not what it is here for. It is here to offer you the thoughts and ponderings of someone like you, and advice you didn’t ask for. But today we’ll make an exception since I also blathered for Techstrong Group recently, and soon you’ll be able to hear it.

    If you are not familiar with it, DevOps Onramp is this week, and you can go and register to hear my session and the sessions of other great voices that are involved in DevOps. My session is about DevOps and Security, but there are a wide variety of sessions for you to choose from.

    I am trying to make the time to be involved in the conversation when my session airs, and it looks like my schedule will allow it, so if you are interested in DevOps security, I’ll likely be around to discuss it with you.

    I can’t speak for all of the sessions, but mine starts with the basics for newcomers and then covers more advanced topics as it goes on. The truth is that I was supposed to do two sessions–intro and advanced, but I started talking too fast, and the next thing you know, I crammed it all into one session, saving you time for some of the other great content that is available at the show.

    So (virtually) drop by, watch my session, see what else you’re interested in, and feel free to drop any of us presenters a line telling us what you think, good and bad. I’m sure the show organizers would be happy to receive feedback too, but I’m all about presenters.

    And keep rocking it. We’ll be back next week with our regular content (and no ads).

  • GitLab Allies With Google to Bring AI to DevOps

    GitLab Allies With Google to Bring AI to DevOps

    GitLab extended its alliance with Google as part of an effort to bring more generative artificial intelligence (AI) capabilities to DevOps workflows.

    The GitLab suite of software-as-a-service (SaaS) applications already reside on the Google cloud platform to provide GitLab with the foundation of data required to train those AI models. Over the course of the last two months, GitLab has already added numerous capabilities that rely on multiple types of AI technologies.

    For example, there is now an experimental Explain This Vulnerability capability that provides a natural language summary of an issue in a way developers and cybersecurity teams can easily comprehend.

    Taylor McCaslin, a product group manager for data science and AI/machine learning for GitLab, said going forward, most of the AI focus is going to be on leveraging generative AI capabilities. Those capability will be enabled by Google using a large language model (LLM) that GitLab developed for DevOps workflows. That approach enables GitLab to surface more accurate recommendations based on validated data compared to the general purpose LLM that was used to create the ChatGPT service.

    In addition, GitLab can continuously update the AI models it is running on the Google Vertex AI cloud service using the data from its SaaS application environment which is continuously monitored and updated, McCaslin noted.

    It’s not clear what impact AI may have DevOps workflows, but GitLab is forecasting a 10x improvement. That will be accomplished by, for example, surfacing code that can be used to remediate a vulnerability. Today, many vulnerabilities are not addressed simply because developers don’t have enough time to write a patch.

    A recent GitLab survey, however, suggested developers are already embracing AI to improve productivity, with 62% of developers using AI and machine learning algorithms to check code. More than a third (36%) also rely on AI and machine learning algorithms to review code.

    At this juncture, the one thing that is certain is AI and other associated technologies are going to make developers more productive. It’s not nearly as apparent what impact increased amounts of code moving simultaneously through DevOps pipelines is going to have on the software engineers that manage those processes. The expectation is that similar types of AI advances will also enable more code to flow through those pipelines without, hopefully, further exacerbating any existing bottlenecks that might exist.

    In the meantime, it’s clear the AI genie is out of the bottle. There will soon be more LLMs for all kinds of tasks. DevOps teams should start planning today based on the assumption that many manual tasks that conspire to make software engineering tedious are going to fade away. As such, the roles with a DevOps team are going to change and evolve. The assumption those DevOps teams should make is that these changes will be for the better. After all, the reason organizations embraced DevOps in the first place was to ruthlessly automate IT processes—AI is simply the latest iteration of that commitment.