I guess you could say that Infrastructure as Code (IaC) is now fully mature and should be your default way of deploying infrastructure. If you’re unfamiliar with the concept and benefits of IaC, see the next paragraph; otherwise skip it.
With IaC, IT teams can deploy and manage all their computer infrastructure using definition files, instead of manually configuring and listing hardware. The definition files are part of specialised IaC software such as Ansible, which executes what’s in the files and automatically configures the – usually virtualised – servers or applications. The definition files are mostly in a version control system that allows you to keep track of changes. The IaC approach saves time because automated configuring makes things much faster and with almost zero error, saving your IT team from having to rework things. An IT infrastructure specialist just needs a couple of days of training to learn how to work with an IaC tool.
Despite the fact that everyone agrees about using the IaC approach everywhere, there is still another step to take. The main driver here is ensuring that IT keeps control over IT. In most organisations, the ever-increasing demands of the business people will lead to comparisons of all internal IT services with what the public cloud offers for a transparent monthly fee. If you want to avoid the threat of massive shadow IT, next-level IaC can help.
So what are we talking about here? It’s all to do with bringing down the IaC walls between your different IT infrastructure departments. Too often, we see that the database team has developed its own IaC approach, as has the application team, the server OS team, and so on. They’re all working with IaC, but each team does it in its own way, desperately protecting its own work. We think they’re wrong for three reasons.
First of all, because your internal clients – the business people – don’t really care how you’re organised or that requests go from one team to another. Your clients will compare internal IT with what they know best and that’s cloud solutions. They are used to comparing specs lists and monthly prices online and that’s about it. What’s more, your clients look at IT as a unified organisation and they expect a single point of contact with a straightforward story. So your approach should reflect this. Excuses like “We’re a bit behind because your request is currently stuck with the database team, but they’ll handle it later this week”, won’t impress them. Honestly, they don’t care about your team structure – all they want is a good service.
Secondly, one overall IaC approach can help you develop a service catalogue to provide your internal clients with self-service capabilities. The business can then configure and order the solutions that are in great demand. Your IT staff won’t have to spend time on repetitive tasks and can offer your internal clients a faster, high-quality and more clearly defined service.
Finally, who wants to be a typist? Because if every IT infrastructure department manages its own IaC system, someone has to enter the data every time a request goes from one department to the next. Nobody wants to do that tedious job, right?
So release your automation centrally in a tool such as Ansible Tower and create one single IaC system for your whole company. Everyone will benefit and thank you for it.
