What & why IaaC?

IaaC could be summed up as the writing down of all the infrastructure elements: network, loadbalancers, servers, OS configuration, services setup, etc. There are currently various tools allowing such automation, whether at the infrastructure level:

Or at the applicative level:

Traditionally infrastructures were within datacenters, the operations were manually managed, the servers/virtual machine had very long lifecycle, costs of hardware were calculated over months/years, etc.

But the arrival of the cloud computing paradigm changed deeply that conception.

This is because cloud environments are API driven, which means many if not all actions can be automated via code whether from scripts, or third-parties services, and on top of that, the very own elastic nature of cloud computing makes lifecycle much shorter than previously: days, if not hours rather than months/years.

Which is why infrastructure as code became more and more popular in latest years via the DevOps shifting.

Couple drawbacks of IaaC

IaaC makes nowadays makes a lot of sense, there are however small drawbacks to take into consideration.

For example the initial setup, might require a bit more time than traditionally, because you have to ensure everything you did has been written down as code for both your infrastructures and/or code.

Small modifications could also prove to be slower than manual ones, eg.: modifying a DNS entry could be very simple in a console, but would require to find the file referencing that DNS entry, update & commit it, apply the changes.

Those drawabacks are difficult to erase, but IaaC comes with a lot more benefits.

Various benefits of IaaC

As previously mentioned there are many benefits from using IaaC.

First of all, via the automation of your IaaC you make your day to day operations much more robust and reliable, as you reduce the human error factor. This automation could also come in handy if you had needs of automatically documenting your infrastructure, as everything is already written down, you could use extra tool to generate it.

That automation, enters the logic of continuous delivery and collaboration. As everything is automated, you will want to version this code, allowing you to gain better knowledge over your infrastructure.

Everything is now shared, with a history of what has been done, what is currently configured, who applied the modification, who required those changes, etc.

Due to this automation, your infrastructures and environments are now more reproducible (it becomes much easier to create a new one), less likely to environments shifting (or if so, better managed), reusable for other projects, and better controlled.

Taking advantage of the flexibility of the cloud and the IaaC, you can now have a better control over the cost of your infrastructure based on your usage. You can also easily scale up or down, easily start/stop environment that you do not use at night, or during development phases, etc

If you wish to read more about it, various actors are speaking about it too, such as Microsoft, Hashicorp or Puppet for example.

At Cycloid

At Cycloid, we decided to use Terraform & Ansible, as we believe these suited our needs of maturity and flexibility.