[HN Gopher] SST: Container Support
       ___________________________________________________________________
        
       SST: Container Support
        
       Author : icar
       Score  : 139 points
       Date   : 2024-11-11 09:51 UTC (13 hours ago)
        
 (HTM) web link (sst.dev)
 (TXT) w3m dump (sst.dev)
        
       | mentalgear wrote:
       | 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 !
        
         | hipadev23 wrote:
         | Hetzner will arbitrarily null route your traffic, proceed with
         | caution running anything important there.
        
           | diggan wrote:
           | > Hetzner will arbitrarily null route your traffic
           | 
           | Never happened to me, been using Hetzner (dedicated though,
           | not VPS) for almost 10 years. What exactly were you hosting
           | before they pulled the plug on you?
        
       | datadeft wrote:
       | 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 });
        
         | moritonal wrote:
         | If by that you mean "is IaC production-ready yet?" my answer
         | would be yes, I have lines like this in our code-base and it is
         | really impressive.
        
           | datadeft wrote:
           | And how does anybody know just looking at this line what is
           | the actual implementation? Creating new names like
           | sst.aws.Cluster that hides actual details is problematic for
           | me. ECS has three flavor as of 2024. How should I know which
           | is in use when writing that line of code?
           | 
           | Amazon ECS capacity is the infrastructure where your
           | containers run. The following is an overview of the capacity
           | options:
           | 
           | - Amazon EC2 instances in the AWS cloud
           | 
           | - Serverless (AWS Fargate) in the AWS cloud
           | 
           | - On-premises virtual machines (VM) or servers
           | 
           | One more intresting detail I found that another services are
           | not trying to hide the implementation detail.
           | const api = new sst.aws.ApiGatewayV2("MyApi", {})
        
       | solatic wrote:
       | 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.
        
         | swyx wrote:
         | does SST compile to CF? for serverless stuff (and now the
         | limited container stuff) what are the tradeoffs SST has vs CDK?
        
           | jackbravo wrote:
           | It's built on top of pulumi, and their docs have some
           | comparison against both CDK and pulumi in their FAQ section:
           | https://sst.dev/docs/#faq
        
           | wrs wrote:
           | It used to use CDK/CF. There's a long blog post about them
           | deciding CF is unusably bad and moving to Pulumi this year.
           | 
           | https://sst.dev/blog/sst-v3/
        
       | rzodkiew wrote:
       | 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.
        
         | solatic wrote:
         | Like https://sst.dev/docs/ ?
         | 
         | I wouldn't begrudge professional tooling companies trying to
         | use consumer marketing to reach early-stage projects, when most
         | early-stage projects are built by hobbyists, side-project-ists,
         | professionals-who-arent-software-professionals, etc.
        
           | lionkor wrote:
           | .. most? Im pretty sure you have a bias there. I see mostly
           | software developers with degrees and jobs producing libraries
           | and cool projects, very rarely is it the kid who never
           | programmed before, or the 60 year old farmer who wants to try
           | something new.
           | 
           | I think you're biased by the fact that the latter generates
           | more attention briefly.
        
         | Thorrez wrote:
         | The video is a parody of marketing. If you want to criticize it
         | for being irrelevant and that humor doesn't fit this situation,
         | then sure. But saying it has similar marketing to consumer
         | goods isn't really accurate.
        
           | tomhallett wrote:
           | Context for people who might not get the joke/parody: SST
           | adding containers to their stack might be viewed as a
           | "betryal" in a similar way to how some basketball fans felt
           | when LeBron James switched teams, from Cleveland Cavaliers to
           | Miami Heat. LeBron had a media event/interview called "The
           | Decision" [1].
           | 
           | I love the clip of @dhh's keynote to engineer's "learned
           | helplessness" to AWS and the cloud [2]. While SST +
           | containers is very very different than DHH's Kamal [3], they
           | both embrace containers without the paas service tax
           | (heroku/vercel/etc) or the overhead of kubernetes.
           | 
           | 1: https://www.youtube.com/watch?v=Afpgnb_9bA4
           | 
           | 2: https://youtu.be/-cEn_83zRFw?si=oAG3ZUKhXlUIKD88&t=1296
           | 
           | 3: https://kamal-deploy.org/
        
         | tolerance wrote:
         | Some people are trapped in the mindset that the only way for
         | them to be taken seriously is to go out of their way to not be
         | taken seriously.
        
         | acomms wrote:
         | What rubs you the wrong way about the video? Does it being this
         | lighthearted make you question their engineering talent? Why
         | are fun and skill mutually exclusive? I would like to know
         | since I am working on a B2B project, and contemplating wacky
         | marketing.
        
           | thdxr wrote:
           | when it comes to marketing the only thing that'll work is
           | finding your true voice
           | 
           | i made this video because it reflects my sense of humor and
           | is the kind of content i'd appreciate
           | 
           | anything outside business as usual will draw polarizing
           | reactions
           | 
           | but in a noisy world that's the only thing that'll work
           | 
           | https://x.com/thdxr/status/1848794269848637510?s=46
        
             | syoussry wrote:
             | 100%, good to see you back, love the tone your sense or
             | humor @thdxr
        
             | acomms wrote:
             | I 100% agree. I love the video and it honestly makes me
             | feel more connected to the brand. Keep up the good work, I
             | think this can only help you stand out in an increasingly
             | crowded space.
        
         | wiether wrote:
         | If you want companies to adopt your tech product, who should be
         | your main target?
         | 
         | - The junior dev with no say in decisions
         | 
         | - The seasoned contributors whose opinion is listened to but
         | who know that there is no magic tool, only compromises
         | 
         | - The managers who almost always have the last word, who live
         | with constant FOMO, and whose jobs are mostly based on
         | impressions rather than actual results
        
         | wagslane wrote:
         | It has boring well written docs. in fact very boring, and very
         | well written. the video is a banger though, I have no idea why
         | you'd want less creativity in an otherwise boring space
        
           | thierrydamiba wrote:
           | It appears that at least one person working on this is
           | connected to Prime-a tech streamer that has blown up
           | recently.
           | 
           | So I think there are some people who don't love the idea that
           | tech is being driven by content creators.
           | 
           | But the reality is a well marketed product will always
           | perform better than a well engineered product.
           | 
           | Given the fact that all these tools are interchangeable based
           | on where you want to sacrifice, I actually think it's pretty
           | cool they are doing this kind of marketing.
           | 
           | You can't win in that area on just product. And I think that
           | really brothers a certain kind of HN poster.
        
             | diggan wrote:
             | > But the reality is a well marketed product will always
             | perform better than a well engineered product.
             | 
             | Maybe not exactly a "product" in the normal sense (but
             | neither is a Terraform-in-JS thingy so) but Linux beat
             | every other competitor (in the server space) by just being
             | "better", rather than "more marketed". I'm sure there are
             | more examples out there proving "well marketed" doesn't
             | always win.
        
               | thierrydamiba wrote:
               | You have to consider your audience, and of course there
               | are exceptions-but I think you're thinking of Linux the
               | wrong way.
               | 
               | Those PR messages are a form of marketing in and of
               | themselves. It doesn't have to be a commercial on Fox
               | during football on Sunday.
               | 
               | You have to be authentic and speak to your audience.
        
             | joshmanders wrote:
             | https://anoma.ly/
             | 
             | This is a YC company.
        
         | aidenn0 wrote:
         | Over the years it has gotten simpler to have a certain level of
         | production-value. This has a few effects:
         | 
         | - The reaction of many to something simple[1] becomes "oh it
         | must be fly-by-night"
         | 
         | - It is more likely someone close to the project who can and
         | will enjoy making something slick-looking
         | 
         | - B2B companies have had reasonably slick marketing for at
         | least a decade, and there's always been a desire for many open
         | projects to look like they can "play with the big boys"
         | 
         | 1: https://motherfuckingwebsite.com/
        
       | oulipo wrote:
       | Is this developped by Pulumi? Seems a lot of the extensions are
       | made by Pulumi?
       | 
       | Does this allow to create GCP / Gcloud stack?
        
         | rhodysurf wrote:
         | You can use any pulumi provider so you can kinda use it with
         | google cloud but it wont be as nice as the AWS and cloudflare
         | support they have.
         | 
         | They dont pay any attention at all to GCP, which i get but its
         | a shame because Cloud Run is the best container platform there
         | is and def a better experience in many ways (cost, dx, etc)
         | than running a freaking ECS cluster
        
           | thdxr wrote:
           | we'll get there! we want to do everything we just go in order
           | of demand
        
             | rhodysurf wrote:
             | I get it! Keep it up
        
         | zoomzoom wrote:
         | If interested in a similar product with GCP support, check out
         | https://cncframework.com.
        
       | taylornotswift wrote:
       | 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.
        
         | meekins wrote:
         | In a sense the simplicity of SLS is a trap: immediately when
         | you need to move past the synchronous lambda invocations via
         | API GW use case (caching, service integrations, step function
         | workflows etc) you need to either fall back to plain
         | CloudFormation or rely on third party plug-ins with possible
         | problems with maintenance, quality and feature-completeness.
         | This makes it a difficult choice to recommend beyond simple use
         | cases.
        
           | taylornotswift wrote:
           | Yeah this is one area it really struggles. I built a harness
           | (using SST, actually!) for things like step functions,
           | background jobs, cron-ed tasks that I'll try to open source
           | once I clean it up a bunch.
           | 
           | I kind of see that as an unforced error on SLS's side as
           | well; AWS EventBridge is pretty simple and would make those
           | types of workflows possible, but the integration with SLS is
           | really rough.
        
         | thdxr wrote:
         | can you share more about what DX is missing?
         | 
         | v3 i think has parity with v2 minus wide support for non-js
         | runtimes
        
           | taylornotswift wrote:
           | I think it's mostly simplicity; with SLS I can have an
           | endpoint for a random function in minutes, so when I want to
           | build e.g. "return AI generated image" I reach for SLS. Then
           | as that project grows, I stay on SLS because it's just there.
           | 
           | But if I could get that set up with SST in similar time, I
           | would reach for that instead. I think SST is very feature-ful
           | and I often find myself putting _good_ thought into what I am
           | architecting when I 'm using it; but it isn't very often that
           | I want to put _good_ thought into what I am architecting when
           | I am just starting a project.
           | 
           | To give an example I am using SLS in most of my contracted
           | work; I am using SST for a project that builds other
           | projects. If you solve the "why are they reaching for SLS at
           | all" problem I think SST would be the very easy choice in
           | every scenario, if for nothing other than the sheer number of
           | providers that are supported instead of just AWS.
           | 
           | I'm sure some of this is a compromise that's tough to design
           | around, so maybe the solution here is a service built on top
           | of SST. I don't necessarily mean Vercel (am familiar with
           | your thoughts on that company), but maybe an easy graphical
           | tool or even a form that spits out my sst.config.ts for me :)
        
       | usagisushi wrote:
       | 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
        
       | andrew_ wrote:
       | Would you trust a company whose founder dances in pajamas like
       | Elaine Benes with an open laptop to deploy your infra? Sus, very
       | sus.
        
         | heyitsdave wrote:
         | yes
        
         | acomms wrote:
         | I am genuinely curious about this. I am contemplating somewhat
         | zany marketing tactics for a project I'm working on. In your
         | mind does fun =/= trust?
        
           | trevor-e wrote:
           | I think it depends entirely on the product/audience. The
           | selling points around infrastructure tooling are stability
           | and reliability. Zany marketing like this invokes an
           | "unpredictable" feeling in me which I'm not sure is a good
           | fit.
        
         | wg0 wrote:
         | I'd be more concerned about pricing and vendor lock-in.
         | 
         | Haven't tried SST though. I doubt if it works always flawlessly
         | because even plain old terraform might get stuck in complicated
         | dependency graphs failing to destroy or create/recreate
         | resources.
        
         | wagslane wrote:
         | yes. also, let's be clear... dax ain't the founder
        
       | tnolet wrote:
       | 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...
        
         | thdxr wrote:
         | that's creating the raw ecs cluster
         | 
         | these components have
         | 
         | 1. adding services that can auto scale
         | 
         | 2. specifying load balancing config
         | 
         | 3. automatic service discovery registration
         | 
         | 4. network tunnel to access vpc resources from your machine
         | 
         | 5. typesafe resource linking to access your resources in your
         | application code
         | 
         | 6. dev mode which brings up your system locally in a single
         | multiplexed terminal UI
         | 
         | not pitching - just listing out why we bother doing anything.
         | pulumi is great and if you want a more low level experience you
         | should use it
        
           | tnolet wrote:
           | I understand, that is indeed valuable. But not at all clear
           | from the documentation / copy in the linked post. I did not
           | watch the video...
        
             | jayair wrote:
             | Yeah it's something we need to get better at.
        
         | unchar1 wrote:
         | According to their docs, SST uses Pulumi under the hood [1]
         | 
         | It's supposed to be a bit easier for developers to pick up, but
         | you should be able to achieve the same thing with Pulumi AFAIU
         | 
         | [1]: https://sst.dev/docs/#faq
        
           | datadeft wrote:
           | Does Pulumi still use Terraform under the hood?
        
             | popcorncowboy wrote:
             | Does Terraform still use computers under the hood?
        
             | dilyevsky wrote:
             | I think some providers are native pulumi now, some still
             | use terraform providers
        
             | ofrzeta wrote:
             | As far as I know it doesn't, although there are some
             | "bridge" providers that do.
        
         | josiahwiebe wrote:
         | sometimes abstractions add value. one could say the same sort
         | of thing about Tailscale for example - why not just use
         | Wireguard? but the abstraction adds value imo
        
       | benry1 wrote:
       | 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.
        
       | joshmarinacci wrote:
       | I was really hoping this was about shipping containers on Super
       | Sonic Transport. Perhaps I'm jaded with software.
        
         | andrew_ wrote:
         | Came here thinking it was containers for Seriously Small Trucks
         | myself
        
       | coronapl wrote:
       | 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
        
       | GiorgioG wrote:
       | We use this at work, steer clear. Support for Windows is an
       | afterthought.
        
       | voat wrote:
       | 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
        
       | douglasisshiny wrote:
       | 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?
        
       | abrookewood wrote:
       | 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/
        
       ___________________________________________________________________
       (page generated 2024-11-11 23:01 UTC)