devopsy.kinsta.cloud

Category: DevOps Practice

  • Embracing Chaos With AI: Reinventing SRE’s Anti-Fragility Practices

    Embracing Chaos With AI: Reinventing SRE’s Anti-Fragility Practices

    In my recent blog, Revolutionizing the Nine Pillars of SRE with AI-Engineered Tools, I indicated that AI can contribute to the development of more resilient systems by analyzing system behavior under stress and identifying vulnerabilities. In this blog, I explain, in more detail, how AI-engineered tools can improve the SRE anti-fragility pillar of practice.

    AI Use Cases for SRE Anti-Fragility

    Fire Drills: AI can assist in creating more effective and dynamic fire drills by predicting potential failures based on patterns and anomalies in data. Tools like Gremlin and ChaosIQ can be used to design, schedule and manage chaos experiments. However, resistance from team members may be a challenge due to the potential for disruption. To overcome this, it’s important to communicate the benefits and ensure there are safeguards in place to prevent unnecessary disruption.

    Chaos Engineering – Infrastructure: By introducing controlled failures in the infrastructure, AI can learn and identify weaknesses that would not be apparent under normal conditions. Tools like Chaos Monkey and Netflix’s Simian Army can be helpful here. A significant challenge could be to deal with the resulting chaos and anomalies. Adequate training and support are required to ensure the teams can handle the chaos experiments and learn from them.

    Chaos Engineering – Applications: AI can introduce failures at the application level to understand how the system behaves and recovers. Tools like Litmus can help conduct these experiments. Challenges could include resistance from developers and potential impacts on the user experience. Having a well-defined scope and process and conducting these experiments in pre-production environments can help mitigate these risks.

    Chaos Engineering – Security of Production Environments: By simulating attacks and breaches, AI can help understand vulnerabilities in the security architecture. Tools like Game of Hacks and AttackIQ can simulate different types of attacks. The main challenge could be the potential exposure of vulnerabilities, making it essential to have robust security measures in place and conduct these exercises in a controlled environment.

    Identifying Reliability Weaknesses in Production Logs: AI can analyze vast amounts of log data to identify patterns or anomalies that may indicate reliability issues. Tools like Splunk and Logz.io can help here. However, the sheer volume and complexity of log data can pose a challenge. To overcome this, robust data management strategies and powerful AI-driven analytics tools should be deployed.

    Predicting System Failures: AI can analyze system usage and performance data to predict potential system failures before they occur. Tools like Dynatrace and New Relic can be useful in this scenario. A major challenge here is the accuracy of predictions, which can be addressed by training the AI model with quality data and continuously refining it.

    Automated Rollbacks: AI can help in the automated rollback of deployments if chaos experiments or real-time monitoring reveal major issues. Spinnaker is one tool that can help in this aspect. The challenge is to ensure accurate triggers for rollbacks without causing unnecessary disruption. This can be mitigated by proper testing and calibration of the AI system.

    RoadMap for SREs to Transform Incident Response to Using AI

    Here is a practical roadmap for organizations that want to transform to using AI tools for SRE anti-fragility.

    Define Anti-Fragility Goals: Define what you want to achieve with your AI-driven anti-fragility measures. Is it to reduce system downtime, improve security or enhance overall system resilience? Defining these goals upfront will help guide the selection and implementation of AI tools.

    Identify Use Cases: As per the use cases listed above, identify those that are most relevant to your organization and your specific infrastructure and applications. Prioritize them based on your anti-fragility goals.

    Evaluate AI Tools: Assess various AI tools available in the market, such as Gremlin, ChaosIQ, Chaos Monkey, Litmus, Game of Hacks, AttackIQ, Splunk, Logz.io, Dynatrace, New Relic and Spinnaker. Look for those that align best with your defined use cases and overall goals.

    Pilot and Learn: Select one or two tools and use cases to start. Run pilot programs to understand the effectiveness of these tools and to gain valuable insights. This step also includes training your team to use these tools effectively.

    Integrate with SRE Practices: Once you have gained sufficient confidence in the chosen tools, integrate them with your existing SRE practices. Ensure that these tools can interact with your current monitoring, incident management and deployment tools.

    Iterate and Improve: Continually measure the impact of these AI tools on your systems’ anti-fragility. Use this feedback to refine your approach, re-adjust your goals, and explore other use cases or tools.

    Expand Scope: As your team becomes more comfortable with AI tools and chaos engineering practices, you can gradually expand the scope of AI-driven anti-fragility measures across more applications, systems and use cases.

    Summary

    The rising complexity of digital systems and increasing customer expectations necessitate a shift towards a more resilient and adaptive approach to system reliability. SRE’s anti-fragility pillar embraces this challenge, allowing systems not just to resist stress but to thrive under it. The incorporation of AI tools in the realm of anti-fragility brings this dynamic resilience to a new level, enhancing capabilities from conducting fire drills and chaos engineering to identifying reliability weaknesses in production logs. With AI-driven tools like Gremlin, ChaosIQ, and Splunk, SREs can effectively simulate failures, analyze intricate system patterns, and proactively fix potential issues to build stronger, more reliable systems.

    Embarking on a journey to harness AI for anti-fragility is an exciting endeavor that promises profound benefits. An achievable roadmap begins with setting clear goals, selecting relevant use cases, evaluating suitable AI tools, and running pilot programs. The key is to integrate these tools into existing SRE practices gradually and iteratively, continually assessing their impact and refining the approach based on the insights gained. This journey is a continuous process of learning, adapting, and expanding, fostering an environment where systems can thrive amidst chaos and uncertainty. The future of SRE is here, and it’s more robust and resilient than ever.

  • Grafana Labs Delivers Open Source Code Profiling Tool

    Grafana Labs Delivers Open Source Code Profiling Tool

    Grafana Labs this week released version 1.0 of an open source tool that collects data about an application’s code to aid debugging, troubleshooting and optimization efforts. The tool makes it simpler to identify the specific lines of code driving a process or task within an application.

    Ryan Perry, engineering director for Pyroscope at Grafana Labs, said Grafana Pyroscope 1.0 combines a tool acquired last year from a company he led with Grafana Phlare, a code profiling tool that Grafana Labs previously developed. The combination of the two tools provides a more precise code-tracking capability with an underlying database that is designed to scale horizontally, he added.

    For example, Grafana Pyroscope 1.0, which supports extended Berkeley Packet Filtering (eBPF) running on Linux systems, can now ingest, store and query workloads from any project of any size. Grafana Pyroscope 1.0 has already been used to profile more than 50,000 application instances at a rate of more than 6,000 unique profiles per second.

    The code profiling tool was added to Grafana Cloud Profiles, the hosted continuous profiling tool that Grafana makes available as a service, earlier this month.

    While the primary use case for Grafana Pyroscope is to troubleshoot applications, organizations are also using it to identify and then remove dead code within an application as part of a larger application modernization initiative, noted Perry. As updates to applications are made over several years, organizations frequently find that subsets of the application code are no longer needed, said Perry.

    The goal going forward is to add support for features such as flame graphs in GitHub pull requests, canary deployments, profile-guided optimization (PGO), integrating profiling with load testing tools such as Grafana k6 and integration with visual editors such as VS Code.

    In addition, Grafana Labs is committed to working with the OpenTelemetry project led by the Cloud Native Computing Foundation (CNCF) to ensure Grafana Pyroscope remains aligned with the OpenTelemtry effort to develop an OTel-native profiling tool. Grafana Pyroscope 1.0 will provide the ability to ingest data from that tool and contribute client-side instrumentation capabilities the company has developed.

    Grafana Labs is also working toward improving client-side software development kits (SDKs) to add more real-time agent management features, such as sampling controls, ad hoc profiling capabilities and alternative instrumentation options.

    Finally, Grafana Labs plans to improve eBPF integration for languages such as Python, Java and .NET.

    DevOps teams naturally spend a lot of time trying to optimize application performance and troubleshooting issues that arise long after an application is initially deployed. Code profiling tools are emerging as a tool that makes it much simpler to aggregate metrics, logs and traces and surface actionable insights that make debugging and troubleshooting applications much less tedious. The challenge is finding the time to identify and proactively address potential issues before they become another incident to manage.

  • Product Mindset Key to Platform Engineering Success

    Product Mindset Key to Platform Engineering Success

    Platform engineering has taken the world by storm, and for good reason. Good platforms reduce TicketOps, standardize config setups, and cut lead time and time to market. Despite the discipline’s new popularity, there remain some questions about what sets platform engineering apart from DevOps. The answer to those questions lies in the platform as a product approach–the heart of every successful platform engineering effort.

    What is Platform Engineering?

    According to Luca Galante, platform engineering is “the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.” Platform engineers build an internal developer platform, which “consists of many different tech and tools, glued together in a way that lowers the cognitive load on developers without abstracting away context and underlying technologies.”

    What is the Platform as a Product Approach?

    A product approach requires user research, a defined mission, leveraging lighthouse teams, getting regular feedback, iterating and marketing your platform for internal buy-in. Together, these product management best practices will ensure your platform enables true developer self-service and finds the right level of abstraction.

    “Build it, and they will come” is not a viable strategy for ensuring developers will adopt your platform. Similarly, forcing developers to use a platform is likely to fail. Mandated usage creates resentment, reduces trust and results in shadow ops. To avoid your platform’s untimely demise, you have to treat your platform like a product and sell it to your customers: Your developers.

    This article provides a high-level overview of what a product mindset looks like in practice and why each component contributes to the success of your platform.

    Do Your Research

    Unless you gain a comprehensive understanding of developers’ pain points and what they’re already doing to mitigate those issues, you won’t build a platform people actually want to use. Hashicorp’s Michael Galloway shared this example of a user survey he conducted with his team while at Doma. The idea is to ask questions about the full software delivery process, from the planning stages of the interviewee’s work to debugging and testing. This way, the platform team can prioritize creating features to solve developers’ most frustrating problems.

    Oftentimes, platform teams will find that teams have conflicting wants and perspectives on what the platform should be. A platform product manager will help translate disparate responses into an actionable and successful plan. Successful platform teams also research open source and commercial tools and integrate pre-built solutions into their platform where beneficial. They study blueprints, like the internal developer platform reference architectures developed by McKinsey, as a starting point.

    Define Your Mission

    Your mission statement gives your platform team a clear identity and priorities. It’s also a starting point for understanding and communicating your impact on the business to relevant stakeholders. Good mission statements are emotional and inspiring, simple but meaningful, match the longevity of the organization and are informed by user research.

    Leveraging Lighthouse Teams

    When starting their platform engineering journey, many organizations don’t know what to build first. The confusion arises from having two important yet conflicting priorities. On the one hand, your platform team doesn’t want to bite off more than it can chew by building too many features at once. On the other hand, platforms that are thin enough to cover the entire enterprise often fail to provide enough value to individual teams.

    The way to strike the right balance is by leveraging lighthouse teams. A lighthouse team is the first group of people you’ll choose to build your organization’s platform for, so spend a lot of time with them to get it right. Cultivate ambassadors and evangelists and give them time to get the rest of the team (and the organization!) on board with your platform. Once you’ve built a platform that provides real value to your lighthouse team, repeat this process with more teams across the organization.

    The lighthouse team approach is valuable because it helps platform teams avoid boiling the ocean while also ensuring your platform provides real value every step of the way.

    Stay in the Loop

    Initial user research is not enough to sustain a successful platform engineering effort. Platform teams should solicit regular feedback from developers and use it to iterate the platform.

    Market Internally to Get Buy-In

    Conversations about platform engineering often focus on developers, but developers are not your platform’s only stakeholder group. Your platform team will also need buy-in from managers, SysAdmins, DevOps engineers and the C-suite.

    In his PlatformCon 2023 talk “How to communicate the business value of platform engineering,” Gartner’s Manjunath Bhat shared Gartner’s Enterprise Value Equation as a foundation for platform teams to understand and communicate the value of their Internal Developer Platform to different stakeholder groups.

    The process includes assessing stakeholder priorities and concerns, identifying and defining value enablers, building a value map to map value enables to stakeholder impact, supporting the value story through outcome metrics, and communicating the “why” and realized value to the organization.

    Sounds Great. What’s the Catch?

    Applying a platform as a product approach can be difficult in practice. For example, many organizations struggle to afford the internal developer platform the same considerations as they would an external product. When working with internal developers, it’s easy for platform teams to make assumptions about what those users know, want and need. However, platform engineering requires avoiding these assumptions and always seeking user perspectives.

    Another common pitfall organizations encounter is mandating platform adoption. Making the platform mandatory closes off the critical feedback loops platform teams need to gauge the success of their platform and make continuous improvements.

    Conclusion

    The platform as a product approach is what sets platform engineering apart from DevOps. It’s deceptively simple but important if you want to build an internal developer platform people actually want to use.

  • Google Adds App Modernization Tools to Generative AI Platform

    Google Adds App Modernization Tools to Generative AI Platform

    Google this week added automated refactoring capabilities to the generative artificial intelligence (AI) tools it makes available to write code on Google Cloud.

    In addition, Duet AI for Google Cloud is now integrated with Google’s Apigee API Management and Application Integration services. This makes it possible to design, create and publish application programming interfaces (APIs) using simple natural language prompts.

    These additions to the preview of Duet AI for Google Cloud were announced at the Google Cloud Next 2023 conference and are scheduled to be generally available later this year. The new capabilities promise to reduce the time and effort required to modernize applications.

    For example, DevOps teams can now convert code written in C++ into Go and migrate that application to Cloud SQL, the managed relational database service that Google provides. Via a natural language interface, these tasks are launched via a prompt from directly within a development environment.

    Priyanka Vergadia, a developer advocate for Google, told attendees these capabilities will reduce the need to rely on consultants to migrate applications and take up much less time. In addition, the overall quality of the code should improve using large language models (LLMs) that have been trained using code written by Google developers and best practices defined by Google software engineers.

    Organizations will save time and effort because the need for developers to understand how existing application code was constructed is eliminated, she noted.

    Google has also started to work with select enterprise IT teams to allow Duet AI to incorporate knowledge from their libraries and codebases to generate more context-aware code suggestions.

    In addition to writing code, Google is making a case for also using Duet AI in Google Cloud to monitor performance and troubleshoot IT issues by identifying correlations across application environments. For example, natural language prompts can be translated into PromQL queries to analyze time-series metrics. Duet AI can also provide intuitive explanations of complex log entries in Logs Explorer for easier root-cause analysis and provide suggestions for how to fix issues that surfaced in an error reporting tool.

    Duet AI is also incorporated into the Google BigQuery service to help developers write SQL and Python code to access and analyze data. It can generate full functions and code blocks, auto-suggest code completions and explain your code and SQL queries. Via a single SQL statement, a query can connect tables with the foundational AI models Google makes available via its Vertex AI service.

    At the same time, IT teams can optimize prompts using BigQuery Studio tools, perform text analysis or generate new attributes to enrich a BigQuery data model. Duet AI also enables IT teams to generate vector embeddings in BigQuery to create semantic searches and recommendation queries.

    It’s not clear whether generative AI capabilities will automate entire DevOps and DataOps workflows just yet, but many of the tasks that once required automation scripts will soon be automated by AI models embedded within DevOps platforms. The challenge and the opportunity is to determine how to make those capabilities available to drive DevOps workflows at unprecedented scale.

  • VS Code for Mainframe: The Enterprise Developer Tipping Point

    VS Code for Mainframe: The Enterprise Developer Tipping Point

    Optics matter. At a recent industry conference, a university lecturer reconfirmed what many in attendance already knew, “3270 [green screens] scare off the young generation of developers.” No matter how state-of-the-art the platform or mission-critical the applications, perceptions are formed largely based on optics, and green screens are not a good look.

    Beyond optics, though, a new option offers the promise of a more normalized developer experience (DevX) and DevOps productivity across platforms, along with the staffing flexibility it brings. In short, Visual Studio Code (VS Code) is a big step toward breaking down the mainframe silo.

    VS Code’s extensible, ‘any language, any platform’ design makes it the perfect tool for mainframe developers and with the free and open Code4z extension pack, VS Code is mainframe-ready. Developers are now using VS Code for mainframe AppDev just like their peers, taking advantage of the extraordinary ecosystem and the other many benefits that have made it a runaway success.

    Per my previous article, Git for Mainframe: Back to the Future, combining VS Code with Git (i.e., editor and source interfaces) makes the experience complete.

    So how does Code4z make VS Code mainframe-ready?  Let’s explore the answers from a functional perspective.

    Editing & Debugging

    Mainframe is closely associated with core languages like COBOL, Assembler and JCL, which are often ignored in the world of modern tooling. With VS Code’s extensible framework, however, incorporating these languages is simple and seamless.

    The Language Server Protocol (LSP), which was developed for VS Code, is now an open standard also used by the next generation of browser-based editors, providing a degree of future-proofing. LSP extensions provide a rich editing experience with a wide range of popular features including IntelliSense, which offers capabilities like syntax checking, verb formatting suggestions and variable name completion.

    Code4z offers LSP extensions for COBOL and High Level Assembler (HLASM) while additional extensions are available for languages like JCL, REXX, Db2, and Easytrieve. The extensibility of this technology has already been used to extend syntax awareness to specific language dialects.

    Similar to LSP, the Debug Adapter Protocol (DAP) provides a native interface and layer of abstraction for debug services. Code4z’s debugger extension facilitates the debugging of CICS and batch COBOL programs, an integral part of the end-to-end experience.

    Access & Security

    Mainframe applications, the lifeblood of many businesses, require rock-solid security throughout the entire SDLC. Code4z leverages Zowe, the award-winning open source framework that extends mainframe security and access controls to tools like VS Code. The Zowe Explorer extension, built on the Zowe CLI, provides access to data sets, jobs and USS files and developers also use it to issue TSO and MVS commands and to submit JCL. Zowe Explorer is packaged with Code4z as is a data editor for mainframe data sets including VSAM. This extension is built on Zowe Explorer, again leveraging the extraordinary extensibility.  A Zowe Explorer for CICS is also available.

    Similarly, developers can access a rich and growing set of conformant Zowe CLI extensions via the terminal and scripting.

    Access to SCMs tools is also supported. In addition to VS Code’s native Git integration, there are extensions for Endevor, ChangeMan ZMF, and related tools.

    DevOps Automation

    Since my introductory article a few years ago, Z is for Zowe – the Open Path to Mainframe DevOps, Zowe has enjoyed wide adoption with 69% of surveyed sites either currently using or planning to use it within the year.

    With mainframe teams now using Zowe to adopt modern shift-left practices, scripts for scanning, building, deploying and testing can be run manually by developers from VS Code, in addition to automatic triggers from code commits. This flexibility further empowers developers to own their code throughout the SDLC and beyond.

    With VS Code, mainframe developers can be equipped with more self-service capabilities like Db2 schema provisioning to accelerate the testing process. With capabilities like these, developers can remain in the VS Code experience focused on editing rather than being distracted by low-value infrastructure activities, like requesting and waiting for DBA action.

    Playing the Long Game

    While VS Code is the dominant tool today—almost 3 times as popular as its closest competitor according to Stack Overflow with the lead growing—what is the long-term opportunity?

    Demand for a modern, enterprise-aligned experience spans many domains, from increasing productivity to backfilling retiring staff. Elevating team morale and future-proofing vital mainframe assets ensure this adoption trend will only increase.

    But tools change. Browser-based editors and in-the-cloud collaboration are gaining greater acceptance and the AI-assist excitement is palpable. Bringing mainframe developers onto an enterprise platform ensures mainframe teams will be able to benefit from the same advances as distributed peers. Enabling VS Code and its cloud equivalents demonstrates a commitment to the long-term success of these applications and by reducing the idea-to-production cycle, product owners become champions.

    While not all mainframe developers will embrace VS Code, especially those close to retirement, the vast majority will, as we have experienced within our Broadcom engineering organization. The bottom line is that VS Code makes them even more productive, as illustrated in Confessions of a Career ISPF Programmer.

    Many of today’s developers are proficient with multiple languages (i.e., polyglot) so picking up an additional language like COBOL becomes less daunting if everything else—editor, repo, DevOps processes, etc.—is familiar.

    Getting Started

    For a closer look at the many free and open Code4z extensions, check out the Developer Cockpit, which simulates a COBOL/Db2/CICS developer configuration. And read From VS Code to Mainframe Developer Cockpit for more detailed use cases.

    Most importantly, try it! Code4z is available on the VS Code Marketplace.

    And stay tuned for additional Code4z extensions in the pipeline. There’s never been a more exciting time to be a mainframe developer!

  • 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

    MasterCard
    O’Fallon, Missouri
    Principal DevOps Engineer
    $160,000 to $202,000

    Dice.com

    ITC Federal
    Remote
    Technical Lead – DevOps
    $130,000 to $150,000

    SimplyHired.com

    JP Morgan Chase
    Jersey City, New Jersey
    AWS DevOps Software Engineer
    $128,500 to $180,000

    LinkedIn

    Accenture Federal Services
    Springfield, Virginia
    DevOps Services Specialist
    $122,600 to $198,800

    CareerBuilder.com

    NextZen Tek Solutions
    Alpharetta, Georgia
    Azure DevOps Lead
    $120,000 to $170,000

  • IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM this week announced it will preview a generative artificial intelligence (AI) tool for converting COBOL code running on mainframes into Java. The preview will be available next month during IBM’s TechXchange learning event, IBM said.

    Kyle Charlet, CTO for Z software at IBM, said watsonx Code Assistant for Z makes use of large language models (LLMs) that IBM has trained to both convert and optimize Java code for z/OS running on IBM mainframes.

    Rather than converting COBOL into Java code line for line, the watsonx Code Assistant for Z improves the syntax of Java code generated using object-oriented techniques, he noted.

    IBM’s watsonx.ai code model, which will have knowledge of 115 coding languages, is based on 20 billion parameters that will eventually be applied to other programming languages such as PL/1, added Charlet.

    That model is the same core LLM that IBM used to create Red Hat Ansible Lightspeed, a tool to generate code for an IT automation framework that is scheduled for release later this year. In the future, IBM will also most likely employ generative AI to convert REXX code into Ansible code, said Charlet.

    IBM expects the final offering will combine generative AI tools with its existing Application Discovery and Delivery Intelligence (ADDI) inventory and analysis tool to streamline the modernization of legacy mainframe applications.

    The goal, however, is not to move COBOL applications off the mainframe. Java applications created using watsonx Code Assistant for Z will still call the same data sources, such as an IMS database or CICS transaction processing system, as the original COBOL application.

    That approach will make mainframes more accessible to a wider pool of developers that know Java, which should increase the overall pace of innovation for application development, noted Charlet.

    There are billions of lines of COBOL code currently running on mainframes that, in one way or another, need to be modernized as the pool of developers that know COBOL continues to shrink. Generative AI will make it easier to quickly assess, update, validate and test code, which should accelerate code conversion efforts that otherwise would take years to complete, said Charlet.

    It’s not clear how quickly organizations might move to modernize COBOL applications, but as the time and effort to do so decreases, so should the cost of modernizing legacy code. Most organizations still running z/OS on mainframes are committed to the platform, but if they can transition to Java, the overall cost of building and maintaining mainframe applications should decline.

    In the meantime, it’s not likely that AI will replace developers. IBM recommends that developers further optimize the Java code generated by watsonx Code Assistant for Z.

    Most developers are already using some form of AI to accelerate application development. The next wave of AI will see more widespread use of LLMs that are optimized for specific tasks and that generate more reliable results. After all, the quality of any output from an AI model is always directly related to the quality of the data used to train it. The narrower the set of vetted data, the more trustworthy the AI becomes—the opportunity for erroneous data to create AI hallucinations is a whole lot less than any general-purpose AI model could achieve with customization.

  • VMware Previews Spring AI to Accelerate Java Development

    VMware Previews Spring AI to Accelerate Java Development

    At a SpringOne at VMware Explore event this week, VMware demonstrated a tool that uses abstractions to make it simpler to build Java applications that invoke multiple artificial intelligence (AI) components with minimal changes to code.

    The goal for the open source Spring AI project is to, for example, make it simpler to swap out AI models using an AiClient interface for invoking OpenAI and Azure OpenAI services. It also adds capabilities that promise to make it simpler for developers to query documentation using generative AI enabled by large language models (LLMs). An additional goal is to extend those capabilities to other Spring projects, including Spring Integration, Spring Batch and Spring Data.

    In addition, the Spring command line interface (CLI) has been extended to support Spring AI and the Spring Boot framework has been extended to help set up dependencies and classes more easily.

    The AI capabilities are part of several additions made to the widely used framework for building Java applications that address everything from automatically turning off instances of Spring running in a container, also known as scaling to zero, to using virtual threads to call external services in a way that reduces memory consumption.

    Those additional capabilities promise to make it more efficient to run Java applications in, for example, a cloud computing environment.

    Betty Junod, vice president of product marketing for modern applications and the Management Business Group at VMware, said generative AI capabilities should serve to make Spring more accessible by not having to click around as much to gain answers to questions.

    In general, VMware is betting that a larger percentage of the Java applications built using Spring will be deployed on the Tanzu platform the company has built on top of Kubernetes. That platform streamlines the application development process in a way that reduces the cognitive load on developers by eliminating the need to know how to work with YAML files or use Docker Compose to create containers.

    Despite the proliferation of alternatives to Java, it remains the primary programming language used by developers to build applications. The challenges involved with learning additional programming languages are high, so most developers would prefer to continue to use Java to build both monolithic and emerging cloud-native applications.

    In the meantime, AI is already widely employed to help developers write code faster. AI isn’t going to replace the need for developers, but it will increase the pace at which applications are being developed. As such, DevOps teams will soon see a significant increase in the amount of code moving through DevOps pipelines. The hope is that AI will be applied in a way that enables those DevOps teams to manage increasingly larger codebases.

    In fact, the way applications are built and deployed will drastically change now that the AI genie is out of the proverbial bottle. But it remains to be seen how quickly those advances will change the way DevOps is managed at a level of unprecedented scale.

  • Driving DevOps Excellence: Implementing SLOs for Your DevOps Team

    Driving DevOps Excellence: Implementing SLOs for Your DevOps Team

    In today’s fast-paced world of software development, when continuous deployment and frequent releases are the norm, DevOps teams are essential to facilitating smooth communication between development and operations. In a blog post on LinkedIn, I talked about the importance of service level objectives (SLOs) for the testing team to improve the overall product quality. On top of that, let’s look at how adding SLOs to your DevOps team can improve productivity, dependability and client happiness.

    The Role of SLOs for DevOps Teams

    • Aligning DevOps Goals with Business Objectives:

    SLOs help DevOps teams coordinate their efforts with business objectives. The DevOps team can concentrate on delivering real business value by setting precise performance indicators, such as deployment success rates or infrastructure provisioning timeframes.

    • Promoting Collaboration and Accountability:

    By implementing SLOs, several stakeholders—including development, operations, quality assurance and business teams—are encouraged to work together. Over each stage of the software development life cycle, this shared responsibility promotes a sense of ownership and accountability.

    • Driving Reliability and Stability:

    SLOs play a key role in ensuring the stability and dependability of the system. You can be sure that your services consistently fulfill client expectations when your DevOps pipeline adheres to defined SLOs.

    • Proactive Issue Mitigation:

    Monitoring and alerting systems are used together with SLOs. The DevOps team could avoid service outages and downtime by aggressively identifying possible problems and resolving them before they become more serious by regularly monitoring important indicators.

    • Data-Driven Decision Making:

    Decision-making is driven by quantitative data. With the help of such indicators, the team is able to identify bottlenecks, prioritize improvements and streamline processes based on quick feedback.

    Now, let’s explore some key areas where DevOps teams can set SLOs to improve their performance:

    1. Continuous Integration (CI):
    SLO: “xx% of builds complete within Y minutes.”
    Measurement: Monitor build times and queue times regularly.
    Action: Optimize CI infrastructure and configurations to meet the SLO.

    2. Continuous Deployment (CD):
    SLO: “xx% of deployments are successful.”
    Measurement: Track deployment success rate.
    Action: Improve the deployment process to meet the SLO and reduce deployment failures.

    3. Infrastructure Management:
    SLO: “xx% of infrastructure is provisioned within Y minutes.”
    Measurement: Monitor infrastructure provisioning time.
    Action: Optimize infrastructure provisioning scripts to meet the SLO.

    4. Monitoring and Logging:
    SLO: “DevOps tools and system uptime should be at least xx%.”
    Measurement: Monitor the availability of the DevOps pipeline, deployment system and other tooling, including monitoring and logging systems.
    Action: Ensure high availability for DevOps tools and components.

    5. Artifact Management:
    SLO: “Artifact retrieval time should be less than x seconds on average.”
    Measurement: Monitor artifact retrieval time and availability.
    Action: Optimize artifact storage and distribution mechanisms.

    6. Testing and Quality Assurance:
    SLO: “Code must have at least xx% unit test coverage.”
    Measurement: Track test coverage regularly.
    Action: Encourage developers to write more tests.

    7. Security and Compliance:
    SLO: “xx% of compliance checks must pass.”
    Measurement: Monitor the results of compliance checks.
    Action: Ensure necessary security measures to meet the compliance SLO.

    8. Standardized Tools Selection:
    SLO: “xx% of teams must use the approved CI/CD tools stack.”
    Measurement: Track the percentage of teams using the approved tools stack.
    Action: Encourage teams to adopt standardized tools and provide necessary training and support.

    9. Training and Skill Development:
    SLO: “xx% of team members should undergo relevant DevOps training annually.”
    Measurement: Monitor training completion rates.
    Action: Provide training opportunities and resources to help team members enhance their skills.

    Initially, teams should baseline which percentage values to track by observing the current state. In the event they don’t have the bandwidth to baseline, start with any reasonable arbitrary number over a period of time, and it will be automatically refined.

    Implementing service-level objectives empowers DevOps teams to focus on delivering reliable and high-performing services that meet user expectations. By setting clear performance and reliability targets, teams can proactively identify and resolve issues, leading to improved collaboration, efficiency and overall user satisfaction.

    SLOs are not rigid constraints but are a means to drive continuous improvement and foster a culture of excellence within the DevOps ecosystem. As organizations strive to keep up with the ever-changing demands of the digital world, embracing SLOs is a crucial step toward achieving DevOps excellence and ensuring a competitive edge in the market.

  • New Relic Extends AI to Identify Alert Coverage Gaps

    New Relic Extends AI to Identify Alert Coverage Gaps

    New Relic this week added additional artificial intelligence (AI) capabilities to its observability platform that make it possible to detect and resolve alert coverage gaps.

    Camden Swita, a senior product manager for New Relic, said it’s not uncommon for DevOps teams to discover an issue that the existing alerts they put in place were not designed to address. New Relic is adding machine learning algorithms at no additional cost that are designed to identify anomalies indicative of those potential issues. The platform then surfaces recommended alerts that DevOps teams can apply or further customize as they see fit, he added.

    Those machine learning algorithms ensure DevOps teams are tracking the right thresholds to ensure there are no blind spots that could adversely affect application performance, noted Swita.

    New Relic is employing both predictive and generative AI to enable DevOps team to detect and resolve issues faster. The company has been using machine learning algorithms for predictive AI for several years and, more recently, started providing early access to a generative AI tool dubbed Grok.

    The overall goal is to make the capabilities of an observability platform more accessible, Swita said. This is accomplished by surfacing issues without requiring a software engineer to craft intricate queries to interrogate metrics, logs and traces, he noted.

    The AI capabilities also serve to reduce the amount of alert noise; it’s now possible to more easily understand the root cause of an issue and reduce the total number of alerts that might otherwise be sent, he added.

    While there’s no doubt AI will help democratize DevOps by making it possible to write scripts and better manage workflows, it might be a while before DevOps teams trust the recommendations made. AI models typically require some time before they understand how an IT environment functions, and not every initial recommendation may be valid. In time, however, DevOps teams will find themselves increasingly supervising processes that AI models are executing.

    In addition, there are competing approaches to building large language models (LLMs) that drive generative AI. For example, it’s not clear whether chaining LLMs together will be more efficient than creating a single large ‘parent’ LLM that has ‘child’ relationships with smaller LLMs, noted Swita.

    In the meantime, DevOps teams would be well-advised to list tasks that are likely to be automated by AI models. Many of them will tend to be manual tasks that most software engineers don’t especially relish, so in that regard, there’s naturally a lot of interest in AI. It remains to be seen, however, whether various forms of AI might one day automate an entire DevOps workflow. In fact, most DevOps engineers are going to set a high bar for AI models that, at the very least, will be expected to perform a task as well as humans before it’s trusted completely.