Infrastructure as Code in conjunction with DevOps is a new approach to managing your IT infrastructure and servers. Maybe I shouldn’t call it new as this approach exists now for quite a while, but still, a lot of IT infrastructures are managed in a traditional manner. A group of technical engineers design and build a data centre where a group of administrators ensures that the required applications run on top of the desired state. And let’s be frank, as long as this works within the given budget, it’s still a viable approach.
But, why is IaC something that should be considered and what are the pitfalls? Well, the idea of IaC is, that a set of tools interpreting some sort of coding, ensuring, that your IT infrastructure looks as described in the coding. This approach comes with some advantages:
With IaC you can easily deploy for example a baseline configuration on a few thousand servers with the execution of a single command. You can also group servers based on their roles and purpose. For example, IaC allows you to upgrade all development servers with a single command. Or you can deploy an existing workload in a new region if required. Together with standard hardware that emulates specialized features in the software layer, it’s even possible to spin up complete new logical data centres with a press of a button. The only requirement, in the end, is a few cheap standard data centres. Anything else is done via coding. If this sounds familiar to you, this is how the cloud/ hyper scaler services work, a lot of cheap hardware in a lot of data centres across the world with IaC on top.
Note: Regardless if you use IaC or how you organize your deployments or if you operate your estate on-premise or in the cloud, it all relates to the same simple architecture. A piece of software runs on some type of hardware located in whatever data centre. This consequently means that the software or the application will not suddenly start to do magic things it wasn’t capable of before. I know a lot of key accounters try to convince one differently, but this is “just” a different approach to managing your IT infrastructure, with all the benefits and downsides that come with every approach.
So, what are the pitfalls and what needs to be considered? First of all, to really utilize IaC you need to move as much functionality into the software layer as possible. The result of this emulated hardware functionality is always slower compared to dedicated hardware. Whether this matters for your specific use case or if the flexibility outweighs the downside, is a different story. Secondly, the job profile of your IT staff will change, whereas it was sufficient in the past to do a bit of configuration work, it’s now a combination of programming and configuration. You need to be skilled in both worlds. Last but not least, it takes some time before the move to IaC/ DevOps pays off. Especially in the beginning when the new processes/ technology is introduced, the costs will grow and not decrease. So, here are the pitfalls I would like to highlight that you should avoid when moving to IaC: