Isn't the entire point of vercel/netlify/cloudflare is that you *don't* have to self-host? The issue is the price of it, not the actual software.
Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected. That 10k bill is roughly $50 dedi from hetzner, but the problem with that is that you need a distributed system, for that you need something more advanced that tau, let's say kubernetes, then you need multi-site storage ok so ceph and then you realize you need a degree in openssh and bluestack to continue on and realize that the hassle from all of that and instead just hire a sysops employee that costs 10k a month and spend $1000+/month on hardware for geo-distribution.
Take this from personal experience. I've personally seen someone go k8s with very little experience and their general consensus was that they just want to go "managed" hosting instead.
Still better than 10k bill once your app becomes large enough, but it's simply not something devs that just want to get something out there want to bother with. In the end even with the insane hosting costs compared to the revenue they bring in is tiny. $10/month service user only racks in around $1 of api usage a month, heavily depends on the app though.
> Isn't the entire point of vercel/netlify/cloudflare is that you don't have to self-host? The issue is the price of it, not the actual software.
There's also a third way, which we're trying to do at stacktape[1].
We've built a PaaS platform on top of AWS, running in your own account. So you get all of the stability, flexibility and reliability of AWS, yet the deployment process is easy as using something like Heroku.
Also, compared to Vercel, the pricing is just a % on top of AWS fees, and not a sudden $10k bill, or $550/TB Netflify egress costs.
> Isn't the entire point of vercel/netlify/cloudflare is that you don't have to self-host?
No. There are two pieces to those platforms. The first is a platform that supports git commit as a deploy method out of the box. That’s the big one.
The second is auto scaling. That’s where not having to self host is actually a big deal. But that’s also where the bills come. A lot of smaller builders are right now looking to have the same deploy experience but on their own cheap hetzner/DO server without crazy bandwidth and scaling bills that they can get hit with the moment they let their guard down.
A decent sized player in this field right now is Coolify. They offer a hosted version of their PaaS but without the servers. So the PaaS part itself, coolify, is managed by them but it deploys to hardware that you control. The existence and usage of this plan is evidence of the needs of this market imo.
Firstly the git history managed via a controller / helm chart. That’s sufficiently complex. The mindset of k8s/cloudnative doesn’t translate easily from the pet vps control server which comes with its own disk and persistence. So conceptually a management layer like cooling is objectively easier.
But that’s a nit really.
I think the idea of management being time consuming is more interesting. It’s true. And I think it’s true no matter what you do.
Time consuming management applies to any sufficiently complex infrastructure or team. No matter what you have these questions to answer.
How is access ma aged?
How does debugging a broken build work?
How does secret and config management work?
How does disaster recovery work?
If you are storing config as code, how are you managing deployment of that?
If you use k8s, how do you manage feature deprecation across versions? Even a managed version won’t help you resolve having to move from some kind of resource/v1beta to resource/v1.
I don’t say this as a slam dunk against anything. I think there are different levels of comfort with certain paradigms depending on what you’ve been exposed to over your lifetime. And the solution that feels most convenient to you is what you’ll want to work with. And for each type of preference we are going to see different solutions. All of which will be time consuming to manage in their own ways at a sufficient level of complexity or scale. Basically I prefer talking in these terms because it shifts the conversation away from broad comparisons to something more tangible which is “where does the time complexity lie for this particular approach”. Teams can put that down on paper and decide which one is more palatable and then go with that.
You're right on all of these. I guess you you can compare this to comfort food.
I definitely do have the experience when it comes to geo distribution and multi-site deployments, but it's something that took me 2 years to build up to and I genuinely think that it's also not something most people have patience for or freedom for. I am lucky that I can afford to experiment with all of these things on my personal cluster and then turn that into something I deploy when dealing with customers.
Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected. That 10k bill is roughly $50 dedi from hetzner, but the problem with that is that you need a distributed system, for that you need something more advanced that tau, let's say kubernetes, then you need multi-site storage ok so ceph and then you realize you need a degree in openssh and bluestack to continue on and realize that the hassle from all of that and instead just hire a sysops employee that costs 10k a month and spend $1000+/month on hardware for geo-distribution.
Take this from personal experience. I've personally seen someone go k8s with very little experience and their general consensus was that they just want to go "managed" hosting instead.
Still better than 10k bill once your app becomes large enough, but it's simply not something devs that just want to get something out there want to bother with. In the end even with the insane hosting costs compared to the revenue they bring in is tiny. $10/month service user only racks in around $1 of api usage a month, heavily depends on the app though.