The term “Infrastructure-as-Code” is often associated with DevOps. But if you’ve ever wondered what exactly is involved, and how it can benefit your enterprise, then read on…
Why you need Infrastructure-as-Code
Cloud computing, containers, virtualization and software-defined networking (SDN) have all reduced the time and effort needed to provision systems. The problem is that along with this simplicity of provisioning came growth in the numbers and scale of portfolios. This, in turn, led IT operations teams to experience considerable difficulty maintaining their infrastructure and its configuration. The majority of enterprises still configure much of the infrastructure and applications manually, which I don’t need to tell you is time-consuming, error-prone and complex. I might also add that it’s an unsustainable way of doing things, too, when you consider the future of systems management is getting more complex, not less. That’s where Infrastructure-as-Code comes in.
Infrastructure-as-Code (IaC) is the mechanism to create and apply changes to the system by treating it as software data. With IaC, the environment is managed and provisioned through templates and definition files, rather than physical hardware configuration or interactive configuration tools. The beauty of this approach is that it consists of creating consistent and repeatable routines for changing infrastructure state and configuration of the infrastructure. Being code itself, it can be versioned by making it part of a Version Control System. This allows it to take advantage of development practices like test-driven development, continuous integration and continuous deployment (CI/CD).
What you need to know about IaC
Much discussion has focused on this topic. There are papers, books and hackathons devoted to the subject, but here’s our quick take. Bear in mind there are three key practices to master if you’re serious about IaC:
1. Every configuration should be part of the configuration code; no one should be able to login to the system and make changes manually. This practice makes sure that both provisioning and configuration are repeatable and consistent.
2. Code itself becomes a self-explanatory document and process. Prior to IaC, every configuration had to be released with a document, which every deployment engineer was required to follow as part of release or provisioning.
3. Small changes should be applied to code rather than big batches. The bigger the configuration update, the more likely it is to contain an error, and the more difficult it is to detect errors.
What are the benefits?
- Provisioning and configuration of IT infrastructure are quicker, simpler and automated
- It makes migration of IT infrastructure from on-premise to cloud, or between clouds, more consistent, reliable and automated
- Infrastructure-as-Code lays the foundation for self-healing infrastructure. As provisioning and configuration of infrastructure is automated, recovery from failure is quicker
- No more snowflake servers
- IaC enables blue-green deployments, which allows you to do zero-downtime deployments
- The development team can define, provision and manage the infrastructure resource with limited or no dependency on the operations team
- No more configuration drift
- As everything is part of the version control system, it is repeatable and consistent, which in turn makes IT infrastructure more robust.
Where do I start?
Popular tools for getting IaC up and running include Chef, Puppet, Terraform, AWS CloudFormation, Microsoft Azure Resource Manager, Ansible, SaltStack, Docker and Vagrant. Infrastructure-as-Code is often viewed as part of a wider DevOps transformation, so if you want to ensure you’re choosing the best tools to integrate, say, with your CI/CD or other DevOps initiative, why not get in touch? Our impartial guidance is based on 13+ years of experience!