Article summary
SST is an infrastructure-as-code framework that automates quite a bit of deployment. I recently worked on a small project where we used it to handle our AWS setup, and for the most part, found it enjoyable to use. It made a lot of generally complex aspects of infrastructure easy to manage. That said, is it viable for production applications? And does it make infrastructure too easy? Here are some of my thoughts on it.
The Good
Setting up infrastructure and doing deployments can be one of the trickiest parts of development for those less experienced. SST removes a lot of barriers, making it easy and accessible to set up and use. Within your code, all you need is a single sst.config.ts file. Everything goes in there. You define your database, events that run on schedules, secret configuration, etc. all in one place. This reduces complex setup and abstracts a lot of the nuts-and-bolts of infrastructure away.
Deploying involves running a single command, sst deploy. That’s it. Behind the scenes, SST does all of the work for you, creating containers, buckets, instances, VPCs, and lambdas without any user input. You can get infrastructure and deployment up very quickly.
The Bad
SST handles everything, and it does not play well when you try to handle things yourself. One of the biggest foot-guns SST provides is its automation. If I were to go into AWS to make modifications to my setup myself, SST would be unaware, and what it deploys would be out of sync with the actual setup.
In general, this is pretty easy to solve with the sst refresh command, but sometimes this doesn’t behave as it should. SST stores its record of state in a bucket, and that state drives what it deploys. If that state isn’t accurate, you can find yourself running into bizarre and confusing situations.
The abstraction SST provides can also cause issues. It’s hard to follow why and how certain pieces are being set up, and if you want a deep level of control over your setup, SST doesn’t make it easy to exert this control. I found myself in some strange situations stemming from the ease of deployment.
Sometimes, I’d accidentally deploy to a nonexistent environment. This caused SST to spin up containers, buckets, databases, etc., that I didn’t even realize it was creating. Once, it stored the wrong public IP for one of my EC2 containers. This resulted in a difficult-to-track-down issue where I couldn’t tunnel into my instance.
The Verdict
When trying to get something up off the ground quickly, SST is a fantastic tool. It sometimes feels like you’re breaking some kind of software law with how easy deployment becomes. If you’re building a larger application where control over your setup is necessary, SST can become frustrating, introducing difficult to solve bugs. SST makes infrastructure very easy, and sometimes that can be a bad thing.