devopsy.kinsta.cloud

Author: Mike Vizard

  • NGINX Unveils Hybrid Application Delivery Controller Platform

    NGINX Unveils Hybrid Application Delivery Controller Platform

    NGINX this week announced it has developed a common framework for managing application delivery that can be applied across both monolithic and microservices-based applications.

    Announced at the NGINX Conf 2018 conference, the NGINX Application Platform has been rearchitected to provide traditional load balancing capabilities and a web application firewall (WAF), as well as a built-in service mesh for managing microservices and an integrated application programming interface (API) management platform.

    Sidney Rabsatt, vice president of product management at NGINX, said an update to NGINX Controller is at the heart of a much more comprehensive to approach to integrating load balancing, service mesh technologies and API management. Due out later this year, NGINX Controller 2.0 is based on a modular architecture that enables additional functions to be added via plug-in modules. The module for API management is slated for release in the fourth quarter, while the service mesh module is scheduled to become available in the first half of 2019.

    Rabsatt said it’s become clear IT organizations don’t want to replicate existing application delivery controllers just to manage microservices. There will never be such a thing as an enterprise IT environment this is made up entirely of microservices. The latest release of the NGINX Controller makes it possible to manage application delivery across the broad spectrum of applications that need to be addressed within modern IT environments, he said, noting that in effect, it’s a one-size-fits-all approach to managing application delivery via a single fabric.

    As part of that effort, NGINX this week also revealed that NGINX Plus R16, an enterprise-grade version of the core NGINX load balancing software, has been updated to apply load balancing algorithms to microservices running on Kubernetes clusters, in addition to support for Amazon Web Services (AWS) PrivateLink integration.

    Finally, NGINX announced version 1.4 of Unit, an open source web and application server that support TLS encryption, dynamic reconfiguration via an API and experimental support for JavaScript with Node.js to extend existing support for Go, Perl, PHP, Python and Ruby languages support. Full support for JavaScript and Java is planned for 2019.

    In general, Rabsatt said it’s clear organizations that have embraced DevOps are the most advanced when it comes to the need to unify management of application delivery. In fact, much of the recent success NGINX has enjoyed as of late starts with developers downloading an open source instance of NGINX to embed within their applications. As those instances of NGINX start to proliferate across the enterprise, more IT operations teams become exposed to the rest of the NGINX platform.

    It may take a while for microservices-based applications to achieve enough critical mass to force organizations to rethink their approach to application delivery. But it’s now a matter of time before organizations need to decide the degree to which they want to deploy standalone application delivery controllers and service meshes for microservices applications instead of pursuing a more hybrid approach. NGINX is clearly betting on the latter, given the number of legacy monolithic applications that will be running for years.

    — Mike Vizard

  • Perforce Acquires Perfecto Mobile to Drive DevOps Consolidation

    Perforce Acquires Perfecto Mobile to Drive DevOps Consolidation

    Perforce this week announced it plans to acquire Perfecto Mobile, a provider of automated application development tools, in a move that signals a potential wave of consolidation across the DevOps sector. Perfecto Mobile is the fifth acquisition Perforce has made in the last two years, and company CEO Mark Ties said there will be more to come.

    Schedule to close later this year, the acquisition is estimated to be about $200 million.

    The primary driver of this wave of consolidation is access to inexpensive capital coupled with mainstream adoption of DevOps processes that is requiring many startup companies to scale beyond their means, Ties said.

    As a provider of a cloud-based set of tools for automating the testing of web and mobile applications using a variety of open source frameworks, Perfecto Mobile will complement a portfolio of application testing tools based mainly on the technologies Perforce gained when it acquired PRKA earlier this year. Perfecto Mobile currently has more than 3,000 customers.

    Application testing, along with application development and deployment, increasingly is shifting to the left as developers assume more responsibility for the overall application environment. Instead of relying mainly on a dedicated team to test applications after they have been developed, companies now are continually testing modules as they are developed. Sometimes that’s done by the developers themselves, while other organizations prefer to maintain testing teams made up of individuals who did not write the code being tested. Proponents of the latter approach contend that approach leads to higher-quality code because the individuals testing the code are not as invested in how the code was written. Of course, in an ideal world, an organization would be able to embrace both approaches.

    Regardless of the approach taken, the one thing that is clear is that the rate of at which applications are being developed requires more reliance on automated testing than ever. Not only are there more applications being developed, but increasingly each one is made up of microservices. There often are multiple versions of those microservices that are subject to frequent change. To make matters even more challenging, the number of dependencies between microservices that make up an application are increasing exponentially. That means the days when organizations could rely mainly on manual testing are coming to an end.

    There may come a day when machine learning algorithms are able to play a bigger role in automating application testing and DevOps. But for now, that day is still far off. In the meantime, most organizations are still incorporating multiple approaches to automated testing into their application development processes. The issue is no longer so much about whether to automate testing as much as it is to what degree.

    In the meantime, the more acquisitions that occur across the DevOps landscape, the greater the validation of DevOps becomes as vendors scramble to extend portfolios that, in many cases, are still optimized for legacy approaches to building and deploying applications that increasingly are falling by the wayside.

    — Mike Vizard

  • Software AG Acquires Built.io to Advance Integration Strategy

    Software AG Acquires Built.io to Advance Integration Strategy

    Software AG has acquired Built.io as part of an effort to provide a multitier approach to application integration designed for different classes of developers.

    Subhash Ramachadran, senior vice president for product management at Software AG, said Built.io adds a low-code approach to integration in the form of a platform-as-a-service (iPaaS) environment developed using Node.js to a portfolio of technologies that include the webMethods platform.

    Ramachadran said the low-code approach will appeal more to so-called citizen integrators who are trying to integrate business processes with minimal intervention on the part of an IT team. Many of those capabilities are now expected to be delivered in a software-as-a-service (SaaS) model that citizen developers can invoke on demand. Built.io, for example, already provides built-in support for more than 300 applications and services. Those tools, however, don’t replace the need for a set of integration frameworks aimed at more complex tasks that require professional developers, Ramachadran said.

    Increasingly, there are large numbers of use cases for integration that simply don’t require a professional developer to accomplish, he noted. In fact, the number of use cases that can be addressed by tools such as Built.io might be substantially larger than the use cases requiring a platform the size and scale of webMethods.

    Software AG’s goal is to create a single platform to provide organizations with multiple classes of integration frameworks that can be applied to different personas within an organization, Ramachadran said. A common platform eventually would make it possible for integrations of varying skill levels to collaborate more easily.

    Those frameworks could then be plugged into any continuous integration/continuous development (CI/CD) platform to enable various Software AG integration platforms to be natural extensions of a DevOps environment, he added. The webMethods integration platform already supports Kubernetes clusters and Docker containers as a runtime environment.

    As DevOps processes continue to evolve, Ramachadran said Software AG is betting that organizations will want to make it easier for different classes of developers working with multiple types of tools to collaborate.

    To facilitate that transition, Software AG now enables everything from sharing code via GitHub to deploying micro gateways for managing application programming interfaces (APIs) within the context of a set of microservices, he noted, adding those capabilities will only become more important as organizations begin to build highly distributed internet of things (IoT) applications running on a wide variety of platforms.

    Microservices, however, create something of a paradox when it comes to integration. On the one hand, frameworks such as Built.io will make it simpler for more organizations to integrate multiple microservices and legacy monolithic applications. On the other hand, microservices are making integration more challenging for many professional developers as they continue to expand across the enterprise.

    The challenge facing most organizations will be striking the right balance between microservices and existing monolithic applications, many of which don’t naturally lend themselves to being re-engineered into a series of microservices. In fact, in many cases it may be difficult to distinguish from an integration standpoint what constitutes a microservice versus a monolithic application, so long as both can be invoked using a simple API.

    — Mike Vizard

  • OutSystems Infuses DevOps Processes into Low-Code Platform

    OutSystems Infuses DevOps Processes into Low-Code Platform

    OutSystems has turned its low-code platform into a framework for generating microservices that can run on-premises or in a variety of public clouds.

    Mike Hughes, senior director of product marketing at OutSystems, said applications generated using OutSystems 11 now can be deployed on both platform-as-a-service (PaaS) environments and container-as-a-service (CaaS) environments, including Amazon Web Services public clouds and the Pivotal PaaS based on open source Cloud Foundry software and CaaS platforms such AWS ECS, Azure Container Service, or as a set of Docker containers running on-premises.

    In addition, OutSystems 11 includes a set of monitoring tools capable of identifying issues emanating from within the applications and external dependencies, as well as a set of impact analysis tools that identify issues before an application is deployed. Those tools are critical elements of a concerted effort to apply DevOps practices and principles to the development of applications created using low-code tools, said Hughes.

    OutSystems 11 also now includes an entitlement model for controlling who can create and manage services and who can consume them, using a full entitlement model that extends to all applications and services.

    Finally, OutSystems has added support for automated risk assessments, granular access controls and activity monitoring of supplemental manual processes along with a revamped user interface.

    IT organizations of all sizes are trying to cope with a growing application development backlog by embracing low-code tools that can be employed either by professional developers to accelerate development or so-called citizen developers to create applications on their own. Legacy approaches to application development have created a gridlock issue that organizations are not going to be able to break without embracing a more modern approach to application development that combines the best of low-code application development platforms and DevOps practices, said Hughes.

    Hughes noted that more organizations than ever are trying to accelerate application development at a time when digital process transformation has become a much high priority. The rate at which new applications can be built, tested and deployed has a direct impact on an organization’s ability to compete, he said. The challenge organizations face is that much of the subject matter expertise required to build these applications resides in business units that have limited application development expertise. The central IT organization, conversely, typically has a limited number of developers available to work on applications at any one time. Rather than simply providing citizen developers with low-code tools, OutSystems is making a case for an approach to rapid application development that provides guidelines for citizen developers in a way that doesn’t create the equivalent of a black box that professional developers can’t later drill down into to determine how an application is behaving.

    It may take a while for low-code application development and DevOps processes to meld within enterprise IT organizations. But the more DevOps tools that come included with the application development frameworks being provided, the greater the chances DevOps processes eventually will pervade the enterprise.

    — Mike Vizard

  • Splunk Aims to Trigger DevOps Processes

    Splunk Aims to Trigger DevOps Processes

    Splunk this week at its .conf18 conference continued a campaign to extend the reach of its operational analytics platform into the realm of DevOps through a partnership with Puppet.

    Spunk also announced the 4.0 release of Splunk IT Service Intelligence (ITSI), which extends a platform for managing IT using machine learning algorithms by integrating it with incident management software Splunk gained via its acquisition of VictorOps. Other new capabilities include support for a set of key performance indicators (KPIs) for tracking metrics such as application workloads and the ability to do root cause analysis on any event the machine learning algorithms predict.

    Andi Mann, chief technology advocate for Splunk, said the alliance with Puppet furthers Splunk’s ambitions to be a primary source of data used to inform automation frameworks that are at the heart of any set of DevOps processes. Over time, Splunk will continue to expand its DevOps partnerships with an eye toward being the analytics platform used to trigger automated processes using frameworks developed by Puppet and others, he said.

    At the same time, Splunk continues to develop orchestration capabilities of its own based on technologies it gained via its acquisition of Phantom. While that orchestration software primarily is used today in a security management application, Mann said Splunk is now looking at applying that software more broadly, as it encouraged developers to build applications using a Splunk Developer Cloud now in beta.

    Mann said that when it comes to machine learning in IT operations, otherwise known as AIOps, the most challenging task ahead is establishing trust. IT professionals are not going to sanction a “black box” approach that doesn’t enable them to see how a machine learning framework is determining what to automate. Because of that issue, Mann said, providing a root cause analysis capability in ITSI is critical.

    The next big issue facing organizations, he noted, is improving the quality of the data being used to inform a machine learning framework. One of the benefits of the DevOps movement is that, as developers take responsibility for both building and running applications, more of them are paying attention to how log data is being created. Mann said the notes developers leave within an application on how to resolve issues are becoming more detailed, a process that Splunk refers to as “semantic logging.”

    Mann noted the goal is to create a closed-loop system where every IT issue eventually creates a ticket in a DevOps system for developers to address. The bridge between those processes will be the chat capabilities provided by the VictorOps incident management platform. In fact, Mann said Splunk is moving from being a provider of log analytics software to being a provider of a continuous monitoring solution that analyzes data both stored in logs and in near real-time using a Splunk Data Stream Processor, which is currently in beta.

    It may take a while for that loop to be completely closed. But it’s clear that many of the tools that IT operations teams rely on today are becoming increasingly DevOps-friendly.

    — Mike Vizard

  • SAP Extends Effort to Modernize App Development

    SAP Extends Effort to Modernize App Development

    SAP this week expanded the scope of the SAP Cloud Platform to include support for the ABAP programming language and made available a beta version of a Kubernetes-as-a-service offering, in effort to update its app development portfolio.

    Announced at the SAP TechEd 2018 conference, these two offerings serve as bookends for an evolving SAP strategy that seeks to include organizations that have heavily invested in ABAP over the last 20 years as well as organizations that are shifting toward employing containers to build applications based on a microservices architecture.

    Dan Lahl, vice president of product marketing for SAP, said ABAP has been widely employed by more than thousands of SAP customers to build applications using the same language that SAP employed to build its on-premises IT environment. Those applications now can be built or enhanced using an SAP Cloud platform based on a distribution of the open source Cloud Foundry platform-as-as-service (PaaS) environment.

    At the same time, Lahl said SAP is working toward hosting its distribution of Cloud Foundry on Kubernetes in addition to making available a Kubernetes-based platform alongside Cloud Foundry. SAP is also leveraging container-based technologies such as Knative and Kubeless to provide access to a serverless computing framework based on Kubernetes. That capability is also in beta.

    The SAP Cloud Platform Backend Service for generating application programming interfaces (APIs) is now available in beta, while the SAP Cloud Platform Enterprise Messaging Service—based on technology developed by Solace—is now generally available.

    Finally, SAP is making available Cloud Application Programming Model for SAP Cloud Platform, a set of framework, tools, languages and libraries based on best practices defined by SAP. Lahl noted that many of those best practices are based on DevOps methodologies that SAP is helping customers embrace as part of an effort to accelerate application development projects.

    Lahl said SAP is, for the moment, focused on modernizing the application development processes of its core developer community. ABAP support, for example, makes it possible to use a venerable programming language that most SAP customers know on a managed instance of the Cloud Foundry PaaS. But the goal is to make SAP Cloud a platform that organizations will use to build applications using multiple programming languages regardless of how many SAP applications they might have running. According to SAP, today there are more than 10,000 customers using SAP Cloud Platform.

    It’s not clear to what degree Kubernetes might supplant Cloud Foundry as a major platform for building applications in the enterprise. Lahl contended that by putting Cloud Foundry on top of Kubernetes, SAP now provides one of the richest application development tools on a platform that is rapidly becoming a de facto standard for orchestrating containers.

    It may take a while before SAP becomes a dominant provider of a platform for building custom applications. But the one thing that is clear is that SAP these days is focused on a lot more than delivering a set of packaged applications that eliminate the need to build a custom application in the first place.

    — Mike Vizard

  • Microsoft Puts Upgrade Plan in DevOps Motion

    Microsoft Puts Upgrade Plan in DevOps Motion

    Microsoft this week at its Ignite 2018 conference made it clear DevOps teams will have their hands full upgrading both databases and operating systems this Fall.

    Erin Chapple, corporate vice president for Windows Server, announced Windows Server 2019 will become generally available next month. As is the case with Windows Server 2016, there are three editions: Standard, Data Center and Essentials. The latter offering is for small businesses.

    However, the suite of management tools the company provides for its operating systems will not be available until early next year.

    Microsoft is putting the finishing touches on Windows Server Software Defined (WSSD) 2019, which provides another approach to combining compute, storage and networking on top of a hyperconverged infrastructure platform. That offering is expected to come bundled on a wide variety of hardware platforms early next year. Organizations looking to shift from a legacy rack-based approach of managing their data centers to a more modern HCI approach will have to wait for WSSD 2019 to become available.

    The company is simultaneously pushing forward with a public preview of Microsoft SQL Server 2019. In addition to adding support for faster queries and persistent storage in memory, Microsoft SQL Server 2019 packages the Hadoop Distributed File System and Apache Spark in-memory computing framework with a relational database. Microsoft is also making it possible to run SQL Server 2019 on Kubernetes clusters running on either Linux or Windows deployed on-premises or in the cloud. While the company has broadly embraced Kubernetes, its support for Kubernetes on Windows Server is not expected to be generally available until 2019.

    Microsoft also announced that a General Purpose service tier for the Azure SQL Database Managed Instance is slated to become available next week. That capability gives DevOps teams the option to deploy SQL Server databases either in a public cloud or on-premises.

    Microsoft touts the ability to run Windows Server on-premises and in the cloud as a core element of its hybrid cloud computing strategy. Right now, however, the most widely employed platform running on the Azure cloud is Linux. The company is also pushing another approach to hybrid cloud computing based on Microsoft Azure Stack, an on-premises edition of the cloud framework the company employs to drive its public cloud. An edition of Kubernetes is available in beta on Microsoft Azure Stack as well.

    Microsoft earlier this month revamped its AzureOps tools to make it easier to manage all those variations on its public cloud. But those tools have yet to be extended to on-premises environments.

    Of course, there’s no requirement that says any approach to a hybrid cloud using Microsoft technologies requires Azure. Windows Server and SQL Server both are already widely deployed across multiple public clouds. The challenge DevOps teams will face is managing all the different versions of Microsoft operating systems and databases that potentially will be strewn across an extended enterprise. It’s unlikely any organizations will be able to upgrade operating systems and databases in one wholesale effort.

    — Mike Vizard

  • Pivotal Software Extends Development Platform Reach

    Pivotal Software Extends Development Platform Reach

    Pivotal Software announced an expansion of its implementation of the Cloud Foundry platform-as-a-service (PaaS) environment in addition to extending its support for Kubernetes to the Amazon Web Services (AWS) public cloud.

    At its SpringOne Platform 2018 conference, Pivotal revealed that Pivotal Cloud Foundry (PCF) can now extend a single instance of its distribution of the open source PaaS across multiple data centers. In addition, Pivotal is making it possible to automatically update the operating systems on which its PaaS is hosted, and added a more extensible user interface to its PCF Healthwatch monitoring tool.

    What’s more, Pivotal announced that Pivotal Container Service (PKS), its implementation of Kubernetes, now can be deployed on EC2 instances of the Amazon Web Services (AWS) public cloud. PKS is currently based on version 1.11 of Kubernetes that has been packaged with a software-defined runtime for spinning up clusters known as Kubo, developed under the auspices of the Cloud Computing Foundation (CFF), which also oversees Cloud Foundry. PKS was developed in collaboration with VMware, which is a sister company of Pivotal operating under the same Dell Technologies umbrella, and the latest version adds the ability to configure a namespace or cluster to emit logs to a specific destination, such as VMware vRealize Log Insight, without operator intervention.

    Richard Seroter, senior director of product for Pivotal, said Pivotal and VMware are collaborating to make Kubernetes clusters more accessible to enterprise IT organizations that typically don’t have engineers available to manage IT operations. By combining automation frameworks from VMware and Pivotal, the expectation is that PKS will gain more traction as IT organizations evaluate which flavor of Kubernetes to deploy in a production environment, he added. A recent research report published by the Cloud Native Computing Foundation (CNCF) would suggest that strategy is starting to gain traction.

    Pivotal apparently is pursuing a dual application development strategy. The first is based on a PCF framework that is highly prescriptive in terms of how applications should be built and deployed. The second is a more flexible container-as-a-service (CaaS) platform based on Kubernetes.

    In general, organizations that have invested in Cloud Foundry to deploy a PaaS are not likely abandon it in favor of a container platform overnight. But Pivotal and the CFF are under some pressure to be more aggressive in unifying Cloud Foundry and Kubernetes: There already are several instances of Cloud Foundry that run on top of Kubernetes, and Pivotal Software revealed earlier this month that it missed Wall Street’s expectations for billing revenue in its most recent quarter by 25 percent.

    It may take a while for the relationship between Cloud Foundry and Kubernetes to become more firmly established in the minds of IT professionals. But there are certainly no shortage of options when it comes to developing modern applications—there will be more than a few organizations employing multiple frameworks for building these applications for many years to come. The real issue may lie in deriving value from those investments.

    Survey findings published this week by Pivotal revealed that only 39 percent of global organizations are deploying code on a continuous, hourly or daily basis and only 40 percent deploy code on a monthly, quarterly or annual basis. The survey also found that only 35 percent of developers’ time is spent writing code for new products or features to deliver value, as opposed to maintenance or fixing old code. Also, one-third of U.S. respondents (33 percent) reported delaying application releases more than 11 times due to security concerns, compared to 21 percent globally. Clearly, there is much more DevOps work to be done.

    — Mike Vizard

  • Kong Inc. Defines Services-Centric Approach to Integration

    Kong Inc. Defines Services-Centric Approach to Integration

    Kong Inc. has released a feature-complete version of its namesake services broker for legacy and microservices-based applications that promises to eliminate the need for legacy application programming interface (API) management platforms.

    Company CTO Marco Palladino said traditional API management platforms, for all intents and purposes, are now dead. Formerly known as Mashape, the core technology developed by Kong Inc. has been widely employed to manage APIs. But the time has come to focus on managing services at a much higher level, he said.

    Despite Kong having been downloaded more than 45 million times, the latest version is being labeled a 1.0 release because the open source service broker has now been deemed to be feature-complete, which includes support for service mesh patterns, Kubernetes Ingress controller and backward application programming interface (API) compatibility to future releases, Palladino said.

    Kong is being positioned as a microservices API gateway capable of supporting sub-millisecond response times in a way that would not be possible to achieve using legacy API management platforms that reside in the cloud or in a local data center. Kong can be deployed on-premises or in public clouds based on virtual machines, Kubernetes or bare-metal servers. That approach makes it possible to employ Kong to manage services regardless of where they run. Kong has also developed a “Kong Brain” function that employs machine learning algorithms to optimize the flow of data traffic between services that has increased dramatically in the last few years, Palladino said.

    Palladino noted that while service meshes exist specifically for Kubernetes clusters, most enterprise IT organizations will require an approach to managing services across legacy monolithic applications and emerging microservices-based applications that are based on multiple types of runtime environments and serverless computing frameworks. Over time, Kong will integrate with various platform-specific service meshes as they emerge to further enable a more comprehensive approach to services lifecycle management, he said, adding that Kong automatically configures itself to serve traffic to new applications as they are deployed and new services are created.

    In addition, organizations can migrate from one service to another based on a different databases schema without incurring any downtime.

    When it comes to managing services, Palladino said there’s still too much focus on tribes that have emerged around specific platforms that wind up polarizing the IT industry. IT organizations clearly need a means to broker services regardless of where they run or might have originated, he said, noting API management could be viewed as a stepping stone toward achieving that goal.

    It’s not clear yet whether legacy approaches to API management are truly dead or simply in the process of transforming into a means for managing services at higher levels of abstraction. Regardless of the outcome, it’s clear that a less brittle approach to managing integration in the age of microservices will be required. Many forget, however, that in most cases a monolithic application is now just another type of service.

    — Mike Vizard

  • CloudBees Extends CI/CD Scope, Reach

    CloudBees Extends CI/CD Scope, Reach

    CloudBees, at its DevOps World | Jenkins World 2018 conference this week, unveiled a broad strategy to extend the reach and scope of continuous integration/continuous deployment (CI/CD) platforms based on the open source Jenkins software.

    Company CEO Sascha Labourey said CloudBees Suite will provide the equivalent of a customer relationship management (CRM) application for software delivery. That approach will not only accelerate application development processes, but also provide application stakeholders across the enterprise with more visibility into DevOps processes. For example, business executives are demanding more visibility into DevOps processes as the organization begins to appreciate how dependent it is on the timely delivery of software, Labourey said.

    Rather than buying isolated components of a CI/CD platform, the CloudBees suite provides a single pane of glass through which all the elements of the platform can be managed. That capability is critical because it enables an organization to start with one element of a CI/CD platform that, over time, can be expanded frictionlessly as the organization becomes more comfortable with DevOps processes.

    Labourey said it’s clear the CI/CD platform is the hub around which those DevOps process revolve. The CloudBees Suite includes CloudBees Core to unify the management and governance of pipelines, which includes limited availability of the Kube CD for extending the CloudBees platform to Kubernetes clusters. In fact, Labourey noted that Kubernetes is rapidly emerging as the foundational element of a federated approach to CI/CD in the age of microservices.

    CloudBees also announced an alliance through which Lenovo will provide IT organizations a turnkey set of servers running instances of CloudBees Core on the Red Hat OpenShift application development platform. As DevOps continues to evolve, Labourey said, organizations want to reduce the amount of time it takes their IT teams to deploy the infrastructure required for a modern application development platform.

    Another core element of CloudBees Suite is CloudBees DevOptics, a software-as-a-service (SaaS) application that provides visibility and insights into value streams and operations as well as continuous reports on the four key DevOps metrics. CloudBees DevOptics will provide the raw data the company will rely on to apply artificial intelligence (AI) in the form of machine and deep learning algorithms to the CloudBees CI/CD platform, Labourey said.

    The two remaining core modules of CloudBees Suite are CloudBees CodeShip, which enables organizations to jump start projects using a CI/CD as a Service offering, and CloudBees Jenkins Support, which provides users of the open source Jenkins platform full support. CloudBees is also making support for instances of Jenkins available as a standalone subscription service.

    It’s clear that CloudBees is trying to extend the reach of its widely employed CI/CD environment not only to new platforms, but also to new users. As digital business processes continue to proliferate across the enterprise, there is now a lot more at stake whenever an application development project is delayed. While such delays may be inevitable, the degree to which organizations might be surprised by those delays can be reduced sharply when everyone in the organization is operating on the same DevOps page.

    — Mike Vizard