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.
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.
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.
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.
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.
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.
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.
I guess it wouldn't work for all the intricacies, but for commonly used stuff it works.
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?
Yes - letting people try something futile and fail is much better than telling them that it is futile.
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.
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.