Recreate/in-place deployment

There are several ways to deliver, or deploy, software and making it available to users. While there are folks out there specialized in managing these and many software engineers focus only on the business logic side of life, it is still important to understand how the deployment process works and how it may affect users. In this post, I’ll cover one of the simplest deployment strategies, the recreate deployment strategy.

Recreate deployment

This strategy, also known as in-place deployment strategy, follows a very simple pattern. When you have your new software version ready to deploy, you shut down and remove the old version, install the new version, and then you start and validate its functioning. If you only have a single instance of your software running, that is all there is to it. However, if you have several instances running, this strategy can come in two different flavours.

All-at-once recreate deployment

The first flavour is sometimes referred to as the “all-at-once” deployment. In this scenario, we bring down all of the running software versions down at the same time, remove the old version, install the new one, and start it up. Pretty darn simple.

Rollout recreate deployment

The second flavour of this deployment strategy is the rollout deployment. Here, instances running the old software version are brought down and updated one at the time, or a fraction of them at a time.

Pros and cons

As with anything in life, these types of deployments have their advantages and disadvantages. The most obvious disadvantage of the all-at-once deployment is that the users will experience service interruption. This also applies to some extent to the rollout strategy, in the case where a single instance cannot handle all the traffic that two instances would normally handle.

Additionally, in the all-at-once scenario, if some defective feature is included in the new version, the rollback process requires another period of downtime. This is somewhat mitigated in the rollout deployment. However, since the rollout deployment is an instance-by-instance process, it is more lengthy deployment strategy.

But this does have its advantages. Perhaps the most important one is that this is a very simple approach to delivering software, meaning that it is easy to implement and manage. Additionally, there are no extra infrastructure costs incurred when using this strategy, which is great if you are acting on a tight budget.

Although everyone loves having high availability services, this isn’t a strict requirement for every service. If there are periods where you know your service will not handle incoming traffic, e.g., weekends for some banking services, it might make sense to adopt this deployment strategy.