3 ms·

I'm surprised containers aren't mentioned once. With mass virtual hosting (not virtualisation, think in terms of vhosts in Apache) resource sharing and securit

I'm surprised containers aren't mentioned once. With mass virtual hosting (not virtualisation, think in terms of vhosts in Apache) resource sharing and security issues that aren't easily fixed with some UID/GID quota tricks and as such we got chrooted FTP, SSH and SCP, then OpenVZ at some point, and LXC. Later down the line we got container sand cgroups and even later, cgroupv2. All of them with similar goals in mind: shared resources, but strong enough isolation to not have unwanted side-effects. This is still something that exists, but isn't really used this way (as far as I can tell - only ISPConfig seems to do this?), because containers were then also used as stateless packaging methods where you don't edit anything in a running container, but rather just re-deploy the whole thing. That is of course not a good match for the article, but there is nothing preventing this from being done in a container. Heck, if you have classic shared storage (i.e. NFS) you could get any container hosting company to do this without them knowing it. But you'd still be on the hook for managing the container lifecycle...

chubot 2y ago
(author here) Yeah this is something I'd like in a host Google used/uses cgroups with just plain UID isolation, no namespaces (of course this was for mostly trusted internal users, although they became less and less trusted over time ... due to being attacked by nation states and all that) Heroku used LXC. Dreamhost does use cgroups now, but it is not configured well, as mentioned in my post (the FastCGI and SSH processes share a cgroup, which means that you can't debug when it goes wrong!) But most hosts these days just use Docker (fly.io, Render, etc.), which I think conflates a bunch of things. Not just cgroups, but also networking ... So yeah it would be nice to have modern shared hosting, without Docker, but with good resource isolation
- indigodaddy 2y ago
  Yunohost isn't really meant for shared hosting but you can have multiple "apps" on a single box and it doesn't use docker. Not sure how good the isolation/security is though.. https://yunohost.org/ https://yunohost.org/ You're right though I think the "modern shared hosting with a more paas approach but without docker and good security/isolation" is something that doesn't really exist. Perhaps someone could use Sandstorm (Kenton Varda's (pretty much abandoned now?) fantastic project/isolation technology) as a starting point and gear it towards a more "shared hosting" approach.
  - chubot 2y ago
    Yeah definitely, Sandstorm was a good effort ... they did use plain cgroups and Linux kernel features from what I remember. To me, it shows that the economics are hard. Writing things like Sandstorm isn't trivial, and having paid employees helps. But the open source, self-hosted model limits your revenue opportunities. I'm not even sure what the business model of Sandstorm was -- was it just to have a hosted version? Maybe enterprise auth features or something? --- It's obviously technically possible to do medium-scale, friendly hosting ... but it's not at all obvious from the standpoint of a self-sustaining business, or even non-profit. I think the "hyper-scalers" are basically swallowing all the engineers and sys admins, which I mentioned in this post One thing I'd liken it to is that in America, almost everyone eats the same corn, wheat, chicken, frozen Russet potatoes, etc. (or at least they are familiar with these commodities) That is, the largest food producers are "hyper-scalers", and some of them are monopolies. They cut the costs to the bone, and convinced everyone that the quality was the same, when it isn't --- I also think customer support is costly, and makes the business hard. Because the customers vary widely in their skill levels ... I almost think that if you could incentivize community support, that might help -- i.e. customers who actually help other customers could get paid perhaps ... A related thought I've had is that shared hosting companies dropped the ball on git push-to-deploy, which Heroku pioneered over 15 years ago I think SSH and shell are too hard for 50% or 90% of customers (one reason I'm working on a shell). So you have cPanel and the like. But actually I think there are a decent number of customers who'd rather use text files? And they have some kind of git GUI or whatever For example Github pages lets you check in a CNAME file for configuration - https://til.simonwillison.net/github/custom-subdomain-github-pages https://til.simonwillison.net/github/custom-subdomain-github... Although now I see that it actually has a web interface too. So I guess you still need cPanel-like things for most customers (though certainly cPanel itself is showing its age)
    - kentonv 2y ago
      > they did use plain cgroups and Linux kernel features from what I remember. Technically just Linux namespaces and seccomp. Those are the parts important for security. cgroups are more about enforcing resource limits, which Sandstorm never got around to (but planned to, eventually). > I'm not even sure what the business model of Sandstorm was We had basically two plans, and the problem is we didn't consistently follow one of them: Plan A: Make technology that excites people, especially developers, and shows fast growth and adoption. Sell investors on a long-term vision of an app store and such -- but get them to fund a big Series A pre-revenue that would allow us to develop for many years. Plan B: Sell a product to organizations (enterprise, government, etc.) that, for policy and/or compliance reasons, could not use cloud apps. There are still a lot of these! Plan A is really what we needed to stay focused on, and what our team really understood how to execute. We were actually totally succeeding at growing the developer community! But Plan B was enticing because it seemed like a faster path to revenue, and it felt like showing revenue would make our pitch even stronger. But we had no idea how to actually execute on Plan B, how to sell to those kinds of organizations. So our efforts there totally flopped. And when investors saw us fall on our faces they weren't excited to keep investing. All that is to say, I don't think it's the idea that failed, I think we failed in the execution. I had intended to keep working on Sandstorm on the side as an open source project when I joined Cloudflare, but then my work there (Cloudflare Workers) was successful, and, well, it's a lot more fun to work on something that is succeeding, so I gave up on Sandstorm.

chubot 2y ago

(author here) Yeah this is something I'd like in a host Google used/uses cgroups with just plain UID isolation, no namespaces (of course this was for mostly trusted internal users, although they became less and less trusted over time ... due to being attacked by nation states and all that) Heroku used LXC. Dreamhost does use cgroups now, but it is not configured well, as mentioned in my post (the FastCGI and SSH processes share a cgroup, which means that you can't debug when it goes wrong!) But most hosts these days just use Docker (fly.io, Render, etc.), which I think conflates a bunch of things. Not just cgroups, but also networking ... So yeah it would be nice to have modern shared hosting, without Docker, but with good resource isolation

indigodaddy 2y ago
Yunohost isn't really meant for shared hosting but you can have multiple "apps" on a single box and it doesn't use docker. Not sure how good the isolation/security is though.. https://yunohost.org/ https://yunohost.org/ You're right though I think the "modern shared hosting with a more paas approach but without docker and good security/isolation" is something that doesn't really exist. Perhaps someone could use Sandstorm (Kenton Varda's (pretty much abandoned now?) fantastic project/isolation technology) as a starting point and gear it towards a more "shared hosting" approach.
- chubot 2y ago
  Yeah definitely, Sandstorm was a good effort ... they did use plain cgroups and Linux kernel features from what I remember. To me, it shows that the economics are hard. Writing things like Sandstorm isn't trivial, and having paid employees helps. But the open source, self-hosted model limits your revenue opportunities. I'm not even sure what the business model of Sandstorm was -- was it just to have a hosted version? Maybe enterprise auth features or something? --- It's obviously technically possible to do medium-scale, friendly hosting ... but it's not at all obvious from the standpoint of a self-sustaining business, or even non-profit. I think the "hyper-scalers" are basically swallowing all the engineers and sys admins, which I mentioned in this post One thing I'd liken it to is that in America, almost everyone eats the same corn, wheat, chicken, frozen Russet potatoes, etc. (or at least they are familiar with these commodities) That is, the largest food producers are "hyper-scalers", and some of them are monopolies. They cut the costs to the bone, and convinced everyone that the quality was the same, when it isn't --- I also think customer support is costly, and makes the business hard. Because the customers vary widely in their skill levels ... I almost think that if you could incentivize community support, that might help -- i.e. customers who actually help other customers could get paid perhaps ... A related thought I've had is that shared hosting companies dropped the ball on git push-to-deploy, which Heroku pioneered over 15 years ago I think SSH and shell are too hard for 50% or 90% of customers (one reason I'm working on a shell). So you have cPanel and the like. But actually I think there are a decent number of customers who'd rather use text files? And they have some kind of git GUI or whatever For example Github pages lets you check in a CNAME file for configuration - https://til.simonwillison.net/github/custom-subdomain-github-pages https://til.simonwillison.net/github/custom-subdomain-github... Although now I see that it actually has a web interface too. So I guess you still need cPanel-like things for most customers (though certainly cPanel itself is showing its age)
  - kentonv 2y ago
    > they did use plain cgroups and Linux kernel features from what I remember. Technically just Linux namespaces and seccomp. Those are the parts important for security. cgroups are more about enforcing resource limits, which Sandstorm never got around to (but planned to, eventually). > I'm not even sure what the business model of Sandstorm was We had basically two plans, and the problem is we didn't consistently follow one of them: Plan A: Make technology that excites people, especially developers, and shows fast growth and adoption. Sell investors on a long-term vision of an app store and such -- but get them to fund a big Series A pre-revenue that would allow us to develop for many years. Plan B: Sell a product to organizations (enterprise, government, etc.) that, for policy and/or compliance reasons, could not use cloud apps. There are still a lot of these! Plan A is really what we needed to stay focused on, and what our team really understood how to execute. We were actually totally succeeding at growing the developer community! But Plan B was enticing because it seemed like a faster path to revenue, and it felt like showing revenue would make our pitch even stronger. But we had no idea how to actually execute on Plan B, how to sell to those kinds of organizations. So our efforts there totally flopped. And when investors saw us fall on our faces they weren't excited to keep investing. All that is to say, I don't think it's the idea that failed, I think we failed in the execution. I had intended to keep working on Sandstorm on the side as an open source project when I joined Cloudflare, but then my work there (Cloudflare Workers) was successful, and, well, it's a lot more fun to work on something that is succeeding, so I gave up on Sandstorm.