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 today. With Intelligence Automation, even testing has reached the 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 like platform.?

About Author

M Senthil Kumar is Program Head of Digital Solutions & Presales for Continental Europe at TechM. In his role, he is responsible for designing and architect digital solutions for large enterprises utilizing nextgen digital solutions with AI/NLP/ML/AR/VR/IoT/RFID/QR, etc. Spearheads Enterprise Architecture, carries 20 years’ experience in IT infrastructure Service Strategy, Service Design, Services Support, Engineering, Systems and Software Architecture, Consulting, and Presales. Truly focused on customer service excellence, enable continuous improvement by assessing and identifying customer business needs.

Disclaimer: The opinions expressed on this site are mine and do not represent those of my employers (past or present) or any other entity. I give no warranty or guarantee whatsoever regarding the accuracy, reliability or completeness of the information provided on my article/website. I will not be liable to you under any circumstances for any loss or damage arising from your use of such information. Users are advised to check the accuracy of the information on this article/website.?