Immutable Infrastructure and Deployment Techniques in Microsoft Azure Focusing Resiliency

As an IT or DevOps professional, you may often find yourself managing an increasingly complex technological landscape. As your infrastructure evolves, it becomes critical to ensure all elements function with the highest levels of efficiency and reliability. This article will detail the concept of Immutable Infrastructure while also shedding light on Microsoft Azure’s recommendations for application updates through blue-green deployment and canary releases.

Immutable Infrastructure - A Proactive Approach

? The principle of immutable infrastructure stipulates that you should not modify your infrastructure after it's been deployed to production. Never? Well, this practice aims to prevent inconsistencies and unforeseen complications that could occur when ad hoc changes are introduced. Such alterations can create a state where the changes made are unclear, and troubleshooting becomes increasingly complex, hindering effective thinking and decision-making about the system.

Immutable infrastructure is particularly beneficial in a microservices architecture or PaaS heavy deployments, where there are many services running different versions and configurations. With an immutable approach, each release gets a new environment and is isolated from others, thereby reducing the risk of making changes and improving the reliability and stability of the system.

For example imagine you are deploying a web application to Microsoft Azure using Azure App Services. Typically, you would have multiple environments e.g., dev, staging, production. Let's suppose you are running v1.0 in production right now and now there is a need to deploy v1.1 with new features according to immutable infrastructure principle, instead of modifying the existing environment to accommodate your new version of application you'll create a new environment altogether.

Here's how you could go about it:

1. First, you deploy the 1.1 version of the application to a staging slot in Azure App Services. This new environment is independent of the current 1.0 production environment.
2. Next, you conduct your testing, apply all necessary configurations, and ensure that everything is working as expected.
3. Once you're confident of the results, using Azure App Services' swap feature, you swap the staging slot loaded with the 1.1 version with the production environment. This essentially means that all the traffic is now pointed to the 1.1 version without directly modifying the existing production environment.
4. The old environment with the 1.0 version is retained in the staging slot. Should anything go awry with the 1.1 environment, due to the immutable approach, you can instantly swap the staging slot back with production, reverting back to the steady 1.0 version in no time.

This approach aligns with the principle of an immutable infrastructure where you’re not making changes to the running production environment, but instead producing new, isolated environments. This method minimizes risks that could arise from modifications while giving an immediate, ready-to-revert solution should any issues arise in the newer release.

Deploying Application Updates - The Azure Way

? When it comes to implementing an application update, Azure recommends a few specific techniques that push updates in a controlled manner, mitigating the potential impacts of a faulty deployment. The two primary methods, blue-green deployments and canary releases.

Blue-Green Deployment

? Blue-green deployment is a technique that emphasizes deploying an update into a production environment separate from the live application. For instance, the 'blue' environment could represent the live application, while the 'green' environment is used for the updated version. Once the new version is tested and validated, the traffic routing is switched onto the updated version.

As an example, Azure App Service Web Apps supports this technique with staging slots. These slots allow you to deploy your application to a separate live app service that is not serving user traffic. Once the app is tested and ready, you simply switch the traffic using Azure’s 'swap' feature.

Canary Releases

? Canary releases follow a similar principle to blue-green deployments. However, in a canary release, instead of switching all traffic to the updated version at once, the update is rolled out to a small user percentage by routing a portion of the traffic to the new deployment. This approach allows you to monitor the performance and feedback of the new release with a manageable user group.

If there is a problem with the new deployment, you can easily roll back and revert to the old deployment. Conversely, if the update is successful, you gradually increase routing to the new version until it eventually receives 100% of the traffic. This model offers a more gradual and controlled migration to the new version, minimizing the risk of system-wide errors and mitigating potential downtime or negative user experiences.

A Strategy for Rollbacks

? Azure's motto is to always have a plan B. No matter which deployment approach you prefer, it’s essential to ensure a strategy to roll back to the last-known-good deployment quickly, in case the new version is dysfunctional. A well-rounded rollback strategy should also consider database changes and adjustments to dependent services.

In any contingency, application logs are a critical resource to identify which version prompted the error. Therefore, make sure logs capture the necessary data and are readily available for error analysis.

? While Azure positions its recommendations and tools as a pathway towards seamless and controlled infrastructure management. It is worth noting that while these two approaches - blue-green deployment and canary releases - offer structured methodologies for application updates, it ultimately falls to the individual or organization to determine what works best within their operational framework. Remember, the essence of all deployment strategies lies in reducing risks, achieving high availability, and delivering optimal performance to the end-users. Knowledge and effective use of these techniques contribute significantly towards the journey to achieve a seamless and efficient IT infrastructure.

Here is a nice blog focusing on immutable infrastructure for Azure, using Azure DevOps, TF, Packer and Ansible. Tutorial: Immutable infrastructure for Azure using VSTS, Terraform, Packer and Ansible ( microsoft.com )