DevOps

This is a pretty broad topic but I will mostly cover some basic deployments use in CI/CD pipelines. Software engineers are increasingly exposed, and to be responsible for, deployments and to a degree, environment management (and yes, we still get paid the same!).

Some of this may affect the application's architecture, code changes etc. I hardly see this as a positive but perhaps a necessary evil and it has already gained substantial mass - resisting would not be prudent.

Deployment strategies

• Blue Green

• Rolling upgrade

• Canary release

• A/B Testing

Blue Green

1. leave N VMs with v1 (group1)

2. allocate N VMs with v2 (group2)

3. once group1 becomes stable, route all traffic to group2

4. release group2

Notes:

• both groups connect to the same DB

  • if there are DB migrations, they must be BG compatible

• the app could have it's own load balancer and it's own version

Pros:

• only one version of the service is available to clients

  • this means there will be consistent interaction of your service to end users

• resource allocation/availability will be the same during the rollout

• rollback is easy

• no down time

Cons:

• requires 2N VMs

Rolling upgrade

1. allocate a new VM with v2

2. release one VM with v1

3. repeat

Pros:

• simple

• requires only N+1 VMs

  • or you can upgrade an existing VM for the cost of performance on VMs on v1

Cons:

• multiple versions of the service will be available

• rollback can be tricky during a rollout

• could have downtime

Canary release

1. allocate a new VM with v2-test

2. route specific traffic to v2-test

3. if stable, continue to full release

Notes:

• this is similar to rolling upgrade but with the intention to expose only a subset of users to v2-test - usually this is done with internal employees/users. An alternative approach is by partition e.g. region.

• enables A/B testing

  • multiple versions of the service will co-exist, this can be difficult to manage

  • it may take a long time before enough data is collected for the A/B test to be satisfactory

• intention is to monitor the v2-test closely in production to determine whether it negatively affects the service

A/B Testing

• two versions of the service is deployed at the same time

• percentage traffic is routed using a load balancer and feature flagging