Many organizations and teams still use manual configuration changes, execute custom scripts manually (in Bash or PowerShell), and use non-automated tools and golden images to build and manage their infrastructure. This results in (human) errors and slow deployments.
By approaching the development of infrastructure in the same way as software development, it is possible to perform reliable deployments much faster. By using IaC, the same development processes and tools can be used for both infrastructure and software development — such as version control, continuous integration, deployment pipelines, code review, automatic testing and automatic rollback capabilities — making infrastructure changes easier, faster, safer and more reliable.
The functionalities and possibilities of IaC make it a mechanism that every company should use when setting up and managing a public cloud environment. Large cloud suppliers such as Amazon, Google and Azure invest heavily in IaC for a reason. They believe it is the only way to build reliable, scalable, and manageable public cloud environments.
Nevertheless, too often IaC is not used to its full potential. An important reason for this is that working via IaC requires an infrastructure engineer with a developer mindset. "Traditional" infrastructure engineers are forced to write software to be able to build an infrastructure, and that requires a different skill set. Large enterprise organizations often have employees who only deal with infrastructure and have not yet mastered these new developer skills, or will never be able to master it.
This does not only apply to engineers within large organizations. Many companies are aware of the possibilities of the public cloud, but run into the limitations of cloud suppliers. It is well-known that parties that set up and manage public cloud environments for companies do not have the right skill set to build environments using the IaC principle. Many cloud infrastructures are clicked together on the public cloud via the console and servers are updated manually.
There are several reasons why IaC should be considered the go-to option. First of all, it offers the possibility of repeating and replicating deployments very easily. A test environment is logged in code and at the push of a button a blueprint is created that can be the same for both the acceptance and the production environment, and the sizing can be adjusted by means of parameters.
Building via IaC also offers organizations opportunities to enforce best practices. A blueprint consists of components that determine what an environment should look like when it comes to monitoring, scalability, and security and compliance. The need to draft these again and again is eliminated.
For many companies transitioning to the public cloud is difficult, if not impossible, to make the solutions that run on this public cloud meet the security and compliance requirements for obtaining certifications such as ISO 27001 and ISO 9001. By applying IaC and the aforementioned best practices that this enforces, achieving the required certifications is a step closer.
IaC also makes it possible for public cloud environments to automatically implement blueprints in different environments that are compatible with application lifecycle management. This way, human errors are kept to a minimum, and the possibilities to comply with the strict security and compliance requirements are maximized.
In short, a compliant public cloud environment comes within reach when you are using the right tools, processes and expertise.
Luc van Donkersgoed, Head of AWS Technology @ Sentia Group, has over fifteen years of experience in software development and cloud. Through his roles as entrepreneur, developer, architect, trainer, public speaker and writer, his main drives are solving real-world problems with future-proof technical solutions, educating current and upcoming generations of engineers
Find me on