For long time when we had on premise web servers, database servers, application servers deployed on specific VMs or bare metal servers, we used to worry a lot on the resources it consumes and the cost of adding more to stabilize it or maintain it to support newer software or hardware releases. Lot of the manual effort of maintaining, patching, updating these servers have resolved by introducing orchestration tools such as Chef, Puppet, Ansible etc.
With the adoption of Cloud platforms, having to maintain the applications deployed VMs or bare metal has been moved from an organization's Devops to the Cloud providers hands. VMs are created, deleted and recreated with just a button click and so was the thought of something called Mutable and Immutable infrastructures came into picture.
Let's talk more about Mutable and Immutable Infrastructure and its advantage or another.
Mutable vs Immutable Infrastructure
Let's take an example of servers residing in on-premise and cloud.
Scenario 1 - Updating an application running on an application server with a version v1.0.
In a mutable infrastructure scenario, you would be updating the application version to v1.1 on the same machine. This application once upgraded will be properly tested and once it's confirmed that it is working as expected, the traffic would be routed to the newer version while degrading the older one.
In a Immutable infrastructure scenario, you would be performing the update on the application on a different VM or instance and once testing is completed and everything is working fine, the traffic will be redirected to the new VM and the old VMs would be decommissioned.
This is not very scary in a Mutable pattern, in fact it is more easy and comfortable to have a single server with the upgradation of the application instead of having new VMs setup
Let's make the scenario a bit complex
Scenario 2 - Updating the application server from V1.0 to V1.1
In a mutable scenario, this will be challenging as the already running application on an application server, if updated and due to some compatibility issues if it fails to process some request, reverting it back may not be possible.
But in case of immutable pattern, having a separate VM that has the new version of application server, some user request can be redirect to the new VM, making sure everything works and then redirecting 100% traffic to new one and decommission old VM is much better option compared to the mutable one thus causing less pain.
Making it more scary...
Scenario 3:- Updating application server and installing new web server
In a mutable pattern, this is really scary if there is a compatibility issue with application running on an application server, the web server communicating with application server and so.
In case while updating the application server and installing new web server caused some issue in between there can be situation where application server got updated but web server downloading failed or web server downloaded and half way installed and failed or application server upgrading failed and web server installation got corrupted. If we have 100 such VMs there will be multiple scenarios that can occur especially in production where things won't go as expected.
This failure situation can be totally avoided incase of immutable infrastructure pattern as once everything is done and confirmed working only then the traffic can be routed to a new VM making it safe.
Conclusion
Immutable infrastructure is a good pattern as it avoids mutating the same server again and again causing nightmares for the DevOps and SREs. With Cloud and IAAS this pattern is good to be taken into consideration.
コメント