Stop doing progressive delivery manually - Use GitOps instead
In this blog we are examining different Kubernetes deployment strategies and taking a deeper look at progressive delivery with GitOps. Move from manual feature flagging to an operationalized and automated approach with Flagger and Weave GitOps.
The term ‘progressive delivery’ was coined by James Governor of RedMonk to describe a set of practices such as canary releasing, blue-green deployments, A/B testing, and feature flagging. These are all related practices with minor variations.
Progressive delivery approaches
Before we get into the how, some definitions of key terms are in order.
Canary releasing: “Slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.” - MartinFowler.com
Blue-green deployments: “Gradually transfers user traffic from a previous version of an app or microservice to a nearly identical new release—both of which are running in production.” - RedHat.com
Feature flagging: “Allowing teams to modify system behavior without changing code.” - MartinFowler.com
Progressive delivery involves one or more of these release strategies and enables teams to optimize the delivery of the product to the user. It is based on the idea that users want to try features before they are finished, so to improve the user experience, the software is developed in stages. Each stage is built-in isolation and tested in a staging environment before being deployed to a subset of users. This allows the developer to control the experience of the user, so the user gets the best experience possible. With progressive delivery, a new feature is a complete unit of work that can be deployed at any time. Learn more in this in-depth blog about Kubernetes deployment strategies.
The benefits of progressive delivery
There are many benefits to using progressive delivery. First, progressive delivery provides early feedback on any version of your application and reduces the risk of deploying new features, as well as isolating and fixing potential problems with those features. The developer can experiment with the product to see the effect of different changes or new features before they are fully released. The idea is that if the changes are negative, the developer can change the release strategy to avoid users seeing the changes.
Second, progressive delivery improves release frequency. While the chief aim of progressive delivery is safer, more reliable releases for the end-user, the benefit to you as the DevOps team is that you can deploy new versions in smaller chunks, and thus release faster. You can develop each feature in isolation, and deploy them in smaller sprints. This quickens the time-to-market and achieves the ultimate goal of any DevOps team - to release better software faster.
Finally, and something that is often overlooked is that Progressive delivery results in better separation of concerns across development and ops teams. With progressive delivery, the separation of concerns is better because developers focus on building new features, and operations focuses on deploying the new features in a gradual release.
Current methods of progressive delivery
There are multiple ways to implement progressive delivery today. A popular approach is to use a feature flagging tool that can turn new features ‘on’ or ‘off’ by toggling a button. These are quite capable, and deliver an elegant UI for controlling feature flags. Another option is to leverage a cloud vendor service like AWS API Gateway to split traffic between multiple AWS services. The focus is not on feature flagging, but on traffic splitting.
Drawbacks with the current options
These methods work for many organizations, but they come with some drawbacks. First, they require manual work to enable and disable new features and change traffic routing patterns during the deployment process. In a world of automation and continuous delivery, this is not ideal.
Another disadvantage is that these solutions are divorced from the Kubenetes ecosystem of open source, cloud native tools. They are vendor-specific tooling that come with some degree of lock-in. They require new processes and tools apart from the cloud native stack that is being used by any team that leverages Kubernetes to deliver software today.
GitOps is ideal for progressive delivery
GitOps is a viable solution to this need for progressive delivery in a cloud native manner. GitOps is the idea of having everything defined and declared in Git. Developers already use Git to create and collaborate around code, GitOps merely extends this idea to infrastructure creation and configuration as well. With everything being declared in Git, Git becomes the control plane for operations and for deployments as well.
Today, GitOps is being enabled by open source tooling such as Flux, which automatically checks Git repositories for any new changes, and if it notices a change, automatically deploys it to production. With progressive delivery, these automated deployments need to be done in phases and to multiple target Kubernetes clusters. GitOps is capable of this as it leverages another open source tool named Flagger.
Flagger for progressive delivery
Flagger is a ‘Progressive delivery operator for Kubernetes’ that leverages any service mesh tool such as Istio, Linkerd, or Kuma mesh to control the routing of traffic to different Kubernetes clusters. Unlike feature flagging tools, Flagger does not hide the infrastructure from the process but makes infrastructure the focus. Yet, Flagger makes it easy to control the flow of traffic to the infrastructure, no matter how complex the mix gets.
The policies that govern any deployment is stored in Git, and Flagger reads these policies and executes them using the service mesh. This is powerful because any change to a policy requires editing a single line of configuration. Policies can be as simple as deploying to two clusters on the same cloud provider, or deploying incrementally to clusters located in different cloud platforms and on premise (Here’s a demo of how this works). This combination of Git and a service mesh makes Flagger a powerful alternative to traditional progressive delivery approaches. It aligns dev and ops teams around the same cloud native stack they already use today.
Weave GitOps enables progressive delivery with Flagger
Weave GitOps is a solution built on Flux and Flagger along with other key open source tooling such as Helm, Prometheus, and Grafana. It delivers a complete GitOps solution out of the box that also includes progressive delivery. You could get started with the open source Weave GitOps Core and start automating deployments and implementing progressive delivery right away. When ready, you could graduate to Weave GitOps Enterprise, which brings advanced features such as RBAC, team workspaces, drift detection, and more.
In conclusion, if you’ve been doing feature flagging manually, or are looking to go beyond automated deployments to progressive delivery, GitOps is the way to go. In terms of operationalizing this, Weave GitOps is the ideal solution as it is based on Flagger, the leading cloud native open source project for progressive delivery today. Look out for another tutorial blog on Progressive Delivery coming online next week.
