Progressive Delivery (the GitOps way) with Kubernetes:

One of the biggest challenges organisations faces, especially when running microservices, is managing application deployments. Having a proper deployment strategy is necessary. For instance, in a production environment, it is always a change management process requirement to ensure that the downtime impact on the end-user is minimised and maintenance windows need to be planned to cater for any changes that will cause an outage. It is also mandated that in case of any issues when deploying the change, a rollback plan must be ready for execution to recover from any failures. These challenges amplify with the increase of the number of microservices and makes it more difficult to assess the result of the deployment and execute the rollback if required. Enter progressive delivery.

Thankfully, cloud native architectures using Kubernetes running microservices addresses this problem by offering increased flexibility, allowing teams to publish more useful updates more frequently and progressively. The use of release techniques like Canary, Blue-Green, and Feature flagging as part of progressive delivery enables teams to maximise an enterprise’s software delivery. It is predicated on the notion that consumers desire to test features prior to completion to enhance the user experience.

In Kubernetes, there are different ways to release an application. It is necessary to choose the right strategy to make the infrastructure reliable and more resilient during an application deployment or update. The out of the box Kubernetes Deployment Object supports the Rolling Update strategy which comes as a standard and provides a basic set of safety guarantees (aka. readiness probes) during an update. When deploying into a development/staging environment, standard Kubernetes deployment strategies such as a recreate or rolling deployment might be a good option. However, the rolling update strategy faces may limitations such as controlling the speed and flow of the rollout. in large scale high-volume production environments, a rolling update is often considered too risky of an update procedure since it provides no control over the blast radius, may rollout too aggressively, and provides no automated rollback upon failures.

In production environments, more advanced deployment strategies are much needed to satisfy the business requirements. These advanced strategies are called “Progressive Deployments”. An example of these deployment strategies is the Blue/Green deployment which allows for a quick transition between the old version and the new version by deploying them side by side and then switching to the new version when testing has been successful. This testing of the platform needs to be thorough to avoid having to rollback frequently. If unsure of the platform’s stability or the potential effects of releasing a new software version, a canary deployment offers a smaller scale next version of the

release running side by side the current version in production. By doing so, the new release is rolled-out to a small subset of users to test the application and provide their feedback. Once the change is accepted, it is rolled out to the rest of the users.

Benefits of Progressive Delivery:

Progressive delivery lowers the risk of releasing new features, as well as identifying and resolving possible issues with those additions. It also offers early feedback on any version of your application. Before a feature is fully deployed, the developer can test out various changes on the product to see how the application behaves. The idea is that the developer can alter the release strategy if the modifications are unfavourable to prevent end users from experiencing any glitches.

Secondly, improved release frequency results from sequential delivery. While the primary goal of progressive delivery is to provide end users with safer, more dependable releases, you as the DevOps team will benefit from being able to deploy new versions in smaller parts and hence release more frequently. You can work on each feature separately and release it in tiny sprints. The time to market is shortened, and any DevOps team can now deploy better software more quickly.

Finally, and this is something that is frequently ignored, progressive delivery leads to improved segregation of duties between the development and operations teams. This segregation of duties works better with progressive delivery since developers concentrate on creating new features while operations concentrate on rolling out the new features gradually in a strategy that suits the operational needs of the platform.

Progressive delivery is best achieved with GitOps:

This demand for progressive delivery in a cloud native manner can be achieved with GitOps. The objective behind GitOps is to define and declare everything in Git including operational tasks. Git is already used by developers to generate and collaborate on code. GitOps simply expands this concept to include the creation and setup of infrastructure as well. Git becomes the control plane for operations and deployments because everything is declared as code in Git.

GitOps is being enabled by open-source tooling such as ArgoCD, Flux and Flagger, which automatically checks Git repositories for any new changes, and if it detects a change, it automatically deploys it to production. With progressive delivery, these automated deployments need to be done in phases and to multiple target Kubernetes clusters. These tools offer full control of the software delivery pipeline, rollback strategies, test executions, feature releases, and scaling of infrastructure resources.

In conclusion, there are various methods for deploying an application to cater for applications with varying complexities, teams with different demands, and environments with different operational requirements and compliance levels. Selecting the right strategy or strategies and having full control over these strategies in code when combined by the right tools is an extremely powerful feature of cloud native platforms that greatly simplifies change management, release management, and operations of the applications. It completely disrupts the way operations teams traditionally thought of these processes as rigid and extremely sensitive with a dramatic business impact in case anything went wrong, into simplified processes and tasks that can be executed every day in the background without having an impact on the end-user.