4 ms·

Maybe. We have all sorts of tools that are reducing the administrative overhead of running a linux box, but they are far from eliminating that burden. Furthe

by lsc 13y ago

Maybe. We have all sorts of tools that are reducing the administrative overhead of running a linux box, but they are far from eliminating that burden. Further, most of the tools I've seen? webmin and the like? The thing is, it works great... Usually, for a while. Then sometimes it breaks, and it's a huge emergency, as the customer had it working just fine for a while; the customer was tricked into thinking they knew what they were doing, and now they've got an emergency on their hands, and they don't even have the training that installing the apps by hand forces on you. So yeah; the thing I see displacing shared hosting? not VPSs, but another kind of fully managed service. See, as you point out, the difficulty of managing a shared hosting host goes up with the number of customers on that host in a kindof exponential way. What if you made something like shared hosting (where the user doesn't have root access, and the host is managed by full-time sysadmins) but ran one user per host, and run each host in a VM or container or something that is managed in a largely automated way? Spend the ram/cpu overhead to better compartmentalize users and take the exponential increase in difficulty out of adding more customers to a particular bit of hardware? It's something I've thought about for a while. Problem is, the temptation to give users root on their VM would be very strong, and once that happens? well, managing thousands of hosts isn't that big of a deal... managing thousands of sysadmins? yeah. Not a job I want. Either I manage the host or you manage the host. Sharing root is a difficult, high-touch thing that requires a lot of communication. Edit: I believe that many of the platform as a service providers operate like this (e.g. your stuff runs in one or several VMs that are not shared with other users, but that you don't have root on.) Considering how cheap platform as a service is for the light users, I wonder how that model hasn't destroyed the flat-rate 'shared hosting' model? Perhaps one of the platform as a service providers needs to offer a flat monthly plan (perhaps that has the option of degrading /or/ interrupting service when usage exceeds the agreed-upon threshold, sort of in emulation of the "unlimited" providers.)

jacques_chester 13y ago
My model isn't "install some click-and-point admin" tools. As you point out, it's been done. It's that if you have an app that targets bare virtual metal, then you can push a lot of admin problems upstream to the app developers. In particular: updating. If a single app controls the whole VM, you can drastically improve the likelihood that a single update mechanism will work properly. You can even automate it. Similarly: configuring components. Right now the lowest common denominator software environment that is targeted is shared hosting. In shared hosting I cannot adjust the database, the web server and so on. So no account is made of how to make self-adjustability a part of the architecture. And so on. My point is that we should stop thinking about apps that we install on linux that are on VMs vs apps that are installed on linux in shared hosting environments. It's that the app should be conceptually be all that runs on the VM. That nobody installs "the stack", they install "the app". I think it would still be a distinct niche apart from managed systems. Edit: a re-reading of your comment suggests that, I think, we are groping towards a common concept, but from slightly different directions. If you're interested, I'll email a project proposal I wrote in 2010 about this very topic. See my profile.
- lsc 13y ago
  >In particular: updating. If a single app controls the whole VM, you can drastically improve the likelihood that a single update mechanism will work properly. You can even automate it. This is interesting. I mean, if you can get it to work. I'm bringing up the point and click admin tools, though, because that's the best comparison I can come up with that actually exists that I've seen. The thing of it is, I think that most things do eventually break. (I mean, like the kids in this thread talking about how easy an 'apt-get update; apt-get upgrade' is - it works great most of the time, then it breaks something horribly.) There are things you can do to reduce the chance of that breakage, but eh, at some point you have to login and fix the goddamn thing. Not that this breaks your model; I mean, if you are distributing, say, a blogging application; my dad is paying you $5/month and giving you login credentials on a standard VM of some type, he installs using the kernel/script you gave him, and the system uses your repos to upgrade nightly. If something does break horribly, you can login and fix it. I still think that model is easier if you include the VM in that $5/month, and you run that VM on something you control.
  - jacques_chester 13y ago
    That said, there are millions of copies of unpatched systems running on VPSes across the internet. I think that the lesser evil is automation. Possibly the upstream can borrow from continuous delivery and only "announce" the upgrade progressively, testing as it goes. I'd also be interested in the upgrade system itself. Systems which have atomic snapshotting would be more un-borkable, for example.

by lsc 13y ago

jacques_chester 13y ago

My model isn't "install some click-and-point admin" tools. As you point out, it's been done. It's that if you have an app that targets bare virtual metal, then you can push a lot of admin problems upstream to the app developers. In particular: updating. If a single app controls the whole VM, you can drastically improve the likelihood that a single update mechanism will work properly. You can even automate it. Similarly: configuring components. Right now the lowest common denominator software environment that is targeted is shared hosting. In shared hosting I cannot adjust the database, the web server and so on. So no account is made of how to make self-adjustability a part of the architecture. And so on. My point is that we should stop thinking about apps that we install on linux that are on VMs vs apps that are installed on linux in shared hosting environments. It's that the app should be conceptually be all that runs on the VM. That nobody installs "the stack", they install "the app". I think it would still be a distinct niche apart from managed systems. Edit: a re-reading of your comment suggests that, I think, we are groping towards a common concept, but from slightly different directions. If you're interested, I'll email a project proposal I wrote in 2010 about this very topic. See my profile.

lsc 13y ago
>In particular: updating. If a single app controls the whole VM, you can drastically improve the likelihood that a single update mechanism will work properly. You can even automate it. This is interesting. I mean, if you can get it to work. I'm bringing up the point and click admin tools, though, because that's the best comparison I can come up with that actually exists that I've seen. The thing of it is, I think that most things do eventually break. (I mean, like the kids in this thread talking about how easy an 'apt-get update; apt-get upgrade' is - it works great most of the time, then it breaks something horribly.) There are things you can do to reduce the chance of that breakage, but eh, at some point you have to login and fix the goddamn thing. Not that this breaks your model; I mean, if you are distributing, say, a blogging application; my dad is paying you $5/month and giving you login credentials on a standard VM of some type, he installs using the kernel/script you gave him, and the system uses your repos to upgrade nightly. If something does break horribly, you can login and fix it. I still think that model is easier if you include the VM in that $5/month, and you run that VM on something you control.
- jacques_chester 13y ago
  That said, there are millions of copies of unpatched systems running on VPSes across the internet. I think that the lesser evil is automation. Possibly the upstream can borrow from continuous delivery and only "announce" the upgrade progressively, testing as it goes. I'd also be interested in the upgrade system itself. Systems which have atomic snapshotting would be more un-borkable, for example.