Infrastructure continuous deployment

Ana Sirvent

During the last decade cloud computing has become the norm and more and more customers are migrating from their on-premise data centres to the cloud. Migration to the cloud offers some important benefits such as cost reduction (decrease capex and opex) or security improvements (as AWS says, “if you don’t trust us, trust our auditors”). This transition along with the agile movement have enabled a new way of doing things on IT that converges on the DevOps culture.

Concepts such as; continuous integration, continuous delivery, continuous deployment or infrastructure as code are now key if you want your IT company to success. When people talk about achieving continuous deployment, they are usually talking about an application or a product on a production environment and procedures such as A/B testing, blue/green deployment or canary deployment are frequently mentioned, but what should we do with the infrastructure? What happens if we need to change something in the network such as; DNS server or a load balancer? Well, first of all, the process of “Infrastructure as code” is here to help.

Infrastructure As Code

Infrastructure as code means to treat the infrastructure the same way as the software development. We will have some code stored in a repository and we will orchestrate the changes on a continuous integration environment, just as we usually do with the rest of the software code.

Behind are the days when the infrastructure changes were done manually, managing the changes of all the different environments were a living hell (believe me, I’ve been there!), and whole teams had to spend extra hours doing a releases rollback because the similarities between pre-production and production environments were only in the names. Using infrastructure as code we can build the infrastructure in a repeatable and reliable way so we can avoid the above problems once and for all.

The Journey To The Immutable Infrastructure

Treating your infrastructure as code will help you to achieve a continuous deployment and the final goal will be to have an “immutable infrastructure”. So, what is an immutable infrastructure? This is not treating your resources as a series of beautiful cables and electronic circuits that need to be taken care of and pampered so they do not break and leave you in the lurch.

Having an immutable infrastructure implies that you are not changing an existing infrastructure, you will destroy the existing and create a completely new one with the change instead. This would be unimaginable without cloud computing and the possibility to spin up environments in minutes, but like everything, it has its challenges. So, can we have a whole system to behave “immutable”? The reality is we can only have the stateless components of the application as immutable, so we can destroy and re-create them as many times as we want, that will be everything except the persistence layer where we store the data, typically on databases.

We have clients with petabytes of information in their databases, so even if the databases are backwards compatible and doing incremental backups, spin up that amount of data on a new database it would take hours, which is not very agile. In addition, the continuous deployment process complexity can exponentially grow if we need to maintain in sync two large databases to achieve zero downtime on a release.

Then, how we can implement the infrastructure as code process?

Nowadays there are several tools that are here to help. At Zaizi we use Terraform, which is an agnostic platform tool that allows us to build infrastructure as code in almost any cloud provider.

When Terraform is executed it generates a state file that contains the mapping of your real world resources. Usually you keep that file in a S3 bucket to allow collaboration between members of your team. Below is a diagram on how the continuous integration process for the infrastructure works (as you can see, we use Ansible for provision: The infrastructure created by Terraform).

Basically, Jenkins do all the orchestration with a pipeline so every time a change on the Terraform scripts is committed it will trigger the execution of the new plan in all the different environments automatically until production, achieving the infrastructure continuous deployment. We were talking before about achieving an immutable infrastructure, and if you ever used Terraform, you will know there are times when it does not destroy and recreate the resources, but it changes them instead. This happens because Terraform evaluates in the plan if the change requires to recreate the existing resource or it can be simply modified. If you want to recreate the resource regardless, you can simply “tainted” the resource and it will force to be destroy and recreated on the next apply.

Challenges We Had

In the earlier days of adopting Terraform we found quite difficult to have more than one developer creating or modifying the scripts as they couldn’t test their local configuration at the same time. Once we gained more experience with the tool, organised the code on modules to be able to reuse it and configured the variables properly it got easier.

Conclusion

Infrastructure continuous deployment will not be achievable without the transition to the cloud and the opportunity to use the infrastructure as code process. Nowadays there are a lot of tools that can be used to reach that state of automation, organisations just need to choose whatever meets the requirements better and start implementing. There is no excuse for manual steps anymore!

Latest content

Thanks for joining us! We’ll keep you informed with regular updates.

Sign up to our newsletter

Consent(Required)
This field is for validation purposes and should be left unchanged.