How GitOps Offers a Direct Path to Self-Service for Developers

The DevOps Research and Assessment group (DORA) in its State of DevOps Report 2020 clearly describes how self-service platforms can level the playing field for organizations seeking ways to simplify and expedite cloud native deployments and operations. With the adoption of GitOps, the inherent structure is largely in place for developers to rely on a self-service approach to commit application code — minus the complexity associated with having to spend inordinate amounts of time working with operations teams to configure Kubernetes clusters. A self-service model that GitOps optimizes offers the underlying process for CI/CD to support organizations’ digital transformations with fewer resources, without reneging on security and application robustness.

If you are reading this article, it is highly likely that you are using or will use Git as a version control repository — usually GitHub or GitLab. Eponymous GitOps serves as a consolidated and cohesive way of managing and operating cloud native infrastructure applications by using Git “where everything lives.” It holds 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 configuration and due to the immutable nature of containers. The applications are deployed, monitored, and reconciled with Git serving as the “single source of truth” through the CI/CD process.

SEE ALSO: “We’ve essentially created a massive sandbox for cyber criminals to play in”

Say Goodbye to Job Tickets

GitOps is structured for a self-service model in such a way to allow developers to push configuration to a Git repository that then is applied to the cluster in an automated way. With the traditional way of doing things — which sadly remains the case for many, if not most, DevOps teams — a developer or engineer must raise a job ticket to request certain resources and infrastructure requirements to commit or update an application. Once issued, the operations team must manually assess the ticket, determine the infrastructure requirements, and then request another manual signoff from certain stakeholders. A typical scenario can involve back-and-forth exchanges between the different teams requesting changes to the initial ticket, such as delaying the time to propagate changes to the production environment. Needless to say, the process is time-consuming and can take days or even weeks to complete.

With the traditional job-ticket process, the developer may also come back with customization requests. Similar requests can also keep coming from other developers, and the operations team can become stretched too thin to meet all these requests.

The self-service menu through GitOps removes many of these time- and resource-sapping steps for CI/CD. For the developer, infrastructure options are made available for declarative configuration — usually with YAML — for application deployment. Pull requests are merged so developers can monitor that the change comes into the system.

Once committed on Git and then tested, the CD process begins and so does the automaton for the CD pipeline. This is also where software agents come into play that are deployed to Kubernetes prior to application deployments. These controllers — with Weave GitOps Enterprise serving as an option to manage GitOps and CD — monitor what is defined in Git and what is running in the cluster and reconcile changes.

A GitOps Kubernetes operator, such as open source Flux, further supports the self-service model as the developer commits code and application configurations into Git. Flux runs within the Kubernetes cluster and “looks at” the defined configuration in the Git repository and at the declarative state. Flux then reconciles the changes to the cluster constantly (one minute intervals by default), instead of pushing them as is the case with a traditional CI/CD pipeline. This separation of concerns between the declared state environment and the actual state’s environment makes the whole CI/CD process more secure.

Key Immutability

The Principles of GitOps

• The entire system is described declaratively
• The canonical desired system state is versioned in git
• Approved changes can be automatically applied to the system
• Software agents ensure correctness and ensure actions on divergence in a closed loop

Flux controls and reverts application changes made directly in the cluster that do not correspond to the code on Git — hence, its immutability. The developers typically do not have access to commands for Kubernetes clusters to change the infrastructure. The kubectl command line tool, for example, can remain off-limits to the developer team, thus improving security by preventing them from making direct configuration changes to the cluster.

Developers’ access to multi-tenancy capabilities within clusters also supports the self-service model for GitOps. It is possible, for example, to split clusters into smaller segregated environments for different developer teams. Operators can enable this capability for GitOps across multiple namespaces on the same cluster aligned with the developers’ access on an as-needed basis.

Through these namespaces, it is possible to observe as well as to filter and group all of the Kubernetes clusters on which developers’ applications run. The namespaces also are assigned with different policies, for managing access, compliance, and other settings. This also helps to segregate the namespaces and to avoid “collisions” between them.

Developers also have access to observability tools to monitor the health of their applications as they are deployed in the clusters during the CD process. With the graphical interface Grafana provides, for example, all environments that correspond to the different namespaces are available where application performance, the health of the cluster, and other information is provided.

In one scenario, a developer might build and test code on their own for a cloud native environment, with containers (typically with Docker) on their laptop before committing the code to Git. They build a Docker file, package their code, then commit it to Git where it is tested.

For testing with GitOps, the developer commits the manifest they have selected as part of the self-service option alongside the application code. After manifest parameters and environment variables are inputted with the data-serialization language YAML in order for the application to run, the self-service automation begins as the code is deployed in a test environment, and if approved, propagated to production. The developer does not require deep knowledge of Kubernetes — a common stumbling block for many DevOps teams making the shift to cloud native environments — while at the same time, they can continue to monitor application health through data logs and other metrics that can be visualized with Grafana, for example.

SEE ALSO: “It’s never been a more exciting time to jump into the cybersecurity conversation”

Self-Service Developer and Operations Customers

In summary, the self-service model GitOps offers treats developers and operations teams more like customers compared to what traditional CI/CD processes offer. For the developer, the benefits include:

• More autonomy over the code stack.
• Less time spent on configuring infrastructure.
• More visibility and control for testing.
• More rapid and secure deployments on their desired infrastructure.

The benefits of self-service with GitOps are also not limited to developer teams. Operations teams are better able to:

• Improve security and compliance management, largely thanks to automation.
• Boost the speed to deployment once code is committed on Git.

The results are easy to demonstrate. In the case of State Farm, for example, every product team has the ability to deploy their changes to the insurance giant’s “modern strategic platforms in a simple, compliant and repeatable manner,” Mae Large, architecture manager at State Farm, said. As described above, GitOps serves as the framework for self-service. “One of my team’s biggest principles is to provide a self-service platform for our engineers — GitOps is making this possible,” Steve Wade, platform lead, Mettle, NatWest’s business banking innovation arm in the UK, said.

The right platform of choice will enable and support a self-service model for developers with GitOps. One alternative mentioned above is Weave GitOps to 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.

The post How GitOps Offers a Direct Path to Self-Service for Developers appeared first on JAXenter.