Infrastructure-as-Code Sounds Scary
One of my readers preparing for public cloud deployment sent me an interesting observation:
I pushed to use infrastructure-as-code as we move to Azure, but I’m receiving a lot of pushback due to most of the involved parties not having any experience with code. Management is scared to use any kind of “homegrown” tools that only a few would understand. I feel like I’m stuck deploying and managing the environment manually.
It looks like a bad case of suboptimal terminology for this particular audience. For whatever reason, some infrastructure engineers prefer to stay as far away from programming as possible1, and infrastructure-as-code sounds like programming to them.
In reality, infrastructure-as-code means using the same methodology to handle your infrastructure configuration as you would use for your source code:
- It has to be in a text file (so it’s possible to diff the changes)
- It has to be machine-readable and human-readable (goodbye, XML and JSON 😜)
- It better be managed with a version control system.
We already have most of that in networking; it’s called device configurations. A similar concept is completely absent in most server virtualization products (including vSphere and Hyper-V), network virtualization products, including VMware NSX and (to a large extent) Cisco ACI2, and all private and public clouds I’m aware of.
Instead of saying “we should use infrastructure-as-code,” try persuading your peers with “wouldn’t it be great if we would have a configuration file documenting how our cloud networking is configured instead of chasing parameters across GUI screens?” Bonus points if you manage to add version control on top of that.
As for the “homegrown” tools: there are numerous well-known intent-based tools that deal with the CRUD API hell. Some of them are provided by the public cloud providers (CloudFormation for AWS or Resource Manager for Azure); the best-known third-party tool with enterprise-grade is probably Terraform. There is absolutely no need to develop new tools to have a well-managed public cloud deployment. All you need are popular tools you can get as free or commercially supported variants, a bit of planning, and a well-defined workflow (for a longer answer watch this video from the June 2022 Design Clinic).
You can also use the examples in the ipSpace.net Public Cloud GitHub repository to help you get started, and a bunch of ipSpace.net webinars to learn more about public cloud networking:
- Cloud 101 webinar to get the initial orientation
- Azure and AWS webinars if you’re looking for a deep dive into provider-specific technologies
- Networking in Public Cloud Deployments online course if you’re interested in design- and architecture aspects.
I'm more or less on the same boat (except it's network automation in my case) as $reader and I feel this. Management doesn't care if we take hours/days to do certain tasks as long as we don't break anything and my colleagues already struggle with some of the more "advanced" (L3VPN) technologies in our network, so I can't imagine having to teach them about ansible or git.