Honestly, Infrastructure-As-Code Makes Things Simpler And Easier

In this episode of TFiR: T3M, Akamai Product Marketing Manager Pavel Despot and RackN Co-Founder and CEO Rob Hirschfeld share their views on infrastructure-as-code (IaC), particularly from a vendor’s perspective.

Defining Infrastructure-as-Code (IaC):

Hirschfeld explains that IaC is the idea of turning automation into software. It can provide development-like processes with modularity, composability, reusability, and the ability to distribute and version-control automation and by extension infrastructure all the way down to that level.
With Akamai having 450,000 servers, Pavel says IaC is critical for their operations. The level of automation is not just in infrastructure, but in operations, monitoring, etc. From a product standpoint, customers are deploying SaaS solutions, media, e-commerce, all of which have to be managed. There are thousands upon thousands of VMs, functions, containers, buckets, and databases that have to be managed and these pieces are increasing, not decreasing.

On IaC adding another layer of Complexity:

Yes, IaC is one more thing to “worry” about. But the alternative, i.e., managing a ton of infrastructure components by yourself, is not going to work.
People have to recognize that it’s normal to have multiple vendors or multiple techniques or different tools that you have to connect together. It’s also normal to deal with variation and drift by building defenses for it. IaC is a way to cope with drift and sprawl. This defense adds complexity, but it also makes the system resilient.

On Collaboration:

Innovation or vendor sprawl does cause a lot of variation. The idea is for everybody to be using and adding to the same automation code and make it work for multiple scenarios. That takes a degree of curation and collaboration, but the rewards are high: no need to write stuff over and over again, less code, less maintenance.
Most of the time, people take a working script, remove all the stuff they don’t need, and make a copy of a script that only works for one scenario. They then end up with hundreds of scripts.
Open source means shared ownership and collaboration, but it requires an investment to make happen.
Automation code decays at an astoundingly high rate. You have to keep it up and keep using it. If you’re testing and collaborating on IaC, you have the opportunity to find those issues faster. Other people will find them and then share the code back with you.
Every day that goes by, those IaC libraries, the shared code, the collaboration gets baked more and more into the system. These advanced users work their logic deeper into the system, making it easier and easier to use these complex systems.

On Reusability:

The challenge with reusability is that you have to be able to pull information from system to system and then share it. It requires building an infrastructure pipeline where you have a standard sequence of operations and known points where you’re allowed to inject customization.
People can take standard infrastructure, plug it in, and it does the right thing because we’ve gotten the shared body of knowledge of how to run the infrastructure and codified it using IaC. It’s portable, reusable, and has version control.
IaC is creating a pathway to make infrastructure more accessible to people. More people can do that work because they don’t have to know all the nuances because the automation works in all of those cases. These processes and techniques not just get adopted, but then the knowledge gets cycled back into the communities.

This summary was written by Camille Gregory.