Why huge cloud and telecom vendors have invested millions in a GitOps startup

Ask business and IT executives what GitOps means and you might get a perplexing reply about prodding a horse ("no, Git-Ops, not giddy-up") rather than something about IT automation. We can excuse people for not knowing the latest tech marketing jargon since they have better things to do than play buzzword bingo. Nonetheless, GitOps, a portmanteau of "Git" as in the popular source code version control system and "Ops" as in IT operations is an increasingly popular extension of DevOps methods to application and infrastructure automation. GitOps is a form of Infrastructure-as-Code (IaC…do we have a bingo?) since both use source code syntax to describe infrastructure configurations and deployment tasks, but GitOps, which is primarily a marketing creation of Weaveworks, has evolved into a discipline focused on cloud-native, containerized applications with the following elements:

• Kubernetes clusters on one or more public and private cloud environments
• Git as a source of application, integration, testing and infrastructure code
• A continuous integration and delivery (CI/CD) process and software to automatically pull, build, test and deploy new code (whether an application or Kubernetes infrastructure)
• A monitoring system and feedback loop to keep deployed applications and systems in sync with the Git repository that is the 'single source of truth' for the entire system

As a platform-agnostic application delivery mechanism, GitOps seeks to deliver on the cross-platform, multi-cloud flexibility long promised by Kubernetes evangelists. Although cloud vendors have hampered such application portability via their managed Kubernetes products, e.g. AWS EKS, Azure AKS and Google GKE, with custom features and integrations to their proprietary services, they are each built on open-source Kubernetes. GitOps products smooth out any inconsistencies and proprietary obstacles via an intermediary abstraction layer that manages the configuration and security policies of each environment from a single source.

GitOps and business

Until recently, the details of GitOps were just so much technical gibberish, meaningful only to developers hanging out on Sourceforge. However, the nexus of enterprise Kubernetes environments and multi-cloud deployments has attracted businesses seeing GitOps as a solution to the vexing problem of ensuring consistent delivery of hyper-distributed applications across heterogeneous centralized (hyperscale) and edge (remote, 5G) environments.

Indicative of its nascent status, most GitOps tools are open-source projects that are often offshoots of established CI/CD software. Flux, which was created by Weaveworks and is now an incubating project at the CNCF, is probably the most popular option and is the basis for the Weave Cloud SaaS product. Weaveworks' GitOps advocacy is finally paying off since it recently received a sizable vote of confidence from several huge cloud and telecom companies.

In early December, Weaveworks completed a Series C funding round, raising almost $37 million, including investments from AWS, Ericsson, Orange Ventures and two others to go with additional funding from its initial VC backers, bringing its total funds raised to $60 million. Ericsson's VP of Corporate Development explained its investment as an effort to speed its transition to hybrid-edge services, writing:

We are working with dozens of the world’s largest communications service providers to deliver more sophisticated consumer services using containerized 5G services. We are investing in Weaveworks to accelerate the shift to software-defined services that work across data centers, cloud, hybrid cloud and edge environments.

Similarly, the investment manager for Orange Ventures justified its funding as a way to promote GitOps as "a reliable, secure and standards-based operating model" for cloud-native applications running on Kubernetes. All of Weaveworks' investors appear to concur with its assertion that cloud infrastructure and services have catalyzed changes in the way developers design and build applications. Specifically, Weaveworks cites three trends behind the need for GitOps automation.

1. Cloud-native (code for containerized, Kubernetes-hosted) applications have become the standard development and operating model for most organizations.
2. Containerization and Kubernetes are seen as enabling necessary portability across public clouds and between centralized and distributed (edge) environments spanning hyper-scale data centers to 5G base stations and vehicles (cars, trucks, ships).
3. The only way to keep up with an accelerating need for applications to serve every new business service and process is through significant improvements in developer productivity.
4. Similarly, delivering these new applications without exploding the cost of IT requires equally substantial increases in operational efficiency via end-to-end automation like that provided by GitOps. Indeed, programmatic automation is the only way to scale software output in light of two conflicting factors: the need for IT cost control and a persistent shortage of skilled cloud developers and engineers.

Weaveworks and its investors see GitOps as the way to standardize software delivery workflows in the cloud era while simultaneously preparing organizations for new edge deployment environments. Indeed, it argues that:

[A software automation] platform must address both sides of the DevOps coin -- operations automation and developer productivity. 5G reinforces the need for this new platform.

Weaveworks isn't the only company targeting an incipient GitOps gold rush. Red Hat has an OpenShift GitOps add-on that uses Argo CD and Red Hat OpenShift Pipelines CI/CD to automate GitOps workflows for cluster configuration and application delivery.

System overview

Treating infrastructure-as-code, i.e. via systems like HashiCorp Terraform, Red Hat Ansible Automation Platform, AWS Cloud Development Kit (CDK) and others, allows using a code-management system like Git as a single repository for application, testing, deployment and management instructions. The following diagram shows the GitOps process flow.

Missing from the chart is a critical element of GitOps: intent-based state enforcement. Much like intent-based network management software (see my overview here), GitOps includes "diff" and "sync" software that compares the existing state of a system —  e.g. application code revisions, cluster configuration, network ACLs, etc. — with the desired state as expressed in the Git repository. A GitOps system uses monitoring and feedback to automatically bring deployed drifts into agreement with the desired configuration.

Another critical GitOps capability is infrastructure portability that allows developers and operations teams to write cloud-agnostic code that is automatically adapted to the targeted cloud environment at deployment time. The ability to target different cloud environments from a single source tree doesn't just protect against vendor lock-in, but more importantly, facilitates delivering the same application to a diverse set of platforms such as emerging edge environments (like Vapor IO's INZONE that I detail here) and internal test-and-development systems.

My take

GitOps might be an awkward, unnecessary buzzword but it describes an avoidable requirement for organizations creating the next generation of distributed, cloud-native applications compatible with an assortment of cloud and edge environments. Runtime heterogeneity is reason enough for end-to-end automation, but something like GitOps is critical in an era where people with requisite expertise are in short supply and when IT organizations are expected to deliver vastly more services with little extra budget.

Although software like Weaveworks' addresses the technical side of GitOps via an automation platform and system integrations, it doesn't tackle the persistent problem of personal and organizational inertia. Such resistance to change hampers efforts at transforming employees who might have defined their worth by the administrative tasks they performed into infrastructure developers. Furthermore, this new generation of IT operations requires engineers that think on a different, higher level of abstraction and are capable of reducing manual steps and idiosyncratic configurations into generalized instructions compilable into infrastructure-specific instructions by a GitOps platform.

Given the time and effort required to conquer such cultural and institutional barriers, application and IT leaders should start planning for a DevOps-GitOps future long before a flood of new applications creates an operational crisis.