Practical Strategies for Adopting GitOps for Self-service Developer Platforms
DevOps promises faster engineering teams by managing both infrastructure and code, but the reality for most who adopt K8s is that platform teams need to keep control over infrastructure. How do you bridge the gap between these teams without compromising on velocity or security?
In a recently published article on The New Stack, I wrote about how adopting GitOps self-service developer platforms can increase your team’s velocity by 75%.
DevOps promises faster engineering teams by managing both infrastructure and code, but the reality for most who adopt Kubernetes and DevOps best practices is that platform or SRE teams need to keep control over infrastructure. How then do you bridge the gap between these teams without compromising on velocity or worse, security?
While the benefits of Kubernetes and other cloud native technology are well known and include an increase in operational productivity and scalability, getting there can mean dealing with an increase in configuration complexity. In most cases, this complexity can be solved through centralized self-service developer platforms.
GitOps is an efficient way for development teams to go faster even if they are not experts in Kubernetes. Implementing a self-service developer platform that is automated with GitOps can provide your application engineers with the autonomy to increase deployment frequency and reliability.
But before exploring strategies for self-service platform adoption, it is worth some discussion of what GitOps means. At its core, GitOps is these two things:
- An operating model for Kubernetes and other cloud native technologies and a set of best practices that unifies the deployment, management and monitoring for containerized clusters and applications.
- A path towards a common developer experience for managing applications and infrastructure; where end-to-end deployment pipelines and Git workflows are applied to both operations, and development.
For GitOps to be implemented correctly, there needs to be a mechanism in place that can compare the desired state, which is kept in Git, with the running state and alert on a drift. If teams can observe their system at any point in time and get alerted when the system diverges from the desired state, then mitigation can occur. With GitOps, your entire system is described declaratively and versioned in Git. This gives teams a sole source of truth from which everything is derived and driven. GitOps also makes use of software controllers to ensure correctness that alert on any divergence, setting up a feedback and control loop for application and operational tasks.
Developer autonomy through GitOps automation
Operations teams can implement self-service Kubernetes platforms by allowing application engineers to choose from a set of cluster add-ons and other tools that solve common uses such as monitoring, CI/CD deployment pipelines from Git. This is possible because not only is Kubernetes described in declarative configuration, but so is its ecosystem of cloud native tools. With declarative configuration versioned in Git, developers and operators have a method to spin up correctly configured clusters based on their use case through pull requests.
Implementing a self-service platform and automating it through pull requests supplies several significant benefits for both platform and development teams, such as a common developer experience for operations and application development teams, as well as built-in audit trails, as well as guardrails, and security guarantees. For a practical discussion on self-service developer platforms and how to implement them listen to Steve Wave and Cornelia Davis discussion on the topic in this recent podcast.
To read the article in its entirety, head on over to The New Stack.
