Dropping fresh code into a production environment is a nerve-wracking experience, even for the best of developers. There’s no getting around it – that moment when you click to deploy new software always sets the heart racing, because what if something goes wrong? You don’t know, until you know.
This is why having a smart software deployment strategy is vital for modern DevOps teams. There are countless ways to push out an update to an application, with options ranging from going for broke and swapping out the old app for a new version instantly, to testing with only a small batch of users to minimise the impact should something go wrong.
Software deployment strategy matters
The method of software deployment can have a massive impact on application availability, the confidence of the developer team, and the hassle involved should a rollback be required. If the team decides to update all running instances simultaneously, it might only take seconds – but if the update fails, a huge disaster could unfold.
In general, most developers opt for one of three primary software deployment strategies – or at least some variation of them. These include blue-green deployments, canary releases and rolling upgrades.
Each has its pros and cons, and developers will always have to make a trade-off somewhere or other.
1. Blue-green deployments
To get an idea of how blue-green deployments work, it’s like having two separate but identical rooms. The blue room is hosting a party, or live traffic, while the green one sits empty. When it’s time for an update, the software deployment slots into the green room, where it can be tested to ensure the lights stay on and everything works as it should.
Assuming all is well, developers can flip the switch and shunt our party-goers from the blue room to the green, before making sure that the lights don’t suddenly go out under stress.
The advantage of blue-green deployments is that they’re simplicity personified and generally, very safe ways to roll out a new software deployment. If any problems pop up, the team can just shove everyone back into the blue room, minimising the impact. However, blue-green deployments are notoriously expensive due to the need to have – and consequently manage and pay for – two full environments running simultaneously.
2. Canary deployments
The canary release process relies on progressive validation. Rather than move the entire user base at once, teams begin by letting a small trickle of application traffic switch to the latest version. Should that initial 5% of users experience problems, they can quickly be ushered back to the older version, while the vast majority of users are none the wiser that anything was up.
Should the initial software deployment go off without a hitch, the traffic can be stepped up progressively – 25%, 50%, 75% and so on, until ultimately every user is moved onto the latest release.
Canary deployments might sound foolproof to the uninitiated, but the downside is that setting them up and seeing them through is often complex. Teams must invest in advanced tools and infrastructure to enable smart traffic routing, along with comprehensive monitoring systems that can compare the performance of the stable and canary versions of the app.
3. Rolling deployments
If a steady upgrade cadence is required, the rolling software deployment strategy might be the way to go. The concept here is “one-in, one-out.” If the app is running on 10 servers at once, the rollout begins by taking one of them offline, hitting it up with the latest software version, before bringing it back online. Then sit back and watch for a while. Hopefully, no major issues will show up, which is the green light to do it again with the next server, and keep going like that, one-by-one.
Financial chiefs tend to like rolling deployments because they’re extremely budget-friendly, as they don’t require the vast resources that spinning up a whole new environment would entail. All that’s required is to ensure there’s enough overheads available for the nine other servers to carry the load while one is being upgraded.
The biggest hassle with rolling releases is that it means you’ll have to be running two versions of the app throughout the process, which necessitates ensuring that they’re backwards compatible, a challenge that teams often underestimate. If compatibility is broken, expect real havoc to ensue.
Which strategy makes the most sense?
There’s no straightforward answer to the question of which software deployment strategy is best, because every team, app and situation demands a custom approach.
For organisations that have money to invest in smooth operations and require a solid safety net, it’s hard to look past blue-green software deployments. This strategy is used with mission-critical applications that need to revert back quickly in the event of problems. We’re talking financial services, healthcare apps and so on, where the cost of extended downtime will quickly exceed the cost of running two environments at once.
A canary release generally works best with high-volume, user-facing applications like content delivery and social media platforms, where it’s easy to measure performance in real time through various metrics. The higher the traffic is, the smaller the percentage of users required to gather meaningful feedback, minimising the blast radius in case things get problematic.
On the other hand, if teams require a more stable deployment strategy that’s not going to blow their infrastructure budget, rolling deployments are likely to be their go-to. It’s often the favoured strategy for high-scale and distributed web services that cannot risk downtime, but where teams lack the budget to have two environments running at once.
The model that fits your situation best
The most successful developer teams don’t just stick with one deployment strategy. The secret is to choose the strategy that’s most appropriate for the situation in hand, so that if any problems do occur, the team can avoid running around in panic and simply follow the plan to revert back to the stable release.
