Companies are facing pressure to quickly scale their infrastructure while maintaining control and cost efficiency. Using manual methods to manage infrastructure often leads to bottlenecks, inconsistencies, and rising costs. To address these issues, many organisations are turning to Infrastructure as Code (IaC). This method helps them be more agile while scaling smoothly and staying in control.
We’ve sat down with Mykola Orlov, Head of Development and Operations Office at ELEKS, to discuss Infrastructure as a Code, best implementation practices, and how to avoid common pitfalls.
What is Infrastructure as Code as a concept?
There’s a well-known concept: "pets vs. cattle." When you treat your machines like pets, you care about them individually. But when you treat them like cattle, you operate at scale, and if one "cow" goes down, it's not a big deal. Infrastructure as Code is a practical implementation of that concept.
It allows you to manage large numbers of servers in a scalable and repeatable way. If one server fails, it's not a tragedy — you simply recreate it. Infrastructure as Code describes your infrastructure in code, rather than manually configuring everything. This brings several advantages:
- Recoverability: If something goes wrong, you can easily destroy and recreate the environment.
- Transparency: You can see what changes were made, who made them, when, and why.
- Scalability: You just change a number in your configuration to scale your infrastructure instead of manually creating more servers.
This applies to different components: VMs, networks, storage, firewalls, etc.
What common mistakes or misconceptions do companies make when starting with IaC?
I'm not sure there are many companies just starting with IaC these days, as it's already become quite standard. However, mistakes are common; they are the same as in scripting or in configuration management.
Common issues include:
- Not following conventions or best practices.
- Hardcoding values into scripts instead of using proper configuration files.
These aren’t unique to IaC, but they definitely show up in this context too.
Does IaC balance rapid changes and control, or introduce new challenges?
Well, it definitely helps. But there’s a catch. You need to invest time upfront to describe your infrastructure in code. This might slow things down initially, but in the long run, it pays off.
At first, you're spending a lot of time writing and testing your configurations. But once the infrastructure is described, your ability to respond and scale increases dramatically. For example, something that used to take several days can be done in 30 minutes or less. So, it helps in the long term and that’s what makes it powerful in the long run.
Where is Infrastructure as Code most effective?
It’s easier to answer where it’s not effective. The investment might not be justified for smaller-scale, short-lived proof-of-concept projects where there's only one environment and no expected changes. But in long-term projects, where there are multiple environments (dev, QA, stage), and where changes and scaling are likely, then IaC is absolutely worth it. So, ideally, we should assess at the beginning of a project, but in practice, that decision is often made early on by the DevOps experts or the architecture team during the design phase.
What advice would you give to someone just starting with IaC?
Well, first of all, read the documentation. This concept has been around for quite a while, and many people have already gone through the trial and error. There are well-established best practices.
So, my advice is:
- Start with official documentation.
- Explore community best practices.
- Don’t be afraid. It’s not that complicated.
What are the best resources to learn IaC?
I would recommend starting with the tooling. The most universal solution is Terraform, since it’s cloud-agnostic. Terraform has great official documentation, and that’s where I’d suggest starting.
Related insights
