This content originally appeared on Bits and Pieces - Medium and was authored by Natarajan Venkataraman
When it comes to SaaS deployment strategies, you may have heard of blue-green, canary and AB-testing. There are many articles that cover how these can be implemented. In reality, there is more than one way to implement each of these strategies.
Some may think these strategies are options, ie. one needs to choose one of these strategies for their microservice architecture-based SaaS application.
In reality, each of them is suited to solve specific problems, which will be the focus of this post. When we use them in other circumstances, they become a burden rather than a benefit.
Blue-Green
Blue and Green are just names for current and previous versions of a component. The purpose of Blue-Green deployment is to ensure the availability of the old version for some time, while the new version is soak-tested in real production and the SRE team is able to gain more confidence in the new version.
There are applications in which some components will be handling a continuous flow of data coming from the users. In the case of IoT, it would be telemetry from a large number of sensors. In the case of security applications, this would be telemetry sent by security agents. Even in the case of social networks with a massive number of users, there will be a continuous feed coming in. In such applications, not being able to handle the data flowing in would result in loss of data. (Let’s say there is no lean time for doing a component upgrade for such components).
In such a scenario, the SRE team would want a way to minimize risk to the production application whenever such components are being upgraded. The SRE team would want the older version to lie around for a day or so, just in case an immediate switch to the old version is needed. Here’s where the Blue-Green strategy becomes useful.
Now, those familiar with the rolling-upgrade strategy in Kubernetes would wonder whether that isn’t sufficient. Or, how is a rolling-upgrade different from a Blue-Green?
In rolling-upgrade of Kubernetes, the pods with the new version are gradually introduced while the old version pods also continue to handle the traffic. While some tuning is possible to control the rate of upgrade, this is still a very short time frame (usually in the order of minutes). The objective of rolling-upgrade is really to have a hitless upgrade of component and ensure there is no application downtime.
In Blue-Green, however, while both old and new versions of the component are present in production, the old version is dormant and is just kept ready to switch over to in case of failure of the new one. This Blue-Green is not an alternative to Kubernetes rolling-upgrade, but can co-exist with it.
I should also mention that some components in the SaaS platform could be singletons. ie. one instance of the component can exist. In this scenario too, the Blue-Green deployment provides a solution while rolling-upgrade cannot.
Use of the Blue-Green strategy requires that there be a way to trigger an auto-switch to the older version when certain metrics (say # of API failures) exceed certain threshold etc. Likewise, once the new version is validated for the required time frame, the old version must be automatically removed from the system to save on resources and costs.
In the era of continuous deployment (/ delivery), Blue-Green strategy provides a way to minimize risk while maintaining feature velocity.
Canary
Non-SaaS software is delivered as a download to customers. In such cases, esp. for software considered as critical infrastructure, real-life testing used to be done via what is called beta testing.
When it comes to cloud based SaaS applications, there is a single production deployment common to all customers. Even if there are some customers who could be considered beta customers, how is beta testing to be done? Here’s where the Canary deployment comes in.
The term canary comes from canary in the coal mine where a songbird (a canary) is used to determine the safety of the environment inside the mine.
Likewise, in Canary deployment, a new feature or enhancement is tested on a very small (and friendly) subset of customer and then gradually exposed to more and more customers. Any adverse impact of the new change introduced means the change is quickly removed from production without a large number of customers being aware or impacted.
Now, a new feature would likely have both backend elements as well as new/changed UI. Here the challenge would be to synchronize what is displayed, with the backend being exposed. If the backend is totally new with new APIs introduced, it may be simpler to do. But Canary deployment also requires that the new feature UI is not displayed to users not selected (currently) for the new feature. Thus, the UI framework itself needs to be based on a switchable UI framework where UI elements can be shown or hidden depending on whether a feature is to be exposed to the user or not. This introduces challenges to implementing Canary deployment, by tying in the UI design with deployment strategy.
Components that expose APIs for access by external parties are good candidates for Canary deployment. It is expected that such users are aware of the new APIs or new API versions of existing APIs.
Canary strategy is also well suited when making design improvements to existing microservices. This may be needed to reduce tech-debt or improve performance etc. Now, any design change comes with risks and the Canary deployment pattern helps reduce the risks.
Can Canary strategy be used in lieu of Blue-Green ? Perhaps. The Blue and Green versions still need to be present side-by-side. However, when using it together with Canary strategy, traffic will be directed to the new version gradually. In that sense, it is a combination of both strategies.
AB-Testing
There are times when we cannot second-guess customers. For user-facing functionality, getting users to decide (or provide feedback) and then adopt is better.
Here’s where AB-Testing comes in. Both A and B refer to two flavors of implementation on which feedback is sought. (NOTE: There could be more than 2 flavors too). Unlike Blue-Green and Canary, it is not about old version and new version of an implementation.
Naturally, this strategy is ideally suited for UI related microservices rather than backend microservices, which a customer would be unaware of. Here, the feature implementer needs to ensure that the backend microservices for choice-A and choice-B aren’t different. For backend services which provide API based access to users (who would be developers), this is not suitable.
AB-testing is best done with help of UI design paradigms like ‘backend-for-frontend’. This helps validate the preferred UI with least impact to backend microservices.
Summary
What is important for an organization that provides SaaS application to its customers is to balance feature velocity and experimentation (aka innovation) with stability, uptime and responsiveness to customers. The strategies discussed here are not an end in themselves, but just ways to achieve this business goal. However, when used for the wrong problem, they can result in neither objectives being met and just become a burden on the development and SRE teams.
From monolithic to composable software with Bit
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more:
- How We Build Micro Frontends
- How we Build a Component Design System
- How to reuse React components across your projects
- 5 Ways to Build a React Monorepo
- How to Create a Composable React App with Bit
Understanding When to Use Blue-Green, Canary, and AB-Testing Strategies was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Natarajan Venkataraman
Natarajan Venkataraman | Sciencx (2023-03-06T14:08:47+00:00) Understanding When to Use Blue-Green, Canary, and AB-Testing Strategies. Retrieved from https://www.scien.cx/2023/03/06/understanding-when-to-use-blue-green-canary-and-ab-testing-strategies/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.