Infrastructure as code: Architect PoV

Infrastructure as code or IaC is a method of allocating, provisioning, and configuration of various infrastructure services by scripting API calls the way they can be replayed later. Like any other code today, these scripts are kept under version control, can go via Continuous Integration, and be applied using Continuous Deployment.

You can also read on Wikipedia about it https://en.wikipedia.org/wiki/Infrastructure_as_code

Why we bother?

Any new artifact adds complexity to a project: it should be documented, versioned, tested. There should be a really good reason for adding infrastructure code to the project. There are a few reasons:

• New Time Machine for Infrastructure:

By replaying the code, we can recreate the infrastructure from scratch on-demand. By adding few demands into the code to avoid uniqueness constraints imposed by the underlying APIs, the code can create a new and clean environment any time we need it: when we start testing our product when engineers don’t want to deal with problems caused by conflicting changes in a shared environment when engineers reprint production environment to troubleshoot a recently observed problem when the team wants to make sure the release process will be smooth and without any astonishments.

• Needs of the hour:

Engineers don’t have to remember how their colleague configured something a year ago — it is all in the code under version control.

The infrastructure code can go through the same best practices or compliance requirements like code review, or separation of concerns when any changes going to production should get a thumbs up from a gatekeeper.

The infrastructure code can be versioned with the product. It means engineers can recreate the infrastructure as it was when some previous version of the product was released.

It’s Good and Bad too

• · Complexity is not so simple caused by the new type of code: how will we test infrastructure changes, what are best practices for the code, how to apply changes to the infrastructure avoiding significant downtimes

• · It’s economic, cost caused by the creation of various copies of the infrastructure: a team of 60 can either share a development, QA, and production environments or they can start creating 60 different quite expensive environments.

• · No Time to code because instead of making few clicks in a console, the change has to be codded, tested, reviewed, and only after that applied.

Engineers should clearly understand the pros and cons of the IaC, understand the cost (time, people, infrastructure, reputation) of doing and not doing IaC, and how to reduce the cost, understand the impact of the strategy they choose on the product, have a plan how to change the strategy if they picked the wrong path initially.

Moving ahead:

There is now a stack of products like Terraform, Chef, Puppet, Ansible, and Juju, etc. They are making the life of the DevOps engineer also shrink the artifact of the Architects. The reference architecture of IaC can be standardized to be used as a blueprint for every on-prem and cloud.

My visualization IaC will evolve with ML and AI together, the bots will be able to build the IaC code; what’s coming from Terraforma and Ansible. With Intelligence Automation, even testing has reached maturity. The IaC engineering will be Ai controlled and managed. Architects need to start artifacts to get IaC to build by Bots with the Watson platform.