devopsy.kinsta.cloud

Author: Mike Vizard

  • Tricentis Aquires Neotys to Gain Load Testing Tools

    Tricentis Aquires Neotys to Gain Load Testing Tools

    Tricentis announced today it has acquired Neotys as part of an effort to expand the scope of its tools portfolio into the realm of load testing. Terms of the deal were not disclosed.

    Neotys provides application testing teams with automatic test design and maintenance, user behavior simulation and root cause analysis capabilities using a set of tools that are designed to be integrated within a DevOps toolchain.

    Sandeep Johri, Tricentis CEO, said the Neotys platform will extend the scope of Tricentis’ Tosca testing platform that today enables DevOps teams to employ machine learning algorithms to test the functions within an application.

    In general, Johri said there’s now a lot more focus on load testing, thanks in part to the rise of microservices-based applications that are starting to be deployed at scale. DevOps teams are, first, trying to identify, as early as possible, a single point of failure that might bring down an application. Second, modern microservices-based applications are designed to degrade gracefully when there is no single point of failure. Identifying what issues are leading to that degradation can be challenging, given all the dependencies that might exist within a microservices-based application.

    Neotys claims to have more than 600 enterprise customers, including BNP Paribas, Dell, Lufthansa, McKesson and Verizon. Tricentis claims to have more than 1,800 customers, including McKesson, Accenture, Nationwide Insurance, Allianz, Telstra, Rockwell Automation, Moët Hennessy-Louis Vuitton (LVMH PCIS) and Vodafone. The acquisition of Neotys will reduce the number of vendors that an organization needs to engage to gain access to a portfolio of testing tools, Johri noted.

    As IT organizations embrace DevOps best practices, more responsibility for application testing is clearly shifting left toward developers. However, it’s not quite clear to what degree that shift is either eliminating or reducing the need for dedicated application testing teams at the back end of the application development process.

    At the same time, many rote testing tasks are now being automated using machine learning algorithms. Those algorithms don’t completely eliminate the need for humans to test applications, but they do significantly reduce the testing time required. They should also create more time for developers to collaborate with one another to review more complex interactions within an application that machine learning algorithms are unlikely to be able to automate any time soon.

    The amount of time organizations devote to application testing has always been constrained. As deployment deadlines approach, often the first thing that gets reduced is the amount of time allocated to application testing. In many cases, developers deliberately don’t address some known issues until the first or second update to an application that has already been deployed in a production environment.

    Of course, integrating application testing within a DevOps process enables organizations to identify more potential issues earlier when they are easier and less expensive to fix. The challenge has always been getting developers to appreciate the value of testing early and often in the application development process.

    Regardless of how application testing continues to evolve in the age of DevOps the one thing that is certain is no matter how automated it gets developers are going to be more involved than ever.

  • Solvo Automatically Crafts Cloud Security Policies

    Solvo Automatically Crafts Cloud Security Policies

    Solvo today announced general availability of a namesake tool that automatically creates a least-privilege policy and applies it to application workloads deployed in the cloud.

    Previously available only as a private beta, Solvo will also continually analyze a workload after it’s been deployed to enable IT teams to adjust security policies as additional updates to an application are made.

    In addition, Solvo is making available for free the Solvo Security Genie, which IT teams can use to identify misconfigurations, excessive permissions, privilege levels and third parties that may have access to accounts on the Amazon Web Services (AWS) public cloud.

    Shira Shamban, Solvo CEO, said the primary reason there are so many cloud security issues today is because developers – that lack cybersecurity expertise – are being asked to define policies. Solvo removes that burden by analyzing a workload and creating a cybersecurity policy before applications are deployed in the cloud. That cybersecurity policy can then be automatically applied by the developer.

    Shamban said that approach will reduce a lot of the DevSecOps tension that organizations are currently experiencing as they try to shift responsibility for cybersecurity further left toward developers. While no developer deliberately sets out to deploy an insecure application, shifting responsibility for cybersecurity to a developer who doesn’t really understand what’s required creates a lot of additional stress.

    The Solvo platform, available as a paid subscription or under a freemium model for individual developers and teams, addresses a lot of the cloud security issues that inevitably arise when infrastructure is provisioned as code by developers. It eliminates that stress by automating the creation and application of cybersecurity policies within the context of a DevOps workflows, said Shamban.

    However, a cybersecurity team can also manually edit those cybersecurity policies after an application is deployed, Shamban added.

    As DevSecOps best practices continues to evolve, it is clear the relationship between developers and cybersecurity teams needs to evolve, as well. For a long time, many cybersecurity teams viewed developers as the primary source of the problems they encountered. Getting used to the idea that those same developers are now going to solve those issues on their own requires a level of trust that will take time to build.

    Developers, for their part, are generally accepting of the idea that they should take more responsibility for security, so long as the tools provided to them are not selected by cybersecurity professionals that don’t appreciate application development workflows.

    In time, there is no doubt the cultural divide that exists between developers and cybersecurity teams will narrow. However, it’s arguable that more progress will be made, more quickly, if developers are allowed to choose their own security tools rather than accept an edict from on high mandating a specific approach. In fact, the best course of action for many IT teams is simply to offer words of encouragement to developers that elect to set an example for the rest of their colleagues.

  • Data Theorem Extends Scope of App Analyzer Portfolio

    Data Theorem Extends Scope of App Analyzer Portfolio

    Data Theorem, Inc. today added to its portfolio a Cloud Secure analyzer that promises to provide full stack visibility into applications through the client, network and cloud layers of a distributed computing environment.

    Doug Dooley, Data Theorem COO, said Cloud Secure extends an existing Analyzer Engine offering that is currently widely employed to identify vulnerabilities found in applications running on public cloud services. That enables DevOps teams to analyze application runtimes using a tool that can be integrated within a continuous integration/continuous delivery (CI/CD) platform as part of a DevSecOps workflow, Dooley noted.

    Cloud Secure now extends that capability to include the client layer for both mobile and web applications, as well as REST and GraphQL application programming interfaces (APIs) at the network layer, to provide a more comprehensive approach to attack surface management, Dooley said. That’s a crucial capability, because in modern IT environments, the single biggest attack surface is now all the APIs that need to be secured, Dooley added.

    DevOps teams can also employ multiple Cloud Hacker Toolkits, created by Data Theorem, to simulate hacks against various types of applications, including those now running on serverless computing platforms. That approach eliminates the need to rely on manual penetration tests that can’t keep up with the rate at which DevOps teams are now building and deploying applications, Dooley noted. For organizations to achieve DevSecOps, the whole security process needs to be just as automated as the rest of the DevOps workflow, he added.

    In general, Dooley said most of the results of penetration testing shared with DevOps and cybersecurity teams lack much-needed context. They may inform members of an IT team that there is a leak, for example, in an S3 bucket hosted on a cloud storage service from Amazon Web Services (AWS). However, they don’t identify what type of data is at risk. That’s critical information at a time when IT organizations need to make high-stakes decisions about where to prioritize their DevSecOps efforts.

    As developers assume more responsibility for application security, the biggest challenge organizations will face is finding security tools that can be easily integrated into application development processes that have become more extended as applications, made up of microservices, are deployed across highly distributed computing environments.

    It’s still early days as far as adoption of DevSecOps best practices are concerned, but as more tools become available, it’s becoming more feasible for organizations to make that transition from the bottom up. No developer sets out to deliberately write and deploy an insecure application. However, DevSecOps edicts issued from on high will fall on deaf ears if the developer lacks the tools required to achieve the goal. Tools that a developer embraces are going to be more widely employed than any tool that is specifically mandated by IT leaders that don’t really understand how applications inside their organization are constructed.

    Regardless of how DevSecOps is achieved, the one thing that is certain is as more applications get deployed, the probability there will be a major security incident becomes all but certain.

  • Cisco Leans on HashiCorp to Manage Infrastructure as Code

    Cisco Leans on HashiCorp to Manage Infrastructure as Code

    HashiCorp and Cisco today announced a Cisco Intersight Service for Terraform offering based on HashiCorp Terraform Cloud Business software.

    Cisco Intersight is an IT operations management platform that enables IT teams to manage IT infrastructure across a hybrid cloud computing environment. Open source Terraform tools have emerged as the dominant tool for provisioning infrastructure as code in the cloud and, increasingly, in on-premises IT environments.

    HashiCorp Terraform Cloud Business is an instance of Terraform that has been extended to include some additional security and governance capabilities enterprise IT organizations typically require.

    In recent years, Cisco has significantly expanded its presence in on-premises IT environments as many IT teams opted to deploy its servers alongside its networking equipment. Like every other provider of on-premises IT environment, Cisco has been moving to extend the reach of its management frameworks to public clouds to help foster the rise of hybrid cloud computing.

    Prior to the pandemic, most public clouds and on-premises IT environments were managed in isolation from one another. However, in the wake of the economic downturn brought on by the pandemic, more IT teams are trying to centralize the management of IT platforms as part of an ongoing effort to reduce the total cost of IT. The multiyear alliance with HashiCorp fills a major hole in the Cisco management portfolio, as Terraform increasingly becomes a de facto standard for provisioning IT infrastructure-as-code.

    Vijay Venugopal, head of product management for Cisco Cloud and Compute Software, said the alliance with HashiCorp will make it possible to provide Terraform support across a management portfolio that, over time, continues to be enhanced with machine learning algorithms that add artificial intelligence (AI) capabilities, also known as AIOps. That platform is already being employed by 6,000 customers to manage more than 600,000 servers, running primarily in on-premises IT environments, added Venugopal.

    HashiCorp Terraform Cisco

    It’s unclear how the battle for control over hybrid cloud computing will ultimately play out. While providers of on-premises platforms such as Cisco are making a case for using existing management frameworks to also manage workloads deployed on public clouds, the providers of those platforms are now extending their reach into on-premises IT environments. Cisco is, of course, betting that most organizations would prefer to extend an existing framework to achieve that goal, versus having to rip and replace existing IT infrastructure to employ an alternative framework from a cloud service provider.

    Regardless of how organizations ultimately decide to manage IT in the age of the hybrid cloud, it’s clear developers, thanks to tools such as Terraform, are exercising more direct control over IT infrastructure. Incorporating Terraform within a larger IT management framework presents an opportunity to bridge the divide between developers and IT operations teams that have historically relied on visual tools to provision infrastructure. The challenge now is finding a way for developers and IT administrators – with varying levels of programming expertise – to work more closely as management of IT environments become increasingly more complex.

  • ServiceNow Acquires Intellibot to Gain RPA Capabilities

    ServiceNow Acquires Intellibot to Gain RPA Capabilities

    ServiceNow’s acquisition of Intellibot, a provider of a robotic process automation (RPA) platform, this week is part of a larger effort to automate the development of applications that are driving digital business transformation within enterprise IT environments.

    Earlier this month, ServiceNow unfurled a set of revamped low-code tools that both professional and so-called citizen developers could employ to build applications to modernize various business processes. However, many existing business processes are either manual or paper-based. An RPA platform enables organizations to create bots that mimic, within an application environment, the way those processes are currently managed.

    Josh Kahn, senior vice president for Creator Workflow Products at ServiceNow, said ServiceNow envisions the Intelligent RPA platform as a mechanism to automate rote processes that, for one reason or another, don’t manifest themselves via a set of application programming interfaces (APIs) that application developers can easily invoke.

    Each IT team, of course, will need to decide when it makes more sense to employ bots to digitize an existing workflow versus reengineering it using a set of custom applications infused with machine learning algorithms and natural language processing (NLP) capabilities. As digital business transformation initiatives become more urgent, the application development backlog within many enterprise IT organizations that require those capabilities is steadily increasing.

    However, in some cases, an RPA platform can reduce that backlog by surfacing a set of visual tools to automate a process that doesn’t require a lot of developer expertise to effectively digitize.

    In general, Kahn said ServiceNow is making a case for building a wide range of applications on top of the same software-as-a-service (SaaS) platform many internal IT teams already employ for IT service management (ITSM). That approach enables IT teams to streamline processes as the number of custom applications that need to be both developed and, ultimately, managed, steadily increases over time, Kahn said.

    The developers of those applications might be professionals using a low-code tool instead of writing additional code to quickly build an application, or it might be a “power user” that has enough understanding of software development best practices to build an application. Regardless of who builds the application, the rate at which applications are built using low-code tools is clearly about to accelerate.

    Kahn said the next step for ServiceNow will be to embed the Intellibot RPA capabilities in the ServiceNow platform sometime after the deal closes in the second quarter. In fact, one of the reasons ServiceNow opted to acquire Intellibot is because, as a smaller startup vendor, it is easier to incorporate their RPA platform than it would be to reengineer a much larger RPA platform. However, ServiceNow remains committed to integrating with other third-party RPA platforms that are already being employed by its customers, Kahn noted.

    Regardless of how or at what rate applications are developed, the number of core technologies required to build them continues to expand. The issue IT organizations will need to come to terms with is the degree to which they want to stitch all those tools together themselves, or rely on a platform to do it for them.

  • LeanIX Extends Application Management Reach

    LeanIX Extends Application Management Reach

    LeanIX today unveiled a catalog that enables DevOps teams to more easily track the relationships between microservices as they are built and deployed.

    At the same time, the company also revealed it has acquired Cleanshelf, a provider of a platform for managing software-as-a-service (SaaS) applications.

    LeanIX CEO André Christ said the Microservice Intelligence catalog will make it simpler for IT organizations to keep track of their ongoing software development efforts, while Cleanshelf provides the mechanism for centralizing management of SaaS applications that are now widely employed across the enterprise.

    The Microservice Intelligence catalog is the latest addition to the LeanIX Continuous Transformation Platform used to manage enterprise applications. It automatically captures and correlates metadata being generated across disconnected toolchains, pipelines and Kubernetes clusters to create a 360-degree view of microservices and their dependencies, said Christ.

    In addition to being integrated with the LeanIX Enterprise Application Suite, Microservice Intelligence comes with out-of-the-box connectors for Kubernetes, Jenkins, GitHub Actions and Red Hat OpenShift platforms.

    By monitoring deployment frequencies, mean-time-to-recovery (MTTR) and failure rates, Christ noted it will become easier to make software engineering decisions based on data and insights surfaced via the Microservice Intelligence catalog. DevOps teams can also annotate the microservices recorded by the catalog to provide additional information, Christ added.

    The Microservice Intelligence catalog provides the added benefit of making it easier to onboard new developers, said Christ. Each new member of a development team can, on their own, explore the overall application environment without requiring an IT team to dedicate someone to describe it each time a new member of a DevOps team is hired, Christ noted.

    At the same time, other stakeholders, such as cybersecurity teams, can explore the application environment to better understand dependencies as well as the potential impact of a newly discovered vulnerability, Christ added.

    In general, Christ said, as application life cycle management across the extended enterprise becomes more complex it’s clear new platforms will be required to manage legacy monolithic applications, emerging microservices-based applications and SaaS applications that, in the wake of the COVID-19 pandemic, are being used to enable employees to work from home. The Cleanshelf platform, in particular, will be rebranded as LeanIX SaaS Intelligence to address that latter issue. A SaaS discovery and cataloging capability will also be made available as a free component of the LeanIX Application Portfolio Management module in the second quarter.

    IT environments have never been more distributed, and it’s clear most organizations are under pressure to reduce the total cost of IT by centralizing management functions. It’s too costly to dedicate a management platform for each type of application deployed across an extended enterprise. LeanIX is making a case for a platform that enables IT organizations to finally centralize the management of application environments.

    It’s unclear at what rate that centralization may occur, given the level of inertia that exists within most IT organizations today. However, as application lifecycle management continues to evolve, the centralization of the management of application portfolios that continue to grow is all but inevitable.

  • Progress Unveils First Update to Chef Automation Portfolio

    Progress Unveils First Update to Chef Automation Portfolio

    Progress today announced it has enhanced its Chef Enterprise Automation Stack (EAS) and released a new version of Chef Infra Client that promises to make the programming language on which EAS relies more accessible.

    Sudhir Reddy, vice president of engineering for Progress, said the latest versions of both offerings are the first updates to the Chef portfolio since Progress acquired the company last fall.

    Chef EAS combines elements of the Chef portfolio in a way that makes it easier to develop and integrate DevOps workflows that span everything from provisioning infrastructure to deploying applications. The latest update to EAS adds the ability to automatically execute compliance audits as part of any Chef Infra Client run using Chef InSpec tools. At the same time, the latest update also simplifies the implementation of the patch management processes.

    DevOps teams can also view and manage Chef Infra Server details via the Chef Automate framework. Those views, when combined with Chef Infra Client Run Reports, provide insights into the various policies and Chef objects in use on a system.


    Finally, the Chef Workstation module includes the Chef Habitat command line interface (CLI) to further simplify workflows.

    Ultimately, Progress is moving toward creating a common user experience across all elements of the Chef EAS suite of tools, Reddy said. In effect, EAS is emerging as the control plane through which the entire Chef portfolio will be managed, Reddy added.

    Meanwhile, Infra Client 17 promises to make the Chef Language underpinning that suite more accessible. It provides a streamlined developer experience as well as pre-built integrations with various cloud services. In addition, Progress is adding support for various ARM processors used in cloud services, macOS Big Sur, the Apple M1 architecture, Windows 8 and PowerShell Core.

    Progress also enhanced its ability to securely capture metadata from the Amazon Web Services (AWS) public cloud as well as capturing data from Microsoft Azure clouds.

    An early pioneer of a framework for automating IT infrastructure-as-code management, Chef is still widely employed. However, rival open source frameworks have since emerged, which Chef eventually responded to by making its core platform also available as open source software as it changed its business model. Progress today also announced it will recognize external contributors to the platform with recognition awards. Progress reports that, in 2020, there were more than 6,000 contributions from over 350 contributors in the Chef community in support of Chef Infra, Chef InSpec and Chef Habitat.

    It’s still unclear how the battle for infrastructure-as-code framework management supremacy will ultimately play out. While many developers have clearly shown a preference for rival open source tools, Progress is positioning the Chef portfolio as a framework for IT organizations that need to automate processes at scale, including how application are deployed on infrastructure that is provisioned as code.

    Of course, many rival framework providers have similar ambitions. The challenge, of course, will eventually be convincing organizations that tend to employ a wide range of tools across different departments to finally standardize on one framework versus another.

  • Eclipse Foundation Creates Adoptium Working Group for OpenJDK Binaries

    Eclipse Foundation Creates Adoptium Working Group for OpenJDK Binaries

    The Eclipse Foundation announced today a working group that will establish a governance framework for an Eclipse Adoptium project that enables developers to download compatible runtimes based on OpenJDK source code.

    Members of the Adoptium working group include Alibaba Cloud, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic and Red Hat.

    OpenJDK is a free and open-source implementation of the Java Platform, Standard Edition that is provided by Oracle. AdoptOpenJDK was created in 2017 to provide open source, high-quality Java runtimes based on OpenJDK. Since then, AdoptOpenJDK has been downloaded more than 240 million times.

    The Eclipse Foundation is now continuing that effort under an Eclipse Adoptium project that aims to become the primary source for OpenJDK-based binaries. The Eclipse Adoptium working group has negotiated with Oracle to create an OpenJDK Community TCK License Agreement (OCTLA) that will enable it to run compatibility tests to ensure conformance to the Java specification.

    Mike Milinkovich, executive director of the Eclipse Foundation, said the Adoptium WG will provide the infrastructure, marketing, community building and developer education required to ensure timely releases and adoption of Eclipse Adoptium runtimes.

    OpenJDK is a reference implementation used by multiple vendors to create their own binaries, which are only guaranteed to be compatible with the standard until the next update arrives; updates are released approximately every six months. The Eclipse Adoptium project will make it simpler for developer teams to identify which binaries are compatible with specific implementations of OpenJDK. Ultimately, the goal is to encourage developers to build applications using frameworks that make use of new OpenJDK features as they are added to the platform versus continuing to rely on older binaries.

    At the same time, however, the Eclipse Foundation is also looking at making it simpler for enterprise IT teams to rely on long term support (LTS) licensing agreements that would be based on Eclipse Adoptium runtimes, Milinkovich noted.

    Despite the plethora of programming languages developers use and even after 25 years, Java remains the dominant language for developers working in enterprise IT organizations. Over the last few years, OpenJDK has gained traction as organizations adopted an open source implementation of the specification that enabled providers of frameworks for building applications to reduce licensing costs.

    It’s not clear at what rate enterprise IT organizations are replacing proprietary editions of Java with OpenJDK. However, in the wake of the economic downturn brought on by the COVID-19 pandemic, reliance on open source software has increased to reduce costs. At the same time, many organizations are looking to build microservices-based applications using Java frameworks that are based on OpenJDK runtimes.

    Regardless of the underlying platform employed, as developers are asked to build and deploy applications faster, most of them will rely on the programming language they already know rather than take the time to master another.

  • Grafana Labs Aligns with Elastic on Observability

    Grafana Labs Aligns with Elastic on Observability

    Elastic and Grafana Labs have allied to create a plugin through which DevOps teams that are employing Elasticsearch within a DevOps workflow will be able to invoke a monitoring platform, based on Prometheus, that is managed by Grafana Labs.

    Raj Dutt, Grafana Labs CEO, said both companies are dedicating engineering resources to building and maintaining a plug-in for a service, based on open source Prometheus software, that is rapidly becoming a de facto standard for observability in DevOps environments. One of the primary reasons for that expanded usage is that Grafana Labs doesn’t require DevOps teams to move data into a central repository to analyze it, Dutt said.

    The overall goal is to eliminate the “tunnel vision” that results when relying on tools that only visualizes a narrow set of metrics, Dutt added.

    The cloud platform provided by Grafana Labs is based on open source Grafana visualization tools. The primary tool for visualizing Elasticsearch data is based on open source Kibana tools. Grafana, however, is based on a fork of Kibana, so the plug-in represents an effort to bring those two open source communities closer together. The two companies plan to collaborate on including more aggregations, broader query language support and support for space-saving constructs like rollups as the partnership evolves.

    Grafana Labs provides a cloud service that aggregates data, pulled from multiple instances of Prometheus, deployed on clusters and servers. Prometheus, especially, gained a lot of traction as organizations began to deploy Kubernetes clusters that are also based on open source software. Both Kubernetes and Prometheus are being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    Once DevOps team initially employ Prometheus to monitor Kubernetes, they frequently expand deployments to monitor additional platforms. That shift has resulted in many providers of proprietary monitoring tools to extend the data they consume to include the metrics captured locally by Prometheus. Grafana Labs claims it has more 1,000 customers, including Bloomberg, JP Morgan Chase, eBay, PayPal and Sony, for a total of more 650,000 active installations of Grafana around the globe. Existing customers of Elastic that are paying for Elasticsearch support include Cisco, eBay, Goldman Sachs, Microsoft, The Mayo Clinic, NASA, The New York Times, Wikipedia and Verizon.

    It’s not clear to what degree Grafana and Kibana might ultimately re-converge one day, but it’s clear there will be a fair amount of ongoing cross-pollination across the two projects. In the meantime, DevOps teams should be able to opt for whichever open source visualization framework they prefer alongside Elasticsearch.

    In the longer term, it’s clear greater appreciation for observability platforms that provide more context will drive a wave of consolidation among all the monitoring tools that enterprise IT teams rely on today. As part of the transition, enterprise IT teams might even standardize on a set of visualization tools that would eliminate the need to master different user interfaces. After all, the only way to actually achieve observability is through a set of tools that makes surfacing the context required easier to consume.

  • Harness Revamps User Interface for CI Platform

    Harness Revamps User Interface for CI Platform

    Harness today announced it has updated the community edition of its continuous integration (CI) platform with, among other updates, a revamped user interface.

    Formerly known as Drone.io, the latest release also adds pipeline execution visualizations, governance and security controls and live CI pipeline debugging capabilities. Harness last year acquired Drone.io, an open source CI project, to extend its existing continuous delivery (CD) platform into the realm of CI. Harness claims there are now more than 50,000 active monthly users of the community edition of Harness CI.

    Brad Rydzewski, co-founder of Drone.io, said the user interface for Harness CI will soon be applied across the entire portfolio.

    The update to the community edition of Harness CI comes at a time when the debate over how tightly integrated CI and CD platforms need to be is heating up. Harness launched a namesake CD platform before it acquired Drone.io to add a CI capability. While most DevOps teams are proficient with CI, the CD side of the DevOps equation has proven more elusive. There are now GitOps advocates that contend the rise of Kubernetes makes it more advantageous to enable a separate CD platform to pull updates from a Git repository, rather than having them pushed out by a CI/CD platform. The challenge with CD has always been that each platform on which code is deployed is unique. Kubernetes, however, now provides a de facto standard layer of abstraction that runs atop multiple platforms.

    Rydzewski said the integrated CI/CD approach will ultimately prevail, because it enables DevOps teams to more easily integrate a range of processes, including testing, that are required to consistently build and deploy applications at scale. Harness is, essentially, making a case for solving the CD challenge using a platform that encourages – but doesn’t require – a DevOps team to replace their existing CI platform.

    Regardless of how DevOps evolves, the CD issue needs to be addressed. As the enterprise becomes more extended with the rise of both cloud and edge computing, the number of platforms a DevOps team needs to support continuously expands.

    Despite the fact that DevOps teams employ CI/CD platforms, it is clear most of those organizations are not overly committed to the way they currently manage CD. It may be years before most organizations finally implement a consistent set of processes for automating application deployment.

    In the meantime, the number of organizations just starting out on their DevOps journey continues to increase. There are still plenty of instances where organizations have yet to deploy any type of CI/CD platform. It’s also worth noting that, in many cases, different DevOps teams within the same enterprise have decided to deploy different CI/CD platforms.

    Regardless of how DevOps evolves the pressure to automate is rising. The challenge many DevOps teams face today is the current platform they are relying on to automate the building and deployment of applications requires a small army of specialists relying on all too often manual processes to maintain.