[krembanan]

I think that for the average developer, these tools will soon be obsolete. For frontend applications, hosting services such as Vercel and Netlify gives a far superior DX. For backend, Vercel does the same, or other BaaS' like Supabase that gives you most you would need to create a fully fledged app with easy to use API's. The only downside I can tell, is the pricing, but compared to dev hours saved, it's probably a net benefit.

[brikis98]

If you can use a Platform as a Service (PaaS) offering like Vercel, Netlify, Heroku, etc, you absolutely should! I always recommend those types of tools as the first stop tools to anyone building software these days.

But there are many use cases that don't fit into those neat PaaS molds: typically, as a software company grows beyond one team, one service, one database, etc, they start to hit limitations with the PaaS solutions out there. As you scale, you often find you need more control than you can get from a SaaS: you may need more control over the hardware (e.g., for performance or cost reasons), or networking (e.g., you need service discovery or a service mesh to allow microservices to communicate with each other), or security (e.g., to meet compliance standards), or a hundred other items.

That's when many companies find themselves migrating to an Infrastructure as a Service (IaaS) provider like AWS, Infrastructure as Code (IaC) tools like Terraform, orchestration tools like Kubernetes, and so on. I'm guessing every software company with more than 50-100 developers ends up moving from PaaS to IaaS, and that's when developers need to understand how to use the tools covered in this blog post series.

Perhaps, some day, the PaaS tools out there will be good enough that you never have to migrate off of them, regardless of scale or requirements, but we're not there yet, and probably won't be there for a while longer.

[silversmith]

For the average developer, it's okay not to interact with these tools. All you need to interact is with the `bin/deploy-production` script the above-average developer built.

And I'd argue that with managed kubernetes solution, such as GKE Autopilot, you get roughly the same "DX", and much more flexibility to use whatever tools you fancy. GKE Autopilot manages the cluster and node availability, ingress and certificates, all you need to do is write the kubernetes yaml. As long as what you are working on fits in a docker container, you're good to go. And you're fairly good to move off of their setup, because those same yaml configs will work on AWS or self-hosted solutions, albeit with additions that fill in gaps where Google managed services lived.

[jbotdev]

What do you think people use to build systems like these?

A lot of medium/large shops build their own deployment and BaaS platforms on top of Kubernetes/Terraform/AWS. You just don’t hear about them as much because they often aren’t provided as a service externally, and aren’t open sourced. (I work with and on such platforms)

The mistake I see people often make is assuming it’s worth using such complex tools directly with a small project. People like the flexibility but don’t understand cost to build/maintain it.

[xyzzy123]

For backend, if you have a platform that allows you to run arbitrary containers, you will need to have a way to express how they are connected together, how much resource they should get, which parts should receive traffic from the Internet and so on. Any solution will tend to have about the same inherent complexity as kube yamls, this seems to be an iron law of devops.

IMHO the thing you have to trade off to get simplicity is generality. I agree that's probably the right tradeoff for 90% of apps, whether that's BaaS, heroku-alikes, language specific hosting or whatever.

Cloud providers are definitely keen on the idea that your web framework and your cloud platform could basically become the same thing.

[eandre]

The difficult with backend is dealing with state. It's easy enough to provide a simple experience when dealing with stateless frontends, backends are a very different story.

You're right that we need better tools. I'm the founder of Encore [1] which is all about bringing the simplicity of Vercel/Netlify to backend development. Not by substituting the backend for a BaaS but by building a developer experience hand-crafted for dealing with cloud infrastructure.

[1] https://encore.dev

[pdimitar]

I'll definitely review your service but in the meantime you should know my desktop (macOS) Firefox is freaking out on your website and is scrolling it in a janky manner and it keeps one CPU core at 80% for good 30 seconds after switching away from the tab.

[eandre]

Oh, thanks very much for letting me know. We'll have a look.

[newusertoday]

can it be used without creating account? also does your open source version has telemetry enabled?

[vbezhenar]

The downside is vendor lock in. What will you do when vendor will ban your website?

[synergy20]

not sure if IaC will help, I'm just started reading about it.

Indeed the cloud vendors are all lock-ins, something needs to be designed to mitigate the switching cost among cloud providers.

Each one has its own SDK and own complicated infrastructures, so far it seems impossible to switch once you started with any one of them.

[vbezhenar]

Cloud vendors are not all lock-ins. Kubernetes is an open API. If you've got your project working in Amazon, you can migrate it to GKE, Digital Ocean or just bare metal.

Yes, cloud vendors love to lock you in, but right now it's possible to use clouds in a vendor-neutral way. Managed postgres is just a postgres. Managed Kubernetes is just a Kubernetes. S3 have plenty of alternative implementations.

[synergy20]

what are the strongest competitors to S3? S3 is so dominant I rarely looked into anything else for cloud storage.

[vbezhenar]

S3 is just a protocol. Minio is one example of software which implements this protocol. You're programming against S3, using amazon SDK, but you change endpoint to another provider and it just works.

I guess it wouldn't work for all the intricacies, but for commonly used stuff it works.

[hotpotamus]

> so far it seems impossible to switch once you started with any one of them

Do you think cloud vendors (FAANG companies) are fools who have accidentally created this situation? And do you think they will stand idly by while you try to abstract away the differences between them?

[jen20]

> And do you think they will stand idly by while you try to abstract away the differences between them?

Yes - letting people try something futile and fail is much better than telling them that it is futile.

[pixl97]

Can we split the middle, they are fools, but the situation is not accidentally created?

[goodpoint]

Even better: we replace those millions of SLOC with something new and 100 times simpler.

[chii]

> The only downside I can tell, is the pricing, but compared to dev hours saved, it's probably a net benefit.

dev hours is already paid - i say that a hosted service for an app is gonna cost even more than the dev in the long run.

[krembanan]

You pay a premium to let your devs work on what matters, the actual product, not tinker with devops tools for hours on end on something that has already been solved. Something to keep in mind is that infrastructure code has to be updated and maintained as well, with services that gets handled for you. It would be interesting to see how much of a difference in price it would make over eg. a year.

[chrisandchris]

I can give you the answer: it depends.

I'm hosting at a colocation for X bucks a month. Solely the RAM I have on my servers costs X bucks a month at AWS/Azure. Maintenance overhead is small, maybe a couple hours a month.

[anaganisk]

Depends on what u consider avg developer, aren’t most developers employed by some company or enterprise? Who would definitely lock into big3?

[roflyear]

Now you have to hire not just for a specific language but a specific backend platform. Idk man.