Infrastructure as Code: Templates vs. App-Centric Infrastructure

Take a moment and envision what your ideal future is for the world of infrastructure provisioning. 

Are you envisioning a team of people dedicated to creating customized components and then chasing down the developers using those components every time some part needs a version update? 

Or is the ideal future one where a team of people are experts on infrastructure and its ever-changing offerings, up to date standards and components are in place, and developers bring their applications and have those standards and components automatically fitted to those applications?

I’m here to make the case for an application-centered approach to infrastructure as the way to move flexibly into the future. Stop chasing teammates or templates, and start chasing innovation.

History of IaC Templates

Infrastructure as Code (IaC) was a really helpful step forward for automating and streamlining infrastructure provisioning. As soon as it became great, the question of how to spread IaC to a wider set of users immediately arose. Surely there was a way, given that IaC enables automating infrastructure provisioning, to get it into the hands of application developers, data engineers, and others who used to have to wait in a queue to be handed infrastructure by an overworked DevOps or Platform team?

Adoption swells and onto the scene steps IaC templates. Templates seemed like an obvious win. Let these end users who need infrastructure pick and choose the components they need from an approved, standardized list, fill in the blanks for their specific teams or needs, and then easily get IaC from those pre-packaged components without having to write IaC. Win-win, right?Disadvantages of IaC templates.

Well, not exactly win-win. Because one of the common pitfalls of IaC templates is that when a security patch or other update is released, the component needs to be updated. On Day 2 (or Day 202), when (not if) a resource in the old version has a required security patch, or needs to be upgraded because it’s end-of-life, the team that created the templates needs to get end users to update from an old version of the template. Except it’s a team of 12 people, and some of them copied the templates to local drives and repos and they keep forgetting to update the IaC template. This can be extremely painful, time-consuming, and can be a source of security risks.

This assumes that these end users knew: which component templates to pick, how to stitch those component templates together, read the docs accompanying the templates to know how to fill them out correctly, etc. Because if they don’t, they are back to the question queue. And once they figure out how to fill the templates out, they are even more likely to copy/paste moving forward because they know for sure that the one they have works.

This doesn’t quite live up to the promise of automating infrastructure provisioning for everyone, does it? It still seems like end users are getting interrupted from their routine workflows to get the infrastructure they need to deploy their apps, etc. And teams are spending a lot of time addressing IaC template maintenance challenges.

Apps are King

Luckily, we are not stuck in this wasteland of partially automated workflows! The most successful companies have found ways to both abstract infrastructure AND build provisioning into devs’ existing workflows. By focusing the infrastructure needs on fitting the applications or programs they are meant to deploy (an application-centric approach) rather than trying to fit the app or program into the infrastructure architecture laid out (template-centric approach), infrastructure becomes more streamlined, less wasteful, and more secure (no more accidental permissions to S3 buckets you don’t really need!).

There are many ways to do this and a lot of tools to help along the way, but to start there are three ways to overcome challenges with IaC templates by using an application-centric infrastructure approach:

1. Keep end users in their day-to-day workflows and build provisioning tools into those workflows. Infrastructure from code (IfC), for example,  allows users to create infrastructure from their application code. 
2. Use standards rather than templates in these provisioning tools. Rather than requiring end users to know about infrastructure, use standards to ask questions about end users’ applications that then select the right infrastructure for the application using the standard along with the application’s needs. 
3. Minimize the amount of input and knowledge needed from end users. Keep the expertise requirements for the experts, the DevOps/Platform teams.

The Future is Focused and Flexible

The future is asking more of us. As applications get larger and APIs more intertwined and complex, building a production-quality product is harder than ever. We’re all being asked to do more with less, and to do it faster than ever. To win in this environment means being focused on delivering high-quality products to our users, but in order to do that, we have to tailor the infrastructure we’re building to its context: the application. And it’s very hard to do that in a one-size-fits-all template-centered organization. We must look to application-centric approaches.