Potential of Infrastructure as Code Without Boilerplate
Ever had a case where you look at your infrastructure as code work and think, “why was I crazy enough to try to automate with this junk?”
If you haven't, then you haven't had a codebase at the multi thousand lines of boilerplate. You just naturally end up writing so much logic gates, just to get around the limitations of what you are using. This is true in software development, but it is especially true in a Domain Specific Language (DSL) for Infrastructure as Code (IaC). My setup has always been to use the declarative nature of Hashicorp's Terraform and AWS Cloudformation for their respective jobs. The IaC tools have worked great. I've been a heavy user of both. But it can get pretty ridiculous how much you have to do to get one single resource up and running (correctly anyway).
Moreover, if you try to do the same with a provisioner or ochestrator, then you are definitely in for multiples levels of hell. Not to say you can't go the route of using Kubernetes for your IaC implementation or Ansible in a declarative fashion. The problem is, you end up writing too much boilerplate before you ever get to what you wanted to do. Your goal ends being forever further away from your intentions.
What terraform and cloudformation get right is you need a full set of primitives to your infrastructure. It makes declarative state the goal of what you want, rather than the how you get to that state. If you try to use libraries for cloud providers directly, like boto or godo, with a programming language of choice, you end essentially building an entire in-house IaC provisioner. Requiring no difference in the level of boilerplate you write. Probably more so as you now need code to define basic primitives in a declarative fashion before you can create what you want.
However, using a generic programming language for IaC can have some strong upsides. You can get precise logic and structures that are very well defined to what you need the infrastructure to be. You can also do some classical test driven development to better define your logic. So in the past few months, I have been thinking on how to resolve the problems of having to constantly write so much boilerplate, make maintenance more manageable, and have better abstractions for core primitives I want to create on a cloud provider. Instead of trying to do this again with cloudformation and terraform, I have begun working with pulumi and AWS CDK for the ambitious goal.
I'm still early in my venture, but so far I have learned both provide much simpler definitions for resources to create. The boilerplate is extremely minimal as the tools are designed for you to create modules or packages that you extend for your needs. With both, my codebases have gone done considerably. Making maintenance actually feasible. I'm still discovering of their usage. Still, I'm really liking the ability to use a full generic programming language to do everything I need to in my IaC.