![SST-CDK-CFN-ALL-HACKS-MEME](/assets/images/blog/2024/01/31/00-cover.png)

I've had a lot to say about SST/CDK and CloudFormation over the last couple of years. In my professional capacity as a Cloud Engineering Consultant I've been exposed to these tools more and more. I've watched adoption increase steadily across various enterprises now and I've seen the lines between Platform Infrastructure and App Infrastructure blur as a result of it.

Unfortunately I think the promises made by these new tools have been very misleading and have relied upon a massive over simplification of the Platform Engineers role and responsibilities.

This has led to misguided decision making and a belief that the role of the Platform Engineer can be rolled up into a simple additional duty of the App Developer but I've only ever seen it cause massive confusion, pain and inefficiencies.

I think you can be forgiven for thinking that App Developers can do it all with the help of tools like SST/CDK, that's the dream they seem to be selling afterall but we're a long long way from this being reality and I'm not sure it ever will be a thing or even if it should be something we strive for.

The tools just aren't mature enough and as I've been saying for a long time now, they're built on shakey foundations. I've analysed the tools and I've pointed out the many weaknesses and flaws that I thought existed, as well as the fact that other industry leading tools exist that are mature and already do everything better, certainly from a Platform Engineering and Operations perspective.

You may have read a couple of my previous rants on this blog about things I dislike about CloudFormation and CDK. CloudFormation has always sucked, always been slow. I thought CDK had a horrible API and in general the design choices and being nothing but an abstraction over CloudFormation made me want to cry.

Imagine my surprise when not only is everything I've said confirmed on a blog post but this blog post was written by none other than the SST devs. That's right the SST Gods themselves have spoken and they took that opportunity to absolutely shit on CDK and CloudFormation. I won't cover everything in this blog post, please just go and read it yourself [here](https://sst.dev/blog/moving-away-from-cdk.html). It's a doozy!

But let's go over a few of my personal highlights....

**CDK Is Not IaC, It’s a CFN Hack**

Finally it's official. CDK is not Infrastructure as Code. I've made many arguments about this and the fact that infrastructure code should be clearly expressed and easy to reason about.

Terraform is a mature industry standard product that has it's own purpose built Domain Specific Language to ensure that this is the case.

Using a general purpose language like TypeScript to interact with an abstraction like CDK which is an abstraction itself over CloudFormation just never sat right with me.

I really like the way SST put it when they said CDK is nothing more than a JSON Generator!

**Custom Resources**

CDK has something called Custom Resources. A basic escape hatch that let's CDK support additional features during deployments that otherwise can't be supported because CloudFormation templates can't run code.

These Custom Resources have been a complete nightmare in my experience. They cannot be tamed, you can't rename them or easily control anything about them such as node version they run for example. They can also severely break your deployments and even make it impossible for you to remove a broken stack afterwards.

I will be happy to never have to think about these ever again!

**SST is basically a nice debug tool**

SST admit they are where they are because they basically offered the best Live Lambda Debugger. I've made this point many times. When I wear my developer had I think SST is a great tool and makes debugging lambdas and remote AWS apps a breeze. But I absolutely do not think it should be used anywhere outside of a developer account or sandbox. When the code works then I think it should be handed over to let Platform Engineers choose the best way to deploy, secure and scale the infrastructure required.

**SST has made their intentions clear**

I've made the argument before that SST is great for the things it's designed for. It's fantastic as a debug tool. It's fantastic to quickly get a web app deployed, especially a NextJs app. But that's pretty much all I thought it was for.

The SST team has made it clear now that they see themselves being a competitor to Vercel which means being multi-cloud and also not limited to just NextJs but also becoming the best product to deploy modern web apps from any popular framework be that NextJs, Astro, Remix or even SvelteKit

Their focus is not your enterprise apps running in AWS.

**If you used CDK in your SST apps, your upgrade path is going to suck**

SST have warned that if you did fall into the trap they set of using CDK constructs then your upgrade path is going to be horrendous when moving to SST V3 unless you stuck to the very low level L1 constructs.

What this means is that anyone supporting a large V2 SST app right now has just been handed a bunch of technical debt to address in the very near future!

**SST V3 - Pulumi+Terraform FTW!**

The best news in all of this for me is that the bad tooling is being abandoned and they now have a great opportunity to build something great based on solid foundations and mature tooling as they're using a mixture of Pulumi and Terraform.

I'm actually quite looking forward to seeing V3 of SST and putting V2 with it's shaky CloudFormation foundations out of my mind forever!


Read the full SST blog about why they are ditching CDK/CFN

CDK IS A HACK

Did you enjoy this post?️

You Might Also Like

New Website!

Brrr