SST: Container Support

The whole tech looks kinda' cool, but this video...

I've noticed a trend where some of the dev tooling nowadays is sold almost as if it were consumer goods with the whole associated marketing behind it. This doesn't work for me, in reality actually has completely opposite effect. Give me boring well-written docs, that shows engineering that went into it, not the marketing show for teenagers.

Readers who are unfamiliar with SST would do well to read a bit about the project, the backing company, and the work they've been doing. Things have come around full-bore from serverless-only on AWS via CDK, putting huge effort into trying to make CDK fast and seamless, realizing they needed to support more than AWS and that CDK/CF are just too slow, transitioning into a Pulumi backend, supporting other clouds, and now, containers.

SST is great because they built a model for infra-as-code that gives sensible defaults out-of-the-box while preserving enormous flexibility as the architecture grows, plus great conventions around giving code access to the environment details via bindings.

Super excited to play with this.

SST (v3, ion) is awesome! Its live Lambda debugging feature totally changes the way I develop Lambda functions. It has the potential to be a cloud vendor-independent alternative to AWS Amplify Gen2.

Since SST allows you to use Pulumi code, you can code your infrastructure extensively even if some resources are not directly supported by SST itself. However, for such usage, it also has rough edges inherited from Pulumi. For instance, I encountered issues with cyclic dependencies [1] between resources and incomplete deployments. It would be great if I could run the Pulumi CLI against my SST stack.

[1]: https://github.com/pulumi/pulumi/issues/3021

Container support in SST is a great addition! But I’d really like to see support for other providers like Hetzner or VPS services in general, which often offer a more cost-effective option. [Update: seems like SST offers a lot of providers (incl. Hetzner) with varying feature sets, only most to all examples are using aws in the guide]

--

For example, SST's AWS costs example:

- AWS Fargate: 0.25 vCPU, 0.5 GB RAM, 20GB SSD: ~$13/month

- AWS Load Balancer: ~$3/month

Total: ~$17/month (rounded up)

--

In comparison, a similar (even more powerful) setup on Hetzner can be significantly more affordable:

- Hetzner VPS: 2 vCPU, 4 GB RAM, 20 GB SSD for ~ $5/month

  -- Coolify

    --- app containers

    --- load balancing

Total: around $5/month.

---

Alternatively, you can offload server management to Coolify Cloud for an extra ~ $5/month, so your Hetzner resources are dedicated solely to running your containers.

- Hetzner VPS + Coolify Cloud: ~ $10/month

You can scale vertically via Hetzner (rescale) and horizontally via Coolify (add more servers).

A more budget-friendly option like this could be valuable for users running small to medium, even larger setups !

Why not just use Pulumi? The code would be almost exactly the same?

  import * as pulumi from "@pulumi/pulumi";
  import * as aws from "@pulumi/aws";


  const cluster = new aws.ecs.Cluster("my-cluster", {
    name: "my-cluster",
  });

  export const clusterName = cluster.name;

https://www.pulumi.com/registry/packages/aws/api-docs/ecs/cl...

I'm really happy to see the SST team pushing this forward. A few months ago, I wrote about how SST is becoming a flexible framework that lets you start with a simple serverless approach and easily migrate to containers. This is my blog post in case someone is interested:

https://pablosblog.dev/posts/1

Would you trust a company whose founder dances in pajamas like Elaine Benes with an open laptop to deploy your infra? Sus, very sus.

I am wondering if this is actually a pattern that we can use to build a production system:

    const cluster = new sst.aws.Cluster("MyCluster", { vpc });

I really like SST compared to SLS because it is by far more featured and actually supports multi-cloud. This kind of cements that as you can deploy nearly anything with it now.

But, if I was going to start a new project today, I would probably reach for SLS, because it is simpler and faster to get set up. I think SST sometimes gets in its own way with complex IaaC config; if I wanted to do all this then I would reach for Terraform, and part of the appeal of serverless is the low lift to getting to "deployed."

So I think it's really cool that SST is adding all these things and exploring areas outside trad serverless to expand and grow new user bases. I also think this kinda sucks for people who have been with SST for a while and waiting for improvements to the DX for serverless (the functionality is there, the DX is not). I'm sure lots of thought went into this decision, but I still think it would be profoundly "worth it" for SST to tackle DX again, or for someone to build a wrapper around it.

I tried Pulumi 5 years ago because the idea looked cool and you could write code instead of HCL and apply things like loops etc.

However, the problem I found was that a Pulumi provider has two "sides", one is on the Pulumi side of the provider, which sets up resources to be created, but doesn't update them with the details of what's been created.

Example (may not be entirely accurate): You create a VPC, but then you want to use the default subnet as an input to another resource. You can't find out that subnet's information because when Pulumi runs, the "script" side doesn't get updated by the result of the VPC creation, so the information like the default subnet is "inside" the provider and not available to the user's script.

Terraform updates the resource that has been created with the information from the creation, so you can access the underlying AWS information in further resources.

What is SST? "SST is a framework that makes it easy to build modern full-stack applications on your own infrastructure. What makes SST different is that your entire app is defined in code — in a single sst.config.ts file. This includes databases, buckets, queues, Stripe webhooks, or any one of 150+ providers." See: https://sst.dev/docs/

Is this developped by Pulumi? Seems a lot of the extensions are made by Pulumi?

Does this allow to create GCP / Gcloud stack?

I'm a big fan of SSTv2, I've built most of my production services around it the last couple years. I'm excited to try out Ion and I think containers are a great addition.

I've played around with sst v2 and now v3/ion for side projects and like it a lot.

Is there a timeline/roadmap for supporting the languages noted on the bottom of the post?

I wish there was more on the philosophical change from server less to containers.

And on the video, I like it

And the docs are very nice

We use this at work, steer clear. Support for Windows is an afterthought.

I was really hoping this was about shipping containers on Super Sonic Transport. Perhaps I’m jaded with software.