Talking about immutable infrastructure requires us to go back in time and start by explaining how they were, and in some cases still are, the infrastructures that support the vast majority of applications.
A few years ago, the entire infrastructure of an application was often shared. In other words, an application was hosted on servers that maintained not just one, but several applications.
Any change in this structure was made through its administrators, who remotely accessed these servers to make the necessary changes.
This introduces us to the concept of mutability, where the change or alteration of something is considered possible. In this case, it applied to the configurations or even characteristics of the server. For a long time, and even today, in some situations, this was the practice employed.
This kind of approach brings to the structure some points that have always brought problems. For example, this change was not always documented, and even errors occurred during configuration, leading to exposure of the structure.
However if we think about it, we will realize that the concept of mutability and immutability is not something new. Programmers already know this kind of concept, and many know that data also have its characteristics of mutability and immutability.
In June 2013, Chad Fowler wrote an article explaining the need to think differently about infrastructure. In the work, he suggests the use of the concept of immutability in software architecture also for the infrastructure.
As we have already mentioned above, the use of mutable infrastructure is very susceptible to errors, and for this reason we want to talk a little bit about the topic of immutability.
What is Immutable Infrastructure?
Initially we talk in a macro way about the concept of immutability – which is a characteristic of something that is immutable, stable.
Starting from this concept, we can say that an immutable infrastructure is a structure where its basic components can’t be changed or modified.
In this first image, we can see how changes are made in a mutable structure, that is, where we can change the components. In this case, it is about systems and applications on a server.
In this example we can see that a web application was updated and a web server was changed, and after the reboot we should have everything working properly.
We have to imagine that, during the process of updating and changing systems, no matter how much the team follows pre-established standards, each one performs the tasks in their own way, and this can generate a series of problems. And if we imagine that in a high availability infrastructure the main goal is to keep the system running as long as possible, having to reboot machines is not the best solution.
The image above shows an immutable infrastructure and how it is operated to reduce the margin of error and downtime.
In an immutable infrastructure, the state of the server is not subject to change. We can see that it is an alternative way to build an infrastructure and helps to fix many of the problems encountered in the changing infrastructure approach.
In the example above, the operations team directly updates the systems and applications in the image code that will be used as the basis and not manually on the server. After these code changes, the development team can start testing in an isolated environment, which being validated, can be passed back to the operations team that, starts to create a new stage of a server using some continuous integration tool.
In a very clear way we can already see a great benefit of using this type of solution. When there is deployment by the operations team, it has already been tested in another environment and validated. So we will hardly have an error in this process.
Once this has been done, at some point the old server will be destroyed and the operation will follow normally.
In some cases there is the use of a concept called deployment canary.
This technique goes back to the times when miners put small canaries in cages inside the mines and if some harmful gas leaked to the human being, it would first affect the canary, thus showing that something is wrong.
This thought was put into the validation of immutable structures, thus getting part of the traffic of a web application, for example, to be directed to servers that were changed, and if something was wrong, only a small part of the users would suffer an impact, which would enable the correction.
This type of structure can be a great advantage for the vast majority of companies and systems, therefore we also understand that in some cases it is not possible to use this type of solution.
For those who can, open source solutions like Netflix Animator or even AWS solutions like EC2 Builder can help with process automation.
And are there challenges?
There always are!
We can say that one of the challenges this new concept brings is for the more traditional security teams, which have not had their structure designed to accompany this model.
Let’s take an example: imagine that at a given moment a vulnerability scanning tool is running on a given host. In this immutable infrastructure model, where the server(host) can be replaced as soon as necessary, it is possible that, when finished scanning, it will be replaced by another, with new version and new configurations.
These new challenges require a change in thinking and structuring, where the focus of the search for vulnerabilities on the active hosts would pass to be performed tests on the image that serves as the source for the new stages that will be activated. This thinking also serves for containers.
Conclusion
The immutable infrastructure offers great opportunities to create new, more efficient forms of management that enable greater control and security over the software update and its support structure.
However, we need to understand that there are challenges and changes that must be made if this type of strategy to be successfully achieved.
The change of thoughts and culture of the DevOps teams are essential for the introduction of this new concept in an effective way.
Read all the articles we have already published on AppSec
