I have previously discussed the characteristics of cloud-native applications in a series of posts. Readers can find the anchor post in that series at this link- https://www.vamsitalkstech.com/architecture/the-seven-characteristics-of-cloud-native-architectures/The third characteristic we had discussed was Automation for both developers and operators. Reproduced below is the third characteristic from the seven main pillars of cloud-native platforms.
Characteristic #3 They are automated to the fullest extent they can be…
The Cloud Native (CN) application needs to be abstracted completely from the underlying infrastructure stack. This is key as development teams can focus on solely writing their software and do not need to worry about the maintenance of the underlying OS/Storage/Network. One of the key challenges with monolithic platforms (https://www.vamsitalkstech.com/?p=5617) is their inability to efficiently leverage the underlying infrastructure. This as they have a high degree of dependency on it. Further, the lifecycle of infrastructure provisioning, configuration, deployment, and scaling in monolithic applications is highly manual with lots of handwritten scripts and only pockets of configuration management.
The CN application, on the other hand, has to be very light on manual asks given its scale. The provision-deploy-scale cycle is highly automated with the application automatically scaling to meet demand and resource constraints and seamlessly recovering from failures….
As the last sentence in the above stem discusses, companies that want to deploy apps faster and more frequently and reliably with the lower overhead need to employ automation across both application development and infrastructure management. GitOps, a term coined by Alexis Richardson at Weaveworks, is precisely that. GitOps is a fast and secure method for developers to manage and update complex applications and infrastructure running in Kubernetes. GitOps can be defined as both a set of best practices as well as prescriptive applications & operations workflows that enable faster and highly automated deployments for microservices-based applications. The biggest problems in deploying fleets of servers running clusters of containerized applications are roughly as follows – operators need to ensure that servers are all running golden images of OS, dependencies needed by the application including libraries/3rd party software as well as external services such as load balancers, etc. Any time the next version of an application gets deployed or a patch is provided, one has to ensure that all servers are updated. Further drift occurs in applications & infrastructure over a period of time and they need to be brought back to the desired state. As the complexity of the application grows this gets very difficult to do with manual configuration and management.
(Image Credit: Weaveworks)
Enter GitOps…
For GitOps to work in practice, your team will need these principles in place:
- Using GitOps, your entire CI/CD pipeline as well as operational & deployment configuration is stored in a Git repository along with your application code. At a high level there are atleast two main branches – first for the application source code, its config, manifests in YAML (containing k9s objects such as namespaces, pod definitions, deployment objects, ingress, heml charts etc) & the second for infrastructure configuration. The latter includes infrastructure the application needs & dependencies- monitoring, dashboards, bpm, message brokers, etc, Weaveworks used the GitOps operating model pattern with their Kubernetes environments.
- All your system and application components are versioned. Changes are controlled by Git updates. This makes Git a single source of truth and it not only describes your platform but also serves as a common change point both for developers and for operations. For teams that already use a container platform such as Kubernetes (k8s), this should be fairly straightforward as k8s is based on declarative definitions. Leading GitOps operator projects ArgoCD and Flux both ensure that the state of our live applications matches the desired state contained in Git. This versioning capability also ensures easy rollback or the ability to roll forward to match a desirable state.
- The ability for changes to be automatically & securely applied. Git provides robust security features to help enable changes to be applied to the production or live platform. This enables teams to maintain system state separately from application code. Commits to Git can be signed using ssh keys so that a reliable audit trail can be maintained. Rolling back changes becomes easy whether they are application-based or to drive cluster operations.
- Software agents that verify correct system state and alert on divergence. When you start adopting the GitOps methodology you will quickly run into tools that help you ensure that the state of your clusters is in synch with your Git repo. In the Kubernetes world, these software controllers are implemented using operators. Examples of GitOps controllers include tools such as ArgoCD and Flux. We will cover both tools in a follow-up post but the idea is very simple. The Git repository is connected through the operator (e.g. Flux operator) running on the K8s cluster itself as a pod. The operator follows a pull-based approach and polls the repo to ensure that any new CUD (Create, Update, Delete) operations are reflected in the cluster. The operator can also poll a Helm repo or a Container registry.
GitOps is a fast-maturing space that is emerging as the goto architecture pattern for cluster admins, and developers charged with developing cloud-native applications. In that light, we will cover the two most popular tools Flux & ArgoCD in subsequent posts.