![Terraform](/assets/images/blog/2023/10/03/00-cover.png)

I have thought about this for a while now and I need to discuss what a nightmare it is to work with 
SST/CDK/CloudFormation in an enterprise environment. SST an abstraction over an abstraction (CDK) which is itself an 
abstraction of CloudFormation. 3 layers of indirection away from your actual cloud resources.

**YES** it is as painful as it sounds.

> TLDR: CloudFormation sucks. CDK really sucks. SST is great at the things it controls but unfortunately its 
> foundations SUCK.
> But there is hope. SST are looking at a version that is based on Terraform.

Before I go any further if you haven't already read my [post](https://www.liam-reilly.info/blog/post/serverless-infra/) 
on Serverless Framework/CloudFormation please do so now. It's funny I've just re-read this post now and I realise how 
many of the issues I've experienced with SST/CDK/CloudFormation on this current project were things I've already 
documented and complained about over a year ago on another enterprise project using Serverless Framework and 
CloudFormation rather than SST, CDK and CloudFormation.

Guess what? CloudFormation sucks!

Anyway back to this post...

---
If you ask me about SST with my software engineer head on I will tell you that I think it is a cool piece of technology 
that really helps improve the day-to-day developer experience. It makes it quick and easy to write and debug our 
Serverless code and the way it proxies messages between your local machine and AWS is as close to magic as I can 
remember experiencing in a long time.

If you ask me about SST with my enterprise platform engineering head on I will tell you I hate it and I never want to 
hear of it again. Out of the box it's wild and out of control and without a decent level of knowledge it's impossible to
tame. Most of the problems I've seen in the wild come from a lack of understanding and a lack of explicit configuration 
which is possible to add if you know what you need, but I think SST is targeting people that don't have this knowledge!

Sadly I think SST also suffers from some unfortunate limitations that they cannot control that come from the CDK 
foundations it is built on.

Because of this it makes managing AWS infrastructure in an enterprise project far more difficult that any other tool 
I've used yet.

My pain comes not really from SST but from its shaky foundations. CloudFormation is not my favourite technology in the 
first place and I think it comes with many limitation and problems of its own but CDK is a truly half-baked, unfinished 
and poorly designed product from Amazon which I really wish didn't exist.

Together SST, CDK and CloudFormation make my day-to-day life an absolute misery.

---

Again I'd like to re-iterate I do not blame nor am I attacking SST here. I think SST is a cool project and does what it 
is designed to do extremely well. I see SST as a great project to get teams moving fast with an idea. It means devs can 
concentrate on deploying and proving out an idea quickly without needing to have expert knowledge on how AWS works or 
what the different services are and how they fit together.

SST is NOT designed for large enterprise projects that already have Platform Engineering teams and expert knowledge that 
need to configure infrastructure in very specific and advanced ways.

I also think it's unfortunate that SST has built in keywords such as [use](https://docs.sst.dev/advanced/cross-stack-references)
which allow Stacks to directly reference resources that were defined in other Stacks. I understand this is helpful to 
get going quickly and could be acceptable in limited use cases and small apps, but it encourages bad practices as apps 
can grow and grow and all the different stacks can reference each other directly meaning deployments end up being a big 
ball of mud rather than small independently deployable microservices which I believe it was SST is designed for and 
would really excel at.

---
I also do not know whose idea this was but whoever decided that we should express complicated Infrastructure as Code 
using general purpose programming languages like TypeScript should retire immediately from tech. If allowing null was 
the [Billion-dollar mistake](https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/) 
then I think this is a Trillion-dollar mistake.

Platform Engineering is extremely complicated. AWS now offers more than 200 different products and services. The number 
1 thing you want when writing Infrastructure as Code is for it to be clear, declarative and concise, and follow a clear 
and consistent pattern and is easy to reason about at a glance.

Terraform was built to solve this exact problem. It has a custom-built DSL (Domain Specific Language) called [hcl](https://developer.hashicorp.com/terraform/language) 
designed in a thoughtful way to ensure that Infrastructure code is clear, concise and predictable.

Terraform allows you to write re-usable modules that you can version easily and then use across your code bases safely 
by referencing different versions by release tags. Everything you write is expressed in the same predictable way. The 
code is always very easy to follow and understand.

It even has useful concepts such as [workspaces](https://developer.hashicorp.com/terraform/language/state/workspaces) 
which mean you can write a define your infrastructure once and then switch work spaces to target different environments 
in AWS and simply use different variables based on the environment. 
You do not need to copy and paste and maintain multiple versions of the same thing because you want them in multiple 
environments.

Replacing a mature Infrastructure as Code product such as Terraform with its custom DSL with a general purpose language,
especially one as messy as TypeScript to write Infrastructure code seems to be one of the worst decisions in the 
history of computing in my opinion.

My reasoning here is four-fold.

1: TypeScript and many other languages that CDK supports allow you to write some truly messy code. The last thing you 
want for Infrastructure Code.

2: Languages like TypeScript generally attract more junior and less experienced software engineers, due to the low 
barrier to entry and online buzz amongst streamers around modern web development, this is especially true with projects
using SST as this solves for this very scenario.

3: The line between Platform Infrastructure code and Application Infrastructure code is blurred and soon becomes a big 
ball of mud that is hard to deploy.

4: Languages like TypeScript and especially tools like SST/CDK give developers a false sense of understanding of the 
complexity of building and maintaining Cloud based applications and services.

Replacing a mature product like Terraform with a truly half-baked and dare I say abandoned product like CDK is madness. 
Everyday working with CDK we discover another basic thing that it doesn't support that would have been a couple of lines
in Terraform, or we read another piece of CDK documentation that ends up being completely wrong. It does not have 
Level 2 constructs for the majority of resources that you need and some key things don't even have any Level 1 
constructs or support at all.

And this is completely ignoring the CloudFormation base and all the problems that come with that. Deploying permanent 
cross-cutting concerns and long lived infrastructure as CloudFormation stacks is not my idea of fun because you just 
cannot depend on it to pick up future changes. It might not error, but it probably won't update your resources to the 
new specification you expressed in the code base. Terraform will ALWAYS deploy exactly what is expressed in your code 
because it maintains an external state file which is analyses every time you run a `plan` or `apply`.

CDK is NOT ready for the enterprise. I would never recommend it to any of my clients. There are much better options out 
there. Much more mature products like Terraform and even Pulumi.  Neither of these products are plagued with the 
problems or slow speeds of CloudFormation, and both of these products are mature, fully featured and support multiple 
Cloud Providers.

Which leads me onto another excellent feature of Terraform. Providers. Terraform doesn't just integrate well with Cloud 
Providers such as AWS. Through its innovative Provider plugin system Terraform now allows you to integrate and work 
with many other products and services. Things like Vault for secure secret and credential management or DataDog for 
building out your monitoring dashboards. You can Terraform Kubernetes clusters, Oracle cloud resources, Microsoft 
Active Directory. The list goes on and on.

There is a reason Terraform is the defacto standard in the industry. **It just works** and Platform Engineers across 
the globe love it.

---
In summary, I do not believe it's a good idea to blur the lines between long term Platform Infrastructure and transient 
Application Infrastructure. I think there should be a clear distinction and separation between the two. 

I also do not think it's advisable to expect application developers to be responsible for building, scaling and 
securing cloud infrastructure, especially if they are relying on starter tools like SST to abstract the complicated 
truth of the services in which they depend on away from them.  

EVERYDAY I'M SST-RUGGLING

Did you enjoy this post?️

You Might Also Like

Better Testing T3 Stack Apps

HIP POP