Deployment strategies

Supported and tested deployment strategies using Werf by WorkZone:

• Recreate: Version A is terminated and then version B is rolled out.

• Rolling deployment (AKS ramped or incremental): Version B is slowly rolled out and replacing version A.

Recreate

Pros:

• It is easy to set up.

• The application state is entirely renewed.

• Use this strategy if:

  • Your application service is not business, mission, or revenue-critical-

  • Your deployment is to a lower environment, during off-hours, or with a service that is not in use.

Cons:

• High impact on the user, expect downtime that depends on both shutdown and boot duration of the application.

Purpose:

When you do not support having new and old versions of your application code running at the same time.

Rolling deployment

Rather than updating all servers simultaneously, slowly replacing currently running instances of the application with newer ones one after the other until all the instances are rolled out.

With a pool of version A behind a load balancer, one instance of version B is deployed. When the service is ready to accept traffic, the instance is added to the pool. Then, one instance of version A is removed from the pool and shut down.

The deployment method is used to reduce application downtime and unforeseen consequences or errors in software updates.

Pros:

• It is easy to set up.

• The version is slowly released across instances.

• It is convenient for stateful applications that can handle rebalancing of the data.

Cons:

• Rollout/rollback can be time-consuming.

• As nodes are updated in batches, rolling deployments require services to support both new and old versions of an artifact.

• The verification of an application deployment at every incremental change makes this deployment method slow.

Purpose:

• When you do not want downtime during an application update.

• When your application supports having old code and new code running at the same time.