Many people rather warmly welcomed the announcement of AWS CDK. I see it as an evolution towards better IaC.
As Seth Vargo put it in his talk: not only infrastructure code should be treated as a first-class citizen in our projects.
What do we need?
The current state of the art is as follows: if you are using multiple cloud providers or many 3rd parties in a single project, in most cases, the only way to automate is either to use Terraform with necessary providers or to reinvent the wheel with your creations. I do not have to explain why the latter is inconvenient, to put it mildly.
If you have written a sizeable piece of Terraform code definitions, you know that it is a very leaky abstraction. All terms relevant to a given cloud provider are soaking into the IaC definitions.
In such an environment, there is no way to create a solid (pun intended) abstraction. Unless we will get the expressiveness of a regular programming language – then only the sky is the limit.
However, at the moment, this is not feasible anyway, as just one cloud provider can define the IaC with the use of regular programming language.
But, what if other cloud providers would adopt this approach? How can it help?
Why? The Case of Pulumi
If you haven’t heard about Pulumi, go check it out. Simplifying, it is the same great idea to use a regular programming language to define infrastructure as code, that precedes the AWS CDK.
And it supports multiple clouds. How may you ask? Yeah, here is the catch: it uses Terraform behind the scenes.
You can read here why using Terraform is rarely a good idea, IMHO. This case aches even more – especially that you lack rollback, and it surfaces pretty often to the top with error messages and leaky abstractions.
If it could leverage AWS CDK and corresponding SDKs from Google Cloud and Microsoft Azure, it would be more pleasant to work with. It would have more features (that would not be available the other way, e.g., rollback), and better feeling. In such a case, we would not have an impedance mismatch because we would use SDKs directly.
Most of the benefits were described above, and they are pretty easy to imagine. However, this may also cause some problems.
First and foremost: if you would like to unify multiple cloud providers and their services, you will have the lowest common denominator. If you are expecting to have just virtual machines, it can be a perfectly acceptable thing. However, in most cases, you are castrating the service provider, and you are ending up with a situation where nobody is satisfied (neither you nor service provider).
Secondly: you may introduce significant accidental complexity to support multiple clouds. This can be partially solved by creating an open standard, but we know how those initiatives often end up.
Call To Action
I know that after reading the last section, you may be hesitant about the whole idea of introducing the same mechanism by the other cloud providers. Still, I think that potential benefits outweigh the potential issues, so:
Dear Decisionmakers from Google Cloud and Microsoft Azure, I would like to ask you for a favor: please consider adding a mechanism similar to AWS CDK to your IaC capabilities and libraries.
I pretty please, as we would like to get rid of the leaky abstractions.