Blue-Green deployment on Azure Service Fabric

Hello, as you know, there are a lot of DevOps tools (such as Azure DevOps) that allow a rapidly build and deploy.

The challenge is to ensure that the process which allows delivering an application from a development environment to a production one do not impact the availability of your application. This is where Blue-Green deployment comes in.

• What is the Blue-Green deployment ?

Imagine that you want to deploy a new version (V2) of an application.

The V2 worked fine on Development environment and user acceptance one, but is this enough to validate your version ? Well, surprises happen !

A process as following may take place on your production environment.

Once you build your V2, you can deploy it on the production environment but on a kind of a staging one. You test it , once it’s OK, you can swap to the principal environment.

This is what we call Blue-Green Deployment. It’s about splitting the production environment to two parallel environments (Called Blue and Green).

Green is the existing production (with the V1) and Blue is the new one (with V2) which becomes the new Green.

The swap should bring no down time to your environment if the Test step went smoothly.

• How to implement the Blue-Green Deployment on Azure ?

The “Cloud Service” (PaaS Service) brings the possibility to implement the Blue-Green Deployment using the slots (Staging and Production). This service is still available on Azure but Microsoft recommends to avoid it because soon or late it will go out of support.

You need then an alternative to Cloud Service on ARM. Well, you have two possibilities : App Service or Service Fabric.

A million of ways to implement the Blue-Green Deployment on Service Fabric are available. I’ll show you some. You can guess the others :

Using Api Management on the front to handle your requests and redirect them to the correct NodeType on service fabric !

Below another overall architecture which represents Service Fabric with two NodeType (which contains VMSS). The blue one has the newer code.

The application Gateway receives the traffic and redirect it to the wanted Load Balancer.

Each node type has a private IP address. Using an Internal Load Balancer, you will be able to load balances the traffic across the backend Pool.

This architecture can be done using an ARM Template or Terraform. A sample will be available soon on my Github.

Bella ciao !