A DevOps team should be able to migrate applications hosted on Amazon Web Services (AWS), Azure, or Google Cloud Platform (GCP) or on-premises infrastructure to Kubernetes environments with ease. Separate developer teams should also have the freedom to pick and choose the cloud provider of their choice — different cloud providers may offer certain niche capabilities for individual apps. In many ways, this was one of the early promises of Kubernetes as a way to scale apps relatively seamlessly, without requiring large and costly migration projects.

However, in reality, app portability across different environments can involve a number of application performance trade-offs from one cloud vendor to another — and risk.

Without touting any single tool or platform as the “one all or be all” solution for app portability, the adoption of GitOps processes and properly applying its culture has emerged as a working and suitable best practice for app portability. Best practices for using Git workflows and CI/CD as the basic building blocks to manage software delivery in native and hybrid-cloud environments play a key role. When applied correctly, this approach results in more reliable, consistent, robust, and secure deployments and their management using Kubernetes and cloud native environments. For organizations deploying applications across multi-clouds on Kubernetes, GitOps can also serve to improve automation and control for deployments across these environments.

The Git ‘Source’

GitOps can be summarized as these two things:

• An operating model for Kubernetes and other cloud native technologies, providing a set of best practices that unify Git deployment, management, and monitoring for containerized applications.
• A path towards a developer experience for managing applications; where end-to-end CI/CD pipelines and Git workflows are applied to both operations and development.

As its name implies, Git, as the cornerstone of GitOps, is often referred to as the “single source of truth” during the entire CI/CD process. Git owes its popularity as Linus Torvalds created it in 2005 as a version control system for a number of reasons, including its simplicity of use, distributed versioning capabilities, and how it tracks all changes made to code once merged to the original  (to which it largely owes its reputation as a “single source of truth”).

Git is also relied upon as a popular resource to, among other things, help DevOps teams avoid a number of problems associated with app portability between different cloud and on-premises environments. For example, Git allows developers to use different branches, tags, or feature flags to keep track of what changes belong to which environment. Git allows developers to switch deployments of entire applications or services to different hosting providers. And finally, if there are problems with a deployment, using Git as a source of truth means developers can roll back deployments to a previously good state.

However, the “single source of truth” description for a Git repository is arguably overused. Instead, a precise and demonstrable description of Git’s role in GitOps is “immutability.”

The ability to manage and compare the current state of both your infrastructure and your applications so that you can test, deploy, rollback, and roll forward with a complete audit trail using Git is what largely encompasses the GitOps philosophy and its best practices. This potential is possible because Kubernetes is managed almost entirely through declarative config and because containers are immutable. In this way, GitOps takes full advantage of the move towards immutable infrastructure and declarative container orchestration by extending some of the concepts to managing applications and their deployment.

GitOps thus serves as a consolidated and cohesive way of managing and operating cloud native infrastructure applications by using Git “where everything lives” to hold the desired state of the different cloud native workloads and infrastructure to help maintain app portability. Git serves as the immutable version of the state declaration that is automated to continuously be reconciled through controllers to become the current state of an application running on Kubernetes clusters. While encompassing GitOps best practices, Git provides a comprehensive audit of infrastructure modifications and changes to applications as they are committed, tested, deployed, rolled back and rolled forward again. This is also made possible since Kubernetes is managed almost entirely through declarative config and because containers are immutable, as described above.

The CI/CD — And More CD

CI/CD plays a central role in GitOps. The CD aspect is especially relevant to developers as they commit their code to Git, which is then tested, reviewed, and approved for deployment. This is also where CI takes over in many ways and where much of the heavy lifting of GitOps comes into play.

Reduced to its essentials, CD with GitOps represents a separation of concerns. Operators do not rely on CD to just connect specific repos to specific namespaces, but it helps to ensure that all funnels are detected — for every app on Git ported to any environment, thus ensuring app portability — and are assigned to a node, instance, and a specific environment with assigned data protections for security and compliance.

As a key requisite of app portability for CD, the operations team must obviously prepare the infrastructure before developers begin updating code on Git and applications are deployed on different clusters. This process involves bootstrapping Kubernetes and running and bootstrapping all the custom resources definitions (CRDs) in that environment. Once the GitOps toolchain installation is complete, the relevant resources necessary to execute the containerized GitOps agents, such as service accounts, RBAC, authenticators, and admission controllers, will be deployed. Thereafter, the GitOps controller is ready to reconcile the state of applications defined within the Git repositories.

For compliance, the permissions of who can run what and who has access to what data have to exist equally across all cloud platforms. Multi-cloud app portability will not work well if the permissions and security settings for compliance have to be set for each of the public cloud and on-premise vendors differently. As with any change made on Git, a GitOps agent recognizes any new permissions or security and automatically applies them to the different clusters across all cloud and on-premises environments.

Audit and compliance capabilities are also baked-in with Git repositories as every change to the system is recorded in Git logs. This embellishes the GitOps process with a clear audit trail to see what changed, when, and by whom.

CD is automated, hence application changes are distributed by the GitOps controller. This serves as another important component in how GitOps supports app portability by providing DevOps teams with the ability to take workloads from one environment to the other on Kubernetes. Thanks largely to Kubernetes’ declarative layer, the operations team can define the state of different applications from Git to run on clusters in Azure, AWS, or GCP, for example.

Once an application is ready for deployment with Git, the environment is pre-defined. This includes not only the workload — which is relatively easy to do — but the configuration of the cluster, the namespaces, and the components themselves. On the infrastructure down to the individual clusters, the definitions hosted on Git clearly show what the configuration should be.

The GitOps Way for App Portability

In summary, GitOps has emerged as the trusted process to ensure app portability across multi-clouds and on-premise environments on Kubernetes clusters. It does this by maintaining the required precision, control, and scalability that is automated — all requirements for app portability. For application updates, the state is stored in manifests describing the workloads and cluster objects. The deployment in the different target environments are reviewed, and once approved, allows for the app to be propagated and ported to the clusters in different environments. The developer teams can always move their production pipelines from one cloud environment to another since Git maintains the required immutability and consistency for the cluster, regardless of the cloud environment.

With the requisite culture and best practices in place, the right suite of tools — such as those delivered in tiers with Weave GitOps — support the CI/CD pipeline process, operations, and automation to achieve GitOps. The open source and enterprise tools offer DevOps teams a single console to deploy and manage applications and Kubernetes clusters in any environment, including hybrid clouds or on the edge. They can also automate the CD process of deploying applications from Git on any cluster — and provide observability and monitoring support.