from Hacker News

SST: Container Support

by icar on 11/11/24, 9:51 AM with 69 comments

  • by rzodkiew on 11/11/24, 12:26 PM

    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.

  • by solatic on 11/11/24, 11:06 AM

    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.

  • by usagisushi on 11/11/24, 2:02 PM

    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

  • by mentalgear on 11/11/24, 10:43 AM

    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 !

  • by tnolet on 11/11/24, 2:21 PM

    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...

  • by coronapl on 11/11/24, 3:45 PM

    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

  • by andrew_ on 11/11/24, 2:16 PM

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

  • by datadeft on 11/11/24, 10:49 AM

    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 });

  • by taylornotswift on 11/11/24, 1:51 PM

    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.

  • by rswail on 11/12/24, 8:20 AM

    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.

  • by abrookewood on 11/11/24, 10:50 PM

    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/

  • by oulipo on 11/11/24, 1:33 PM

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

    Does this allow to create GCP / Gcloud stack?

  • by benry1 on 11/11/24, 2:50 PM

    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.

  • by douglasisshiny on 11/11/24, 5:53 PM

    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?

  • by voat on 11/11/24, 5:28 PM

    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

  • by GiorgioG on 11/11/24, 4:19 PM

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

  • by joshmarinacci on 11/11/24, 2:57 PM

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