Author: Mike Vizard

  • 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.

  • CDF Report: Steady Growth in Number of Jenkins Jobs Run

    CDF Report: Steady Growth in Number of Jenkins Jobs Run

    The Jenkins project that operates under the auspices of The Continuous Delivery Foundation (CDF) reported this week that over a two-year period, usage of pipelines grew 79%, with total workloads defined in the continuous integration/continuous delivery (CI/CD) platform growing 45% over the same period.

    Based on analysis conducted from June 2021 to June 2023, the report found the number of jobs defined increased from 27,105,176 jobs to 48,625,398 jobs per month. The number of all jobs defined on Jenkins increased from 50,785,205 to 73,746,418 jobs per month (45%).

    Sacha Labourey, a member of the governing board for the CDF and chief strategy officer at CloudBees, a provider of commercially supported instances of the open source Jenkins CI/CD platform, said it’s clear that more applications are being constructed by more organizations than ever using DevOps workflows.

    At present, the CDF reported there are now more than 600 active contributors to the Jenkins project. That level of support has made it possible for Jenkins to become a standard CI/CD platform. DevOps teams know there is a substantial open source community they can count on for support, said Labourey.

    The challenge now is how to centrally observe DevOps workflows to accelerate application development while at the same time giving developers more freedom to innovate. Platform engineering principles represent an opportunity to achieve that goal, as long as developers still have an opportunity to innovate and collaboratively address bottlenecks in DevOps workflows as they occur.

    The platform engineering team should be observing processes and proactively making recommendations and define a set of guardrails that ensure DevSecOps best practices are followed, he added.

    Otherwise, application developers are likely to view platform engineering as another effort by centralized IT teams to take power away from the developer, noted Labourey.

    Striking that balance is especially critical as the number of cloud-native applications being built and deployed alongside classic monolithic applications has significantly increased, he added. DevOps teams need to be able to centralize observability of what are two distinct styles of application development that tend to occur at a significantly different pace from one another, Labourey said.

    Hopefully, advances in artificial intelligence (AI) will make it easier for DevOps teams to strike the right balance between management and innovation. In the meantime, however, as the pace of application development continues to accelerate, each DevOps team will need to determine how best to evolve their existing workflows. That’s especially critical at a time when economic headwinds are requiring organizations to find ways to increase existing developer productivity rather than hire or contract additional developers.

    In the meantime, it’s apparent that DevOps, as a methodology for building and deploying applications faster, is here to stay. The next major challenge is finding a way to achieve that goal at levels of scale that require automation everywhere from the network edge to the cloud.

  • Gremlin Adds Detected Risk Tool to Chaos Engineering Service

    Gremlin Adds Detected Risk Tool to Chaos Engineering Service

    Gremlin today added a risk detection capability to its chaos engineering service that automatically identifies issues that could cause outages along with recommendations to resolve them.

    Enabled by agent software deployed in an IT environment, the Detected Risk tool makes it possible to benefit from chaos engineering techniques without needing to construct experiments or run reliability tests.

    Gremlin CTO Kolton Andrus said that approach eliminates much of the friction that previously limited adoption of chaos engineering best practices to improve the resiliency of IT environments.

    Chaos engineering is rooted in a resiliency testing philosophy that posits applications should be able to keep functioning regardless of any service or infrastructure failure. Most IT organizations, however, don’t have the expertise required to build the tools required to test resiliency based on the “Chaos Monkey” principles—pioneered by a Netflix project by that name—that, for example, randomly turns services off to see if an application fails.

    Each DevOps team will need to evaluate Gremlin’s recommendations before implementing them, but the overall goal is to provide IT teams with a better understanding of the level of risk attached to, for example, a misconfiguration of a server. To do so, the tool uses a scoring mechanism provided by Gremlin, noted Andrus.

    The challenge is that as IT environments become more complex, the level of dependencies between applications and infrastructure continues to increase. It’s often impossible for DevOps teams to manually keep track of all the hidden dependencies that might exist when IT environments are continuously being updated.

    In theory, of course, adopting cloud-native applications based on microservices should make IT environments more resilient as calls to application programming interfaces (APIs) are rerouted in the event of an outage. Nevertheless, there are almost always dependencies that get overlooked as these applications evolve, which creates a potential single point of failure.

    Naturally, not every IT team is always comfortable with the concept of deliberately breaking things to better understand what issues might cause an outage. As organizations become more dependent on software to drive critical processes, however, a more proactive approach to ensure resiliency is required, added Andrus.

    In fact, business leaders are becoming less tolerant of outages that result in lost revenue, so DevOps teams are being held to a higher level of accountability. DevOps teams may appreciate the value of a blameless culture that encourages everyone to learn from their mistakes, but IT leaders still get fired when there are too many outages, noted Andrus.

    Less clear is the degree to which the rise of artificial intelligence might affect chaos engineering. At the very least, AI models should make it easier to assess levels of risk, but the cost of using those technologies to achieve that goal is substantial, especially when platforms that provide the same outcome already exist.

    Regardless of approach, however, when it comes to resiliency, everyone agrees that the value of application uptime is now beyond measure.

  • Apica Acquires LOGIQ.AI to Unify Observability

    Apica Acquires LOGIQ.AI to Unify Observability

    Apica, a provider of a synthetic monitoring and observability platform, has just raised an additional $10 million in funding and has agreed to acquire LOGIQ.AI. LOGIQ.AI is a provider of a data fabric infused with machine learning algorithms.

    Jason Haworth, chief product officer for Apica, said the data fabric developed by LOGIQ.AI will be incorporated into the Apica Ascent platform in the third quarter. The LOGIQ.AI addition will apply artificial intelligence (AI) in a way that both optimizes and enriches data collected by the company’s observability platform.

    At the core of the Apica Ascent platform is an indexing engine built on top of a Kubernetes platform that aggregates data such as logs, traces and network packets from multiple sources. As part of that process, the platform reduces storage costs by trimming excess data that can be stored in a data lake it provides or a third-party data lake a customer prefers.

    At the same time, Apica also enables DevOps teams to both normalize data collected from multiple sources and enrich it to add additional context, said Haworth.

    The overall goal is to provide a unified view of all IT data to accelerate faster root cause analysis and reduce the total cost of collecting the data required, he added.

    Apica is making a case for an observability platform that goes beyond collecting data from DevOps platforms. As IT environments become more complex, IT teams need to be able to correlate data collected from a wide range of data sources to accurately determine the root cause of an issue, said Haworth.

    The challenge is managing the massive amount of data that needs to be continuously collected, stored and analyzed to achieve that goal, he added. The acquisition of LOGIQ.AI will enable Apica to embed a data fabric that employs machine learning algorithms and other data science techniques to make it feasible to observe complex IT environments at scale, noted Haworth.

    It’s still early days as far as observability is concerned, but it’s clear that IT teams need to move beyond monitoring a pre-determined set of metrics to manage complex and dynamic application environments. The rate of change to application environments as updates are made requires an ability to query data to determine the root cause of issues that could be caused by any number of dependencies.

    The issue is that even when IT teams have access to an observability platform, they may not have the knowledge and expertise required to craft the queries needed to determine the root cause of an issue. Machine learning algorithms will play a major role in enabling IT teams to proactively discover issues that they can investigate using the suggested queries.

    It’s only a matter of time before most IT organizations unify observability data within a single platform. That will make it simpler for them to collaborate across teams and should result in fewer disruptions as IT issues are discovered more quickly. After all, the best kind of IT incident is the one that never happened or that was too trivial for anyone outside of IT to even notice.

  • Styra Makes Source Code Available for Enterprise Edition of OPA

    Styra Makes Source Code Available for Enterprise Edition of OPA

    Styra is now making the enterprise edition of the Open Policy Agent (OPA) available under a source license that enables IT teams to modify or change the underlying code as they see fit when integrating it with other applications.

    Enterprise OPA is a drop-in replacement for OPA, agent software for implementing policy-as-code that is already available under an open source license. Styra’s enterprise edition provides access to a version that provides better performance, native integrations for a suite of data sources and additional capabilities such as policy decision analysis.

    Previously, Enterprise OPA was only available in either a binary or container format. While these formats enable Enterprise OPA to be widely used, they limited it from being built directly into applications for performance optimization because no access was provided to source code.

    Chris Hendrix, director of product management for Styra, said the source license also provides organizations with an assurance that they will be able to continue to modify Enterprise OPA in much the same way as they modify the open source edition.

    It’s not clear how many DevOps teams are managing policy-as-code within their pipelines, but as application security regulations become more stringent, it’s only a matter of time before most of them do so in one way or another. Styra’s approach relies on a Rego programming language that some DevOps teams have found challenging, however. To make it simpler, the company is working on a low-code approach that would help make Enterprise OPA more accessible, said Hendrix.

    In addition to encouraging more DevOps teams to use Enterprise OPA under a source license, Syra is clearly moving to make it more attractive to replace existing instances of OPA with a more robust implementation licensed from the company. No one knows how many instances of the open source edition of OPA advanced under the auspices of the Cloud Native Computing Foundation (CNCF) are running in production environments. But as those applications become more complex, the need for deeper levels of integration enabled by a faster version of OPA becomes more apparent.

    OPA enables developers to programmatically embed compliance controls without waiting for a compliance team to make them available. That ultimately makes it simpler to ensure that the proper controls have been implemented before an application is deployed in an on-premises IT environment. That capability also makes it easier to document which controls have been applied to make any audit less time-consuming.

    Shifting responsibility for compliance controls to the left also enables DevOps teams to better understand which controls address specific regulatory mandates incorporated into most applications versus which controls might be specific to a specific regulation. Armed with those insights, it then becomes simpler to incorporate policy-as-code within a DevSecOps workflow.

    Hopefully, more applications running in production environments will soon be secure by default. Naturally, one of the first places to start is by making sure the compliance controls needed to achieve a baseline level of security have been pervasively implemented.

  • 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.

  • 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.

  • IBM to Provide Hybrid Cloud Service Based on VMware Cloud

    IBM to Provide Hybrid Cloud Service Based on VMware Cloud

    At the VMware Explore 2023 conference this week, IBM announced that it will soon provide a fully managed service based on a streamlined edition of VMware Cloud.

    Brendan Kinkade, vice president for independent software vendors, technology and hybrid cloud partnerships for IBM Global Sales, said VMware is now making available editions of VMware Cloud that are both easier to deploy and manage and, just as importantly, migrate between cloud platforms and on-premises environments as IT teams see fit.

    IBM is committed to using that platform to deliver a managed VMware Cloud service that will span hybrid cloud computing environments aligned to an NIST-validated framework, he added. That approach is critical because it will enable IT teams to apply VMware license credits to any instance of VMware Cloud no matter where it is deployed, noted Kinkade.

    In addition, the streamlined edition of VMware Cloud doesn’t use proprietary application programming interfaces (APIs) to make it simpler to port IT environments to another cloud service or back to an on-premises IT environment whenever necessary, he added.

    At the foundation of the hybrid cloud service will be an instance of a multi-tenant vCloud Director console residing on the IBM Cloud. Through the console, IT teams will be able to work with IBM to co-manage application environments.

    In addition, IBM is providing a managed IBM Cloud Cyber Recovery (ICCR) Service to better secure cloud computing environments.

    It’s not clear how much of IT is now being consumed as a managed service, but the COVID-19 pandemic has certainly increased that number. Many IT organizations are also finding it simpler to rely on a managed services provider (MSP) to manage infrastructure so they can focus more of their time and effort on application development, noted Kinkade.

    MSPs are also in a better position to aggregate all the telemetry data needed to train artificial intelligence (AI) models that will be used to automate workflows, he added.

    Exactly how DevOps workflows will evolve as organizations rely more on external service providers to manage IT infrastructure is, naturally, a work in progress within many organizations. The main challenge is aligning a unique set of continuous delivery (CD) practices for deploying and updating applications with a provider that has already defined its own workflows.

    Nevertheless, given the complexity of those environments, many organizations are not able to hire and retain the IT expertise required to manage it, so the only option may be to rely on an MSP.

    Each IT organization will need to decide whether to rely on an MSP, given the total cost of a service. Many organizations often wind up having a mix of workloads managed by internal IT teams and external service providers. The one thing that is certain is that as the pace at which workloads are being deployed in the cloud increases, many internal IT teams are overwhelmed by a level of complexity that will only increase.