How IaaC actually helps you
“IMO, unless the infra-related issues are resolved and the infra is frozen, the real stabilization of the app will not even start!”, complained a product dev-lead who was more interested in finding functional defects in the integrated application, but was hearing more of the infra-related issues from the QA team.
A typical scenario – everything works on the dev setups, but when a staging setup starts to mimic the production environment, things start breaking up… Any solution? Document each and every step is taken to set up the dev environment? No way! It will give us a document with a lot of unnecessary steps the devs take up as trial and error!
IaaC aka Infrastructure-as-a-Code comes as a relief… Developers do not like to document and moreover keep the document updated all the time, but they do like to code! It doesn’t matter whether the code is written for the functionality of the product, or for maintaining the infra.
Interesting! What are the advantages of using IaaC for setups?
- A declarative language to just ‘describe’ the infra you want to create and no actual steps like shell commands.
- State saved at a central location so that there is no confusion on the changes done to the infra, even if many people across geographies are maintaining the same.
- Operating systems and other environment details are hidden under the IaaC layer.
- The platforms and systems come up with their own providers for setup. They are the best to know how to install their platform on various operating systems and environments.
- The same declarative code works on different machines, so it is a code-once-setup-many-times proposition.
- It saves costs on the cloud. Since the setup is automated we can create infra, perform tasks and tear down thus saving huge costs spent in allocating infra beforehand and keeping it idle for most of the time.
