3 Best Deployment Strategies for Your Startup
There are a number of strategies for implementing new production applications, so selecting the best approach is a significant choice, evaluating the choices in terms of the effect of transition on the system and end users.
In this post, we are going to talk about the three best strategies you can use for your startup:
Blue/Green Deployments
The blue / green deployment strategy consists of running concurrently two production versions of a given device. The catch is that there is only one that gets live traffic. This assumes that since the blue and green deployments will not be alive at the same time, the latest version does not actually have to be backward compatible. It is a problem for application dependencies, such as databases, but for them, you can also use the blue / green approach.
For example , let’s assume that your blue side is the version that’s running. The latest update is the green hand, with the updates you want to deploy then. Since the green side is not receiving live traffic yet, until moving it live, you have the chance to conduct real testing in a production environment.
Pros:
- Instant rollout/rollback.
- Avoid versioning problems, the entire state of the application is modified in one go.
Cons:
- Expensive as it involves doubling of capital.
- Proper testing of the entire platform should be conducted prior to release to production.
- Handling stateful software can be difficult.
Canary Deployments
A canary deployment consists of moving output traffic gradually from version A to version B. The traffic is generally divided on the basis of weight. For eg, 90% of requests go to version A, 10% to version B.
Technically, you decide which users will be the first to see the new edition, and you can still change which users you want to have in your test community. Typically, it’s as easy as redirecting a small amount of user traffic to the new version and the rest to the existing version. Both models will be the same when deployment is over. But the positive thing is that before a complete launch, you get the chance to test modifications with a portion of the real traffic.
Pros:
- Released edition to a subset of users.
- Practical for controlling error rate and efficiency.
- Speedy rollback.
Cons:
- Slow rollout.
A/B Testing Deployments
A / B testing is similar to the release of the canary, but how the traffic is divided is a business decision and is typically more difficult. This technique is widely used for experimentation — when you want to try something that you’re not sure is going to succeed. You identify groups based on user habits, location, age , gender, or other variables that will tell you which version has the most positive impact on sales. You can then determine if A or B is ready for all of your users.
Here is a list of conditions that can be used to distribute traffic amongst the versions:
- By browser cookie
- Query parameters
- Geolocalisation
- Technology support: browser version, screen size, operating system, etc.
- Language
Pros:
- Several variants run parallel to this.
- Complete control over management of the traffic.
Cons:
- Needs a smart load balancer.
- Difficult to troubleshoot errors, distributed tracing becomes mandatory for a given session.
Conclusion
Each strategy has its trade-offs. But one advantage common to all of them is that you’ll have zero downtime if you execute the strategy well. You’re not going to have to wait for particular times when your customers won’t know that anything is changing for you. Now, getting to that point won’t be easy; your employees will have to put in some extra effort to accomplish it. But nevertheless they won’t like having to cut deployments into their evenings, weekends, or family time.
