3 ms·

> 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

by nstart 2y ago

> 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.

kachapopopow 2y ago
The management when something goes wrong (take this from experience) is very time consuming, especially if you lack experience and/or dedicated staff. Git history deployments is a simple k8s controller, pretty sure there's a helm chart for that. Autoscaling is what I mean by kubernetes so yes totally agree. Coolify seems pretty neat. Still has the overhead of management when dealing with clustering and multi-site.
- nstart 2y ago
  Some good points to discuss here. 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.
  - kachapopopow 2y ago
    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.

by nstart 2y ago

kachapopopow 2y ago

The management when something goes wrong (take this from experience) is very time consuming, especially if you lack experience and/or dedicated staff. Git history deployments is a simple k8s controller, pretty sure there's a helm chart for that. Autoscaling is what I mean by kubernetes so yes totally agree. Coolify seems pretty neat. Still has the overhead of management when dealing with clustering and multi-site.

nstart 2y ago
Some good points to discuss here. 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.
- kachapopopow 2y ago
  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.