Software Development Lifecycle (SDLC) management is an old topic that is hot again for DevOps teams in charge of operating applications in Kubernetes.
The daily mood
According to the famous book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim, we are often looking at automation as an opportunity to improve both development velocity and operational reliability. We know what works and what doesn't work, yet we often don't know well enough the methods and discipline to make it lean and consistent.
I need to build my own mindset about our path towards GitOps. I just looked at some Dzone contributions from vamp.io and split.io around the concept of Continuous Release Cycle.
*Deployment approaches
- Conitnuous Deployment: New versions are automatically rolled-out as they are available. Ideally with no risk but this is extremely hard to achieve, therefore it doesn't get any credit.
- Continuous Delivery: New versions are submitted to manual deployment approval as they are available. This is the most common approach in the industry.
- Progressive Delivery: New versions are delivered to a subset of users only. State-of-the-art (according to the talk).
Deployment styles
- Blue-Green: Deploy a modified copy of your production and cut-over (ex. using a Load-Balancer) from one state (fig. "blue") to another (fig. "green"). Classical "Big-Bang"-scenario which allows for very fast deployment with only little or no downtime noticed, but the effort and cost to setup multiple environments in parallel each time a change occurs. Not the best option.
- Canary: Allow for running multiple versions of an application on the same environment. Make the new version available for a non-critical subset of the production (ex. 5% users) first, then progressively route all other users from one state to another. Most common approach in the API-industry, also know as "Traffic splitting". However, such "Rolling" can take weeks or months.
- Feature-Flag: Each feature is controlled separately using individual on/off switches, and delivers aspect driven metrics e.g. at LinkedIn in terms of speed, quality, risk. Telemetry also supports business metrics e.g. licensing, revenue, customer engagement and retention. It can be used in combination to the Canary approach. It is fine-grained and complex, but state-of-the-art.
Source: FeatureFlags.io
Continuous Release Cycle
- DTAP is an established acronym for the practice of staging accross Development, Test, Acceptance, and Production environments
- DPAT is a new accrony which stands for Development, Production, Acceptance, and Testing. With this, you can push out new features to early adopters.
Caution: Although the Feature Toggle pattern has gained in popularity through successfull companies like Flikr, Google and Netflix, you should better not wrap every new feature within a flag. Instead, rather consider if a given feature could be splitted into smaller ones in order to facilitate its deployment.
Tooling
While there are plenty of language specific libraries for supporting feature-flagging as part of your applciation code, there are also a number of standardized platform providers creating better user management, toggle usability and flag security:
- Open-Source: Split.io, Togglez, FF4J, Rollout.io, Unleash
- SaaS: LaunchDarkly, ProbeBeta, Optimizely
- IaaS: Azure App Configuration, AWS Cloud Development Kit (CDK)
Conclusion
To me it looks like there is no easy answer to how CD should be done, as it might require quite a lot of custom configurations and process definitions. Still there is definitely a strong link between general best practices and what GitOps can perspectively offer within a Kubernetes environment like ours.
Other references
- Feature toggle on Wikipedia
- CNCF Webinar about Deployment strategies on Kubernetes - including A/B and shadowing for testing
- James Governor talk on Prgressive Delivery at QCon 2019
- Pete Hodgson article on Feature Toggles (aka Feature Flags) at martinFowler.com 2017
- Ben Nadel's article on Best Practice for using LaunchDarkly
Comments
Post a Comment