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.
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
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.
> 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.
Interesting I was not aware of this. Wish them all the luck and hope they become the next unicorn. The people working on this seem extremely competent.
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.
.. 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.
I may be biased, but I wouldn't be the only one :) There are so many great new projects getting started in South America, Middle East, Asia, Africa being built by people from non-traditional backgrounds who see software as a ladder to a middle-class or upper-middle-class livelihood. Just because their products sell to markets you're not familiar with, doesn't mean they don't exist.
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
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.
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.
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.
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.
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"
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.
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.
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]
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 !
> 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?
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
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:
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.
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.
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.
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.
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.
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.
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.
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 :)
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/
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
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.
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.
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
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.
> 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.
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.
https://anoma.ly/
This is a YC company.
Interesting I was not aware of this. Wish them all the luck and hope they become the next unicorn. The people working on this seem extremely competent.
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.
.. 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.
> I see
I may be biased, but I wouldn't be the only one :) There are so many great new projects getting started in South America, Middle East, Asia, Africa being built by people from non-traditional backgrounds who see software as a ladder to a middle-class or upper-middle-class livelihood. Just because their products sell to markets you're not familiar with, doesn't mean they don't exist.
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
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.
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
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.
100%, good to see you back, love the tone your sense or humor @thdxr
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.
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/
It's satire and it's hilarious. The fact that you thought it was a serious calculated marketing move honestly makes it even more hilarious.
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.
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/
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.
does SST compile to CF? for serverless stuff (and now the limited container stuff) what are the tradeoffs SST has vs CDK?
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/
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
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
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 !
Hetzner will arbitrarily null route your traffic, proceed with caution running anything important there.
> 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?
A web-based multiplayer-game operating over websockets. They turned off my server a few hours into launch day.
Why not just use Pulumi? The code would be almost exactly the same?
https://www.pulumi.com/registry/packages/aws/api-docs/ecs/cl...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
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...
Yeah it's something we need to get better at.
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
Does Pulumi still use Terraform under the hood?
As far as I know it doesn't, although there are some "bridge" providers that do.
I think some providers are native pulumi now, some still use terraform providers
Does Terraform still use computers under the hood?
does computers still use electric sand under the hood?
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
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'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.
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?
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.
yes. also, let's be clear... dax ain't the founder
yes
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.
I am wondering if this is actually a pattern that we can use to build a production system:
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.
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.
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.
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.
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.
can you share more about what DX is missing?
v3 i think has parity with v2 minus wide support for non-js runtimes
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 :)
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?
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
we'll get there! we want to do everything we just go in order of demand
I get it! Keep it up
If interested in a similar product with GCP support, check out https://cncframework.com.
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.
[dead]
I was really hoping this was about shipping containers on Super Sonic Transport. Perhaps I’m jaded with software.
Came here thinking it was containers for Seriously Small Trucks myself