In such situations, the conversations invariably start something like this:
“We are already agile, we do daily standups – so, we do not need any training. Just tell us how to improve productivity.”
Similarly, there are many misconceptions about DevOps. When asked what is your DevOps approach.
– We use Chef/Puppet
– We have a CI/CD pipeline [use Jenkins]
– We deploy to the cloud etc.
While DevOps is also considered as a significant cultural approach, there are many aspects that contribute to deriving the benefits of a cross-functional team working together with the user experience in mind – which is the spirit of DevOps or the Software Delivery Lifecycle. [See also a related post on this topic]
One of the concepts that is not talked about much, is related to immutable infrastructure.
The concept itself is not new. We have heard this in different forms – most popular is the plug and play model. Just replace a component or add a new component and everything will work well and, in effect, replace the old configuration.
Usually, when we upgrade applications as patches, new features etc, there is a downtime needed to complete the setup and migration – as depicted in the top portion of the diagram.
With an immutable approach, the shift is from a ‘maintained’ infrastructure – as it would be the case for dedicated data centers, to a ‘replaceable’ data center, as in the case of a cloud platform.
Traditionally, provisioning infrastructure from the scratch is a more time consuming activity compared to patching or mutating an existing infrastructure. That has made the latter approach more popular.
However this has a potential side effect of unpredictable application behavior, since there could be differences between the production environment and the development or test/staging set ups.
Immutable infrastructure is a collection of components where the infrastructure is closed for modifications, but open for recreation and expansion.
The significant benefits are predictability and the ability to fail fast, if you have to!
On cloud platforms, changes to the resources are pretty much a simple command or API call.
Immutable does not mean that nothing changes. It is just that the evolution can be better managed with reduced disruptions.
Martin Fowler wrote in a July 2012 blog post titled “PhoenixServer”:
[ … ], it is a good idea to virtually burn down your servers at regular intervals. A server should be like a phoenix, regularly rising from the ashes.
It is almost like in-situ renovation.
In order to do this, the application[s] should inherently be able to handle this. Stateful applications [for special applications] and multi-data center deployments could add additional challenges, but none of them unmanageable.
More careful planning and automation can help make the upgrades smooth. If the underlying architecture is more API based or service oriented – in other words, based on high cohesion and loose coupling, managing some of these changes will become simpler.
This approach could be an overkill, if you manage a fairly simple application running on a few dedicated servers. If you are already on the cloud, you may already be leveraging the facilities of the service provider.
But, if you anticipate the application to evolve into a large one, building an immutable infrastructure in parallel, even during the time of development may benefit in the long-run, to scale out and also detect failure more easily.
Virtualization [and microservices] will help you replace old images, as suggested by an immutable approach.
If you want to take baby steps towards this, you can start with the blue/green model.
Have 2 infrastructures, one that is live and the other that could be just standing by. Again, build the heartbeat or replication features in the architecture, particularly to handle any degradation in production, gracefully.
If you are ready to experiment, inspect and adapt, a good reference to read is:
by Josha Stella,
Copyright © 2016 O’Reilly Media, Inc.
you can read it online at the author’s company site.
If you have created any tools for doing this, or have some experience – good or not so good – please share for the benefit of the others.