BrainBlog for Robocorp by Jason Bloomberg
Cloud native computing is a new paradigm for enterprise IT that takes the cloud’s core elasticity and scalability benefits and extends them to the entire IT landscape.
At the core of this new paradigm is the declarative representation of the IT environment that represents an abstraction between the operations (Ops) team members and other users who manage and run applications and the underlying infrastructure that supports those applications.
At the heart of the cloud native movement is Kubernetes, an open-source container orchestration platform that provides rapid elasticity and massive horizontal scalability for software running as microservices in containers.
Ops personnel control Kubernetes itself via a declarative abstraction layer, which is predictably cloud native in its architecture. However, there is no requirement that cloud native infrastructure leverage Kubernetes or containers and microservices in general.
Many of today’s cloud native deployments include traditional VMs and serverless functions as well as containers, extending declarative control over infrastructure beyond Kubernetes.
As a result, there are two contrasting interpretations of the term ‘cloud native’ in everyday use – the narrower, Kubernetes-specific sense and the broader, hybrid IT-centric approach.
The conflict between these two interpretations is particularly stark within conversations about GitOps, a rapidly maturing set of best practices for implementing continuous deployment (CD) for cloud native applications.
While GitOps applies to the broader sense of cloud native in theory, it has grown to be Kubernetes-specific in practice. As a result, extending GitOps to application deployments across all of IT is becoming an increasingly important challenge.
The Challenge of GitOps
At the core of GitOps is the open-source source code management tool, Git. When implementing GitOps, the deployment team should place all declarative representations of the desired infrastructure configuration on the production environment into the Git repository.
Furthermore, there should be an automated process for ensuring that the production environment matches the state that the representations in the repository describe. As a result, if a team member wishes to deploy a new application or update an existing one, all they must do is update the Git repository, and built-in automation takes care of the rest of the deployment.
The most popular approach to implementing such automation follows the pull-based deployment strategy. Pull-based deployments depend upon an operator, which is a Kubernetes-specific software agent that continually compares the state in the repository with the actual state in production.
If there are differences between the two (what we call ‘drift’), then the operator automatically updates the infrastructure to match the information in the repository.
Much of the innovation in the GitOps space today centers on these operators. There are numerous active GitOps operator projects and commercial products, including ArgoCD, Flux by Weaveworks, Jenkins X, and Helm Operator.
The challenge with all of these products is that they are Kubernetes-specific. The underlying operator architecture is part of the Kubernetes specification.
GitOps, however, is not supposed to be Kubernetes-specific. GitOps specifies the declarative representation of infrastructure configuration and the processes that Git supports. How, then, should organizations extend GitOps to the broader hybrid IT-centric notion of cloud native computing?
Read the entire BrainBlog here.
