We’ve all done it, you go to fill out a template only to find out it’s the wrong version or lacks something you need or doesn’t quite apply to what you are doing. Templates have become a standard way to help get Infrastructure as Code (IaC) into the hands of users who might otherwise struggle to compose IaC. For a long time, I was a huge proponent of templates as a way to solve problems adopting IaC throughout an organization. But as time has gone on and the industry has evolved, I’ve come to realize that it’s time to retire templates in favor of something else: standards.
Why Templates
For day-to-day deployments and common projects, the infrastructure you need is often the same. So why rewrite the same IaC over and over? And more than that, figuring out which modules to use and in which order to invoke them takes more than a little time and experience. It’s time and experience that a lot of users who need infrastructure don’t have. Why ask them to build that knowledge for run-of-the-mill infrastructure needs? Enter: templates.
Templates arose as a way to make IaC easily repeatable for common use cases. They built on the hard-won knowledge and experience of platform engineers, including best practices and optimizations, but were easily accessible for end users (application developers, web developers, marketing engineers) who needed infrastructure to deploy their work. Or, at least, that was the goal.
Why Not Templates
The tricky thing about templates is that it’s not actually easy to make a complex thing (setting up and provisioning infrastructure) simple. Templates often still require end users to go out and find information that they don’t understand and that they are then copying and pasting in. Templates require a version control strategy and system that everyone is familiar with and using regularly. Without this strategy or system, you have template sprawl where users just keep copying the same template they used the first time and never upgrading to the newer version.
Platform engineers then get the fun task of trying to upgrade really outdated infrastructure that was built with outdated templates. And all of this assumes that templates, which are meant to be used and understood by folks with little infrastructure know-how, are written in such a way that those users can easily understand them, which is a whole skill set in itself. But how, then, can platform engineers use their plentiful knowledge and experience of building optimized, secure cloud infrastructure to help end users who need infrastructure but aren’t going to write their own IaC?
Why Standards
The best thing about templates is that they employ the rules and guidelines that are necessary for various kinds of infrastructure. These standards change way less frequently than the modules, providers, and other components underpinning templates. So what if you could just use those?
Standards stand the test of time. It’s unlikely that you are going to want to be less secure over time, or spend needless money, or never upgrade. By setting standards, which are rules and guidelines for how you want infrastructure to be built and structured, you ensure that whatever application or project is being deployed, it’s being done in a way that meets the needs of the business, the needs of the industry, and the needs of your customers. But how do you set them without templates?
Applying Standards by Default
Asking developers to memorize your standards isn’t going to get you very far (you’ll still have the same challenges as you do with templates). Instead, you want specific policies and standards to be applied when IaC is generated. This ensures that standards are automatically built-in without needing the cycle of scan-and-fix that exists with most IaC today.
Developers get applications deployed faster and platform engineers can provision the infrastructure more easily knowing that standards are by default.
There are a few places doing this right now, including appCD. appCD uses the application code to generate IaC while also enabling platform engineers to set standards at the organization level. When the IaC is generated, those standards are automatically applied, without the developer needing to know the standards at all.
Organizations benefit when standards are by default, especially when they do not need to recreate existing deployment pipelines but instead enhance them by auto-generating an important step (IaC) in the process. Teams will be more productive and infrastructure more secure.
