I was suprised no virtualisation is included in the solution (or I did not find the parts in the github repos). Seriously, shared-hosting is so 1996 from a security perspective.
So for me It will be "just" an "internal cloud" solution and maybe replace capistrano. Still, puppet and chef will do the "physical"/"system" provisioning for my customers and my projects.
Virtualization isn't the only way to isolate apps. What happened to good old Unix user accounts? It seems ridiculous to me to allocate entire kernels and OS runtimes per user/app when they can just share all that stuff and have the kernel isolate access and divide resources.
Because since then code has got more hostile. Arbitrary code execution attacks and then local root exploits are not uncommon. You have to make some effort to protect against these. Lxc as mentioned at least isolates processes, file system and network access which helps a lot.
I've used linux-vserver.org years ago and lxc, which is in the official kernel, looks promising. This would be relativly efficient and secure (ok, one kernel exploit => all instances)
Shared hosting is now called "Multi-tenant", and that is how Heroku, Google Appengine, Windows Azure and other multi-tenant PaaS hosters work. Their thousands of users don't seem to mind.
As far as I can make out so far it is not designed to be multitenant. Each client gets an instance for their apps which can consist of multiple VMs. Based on interpreting the install guide here https://github.com/cloudfoundry/vcap
It currently supports multi-tenant and single tenant, you choose when you set it up.
Currently the multi-tenancy is based on locked down unix users and permissions and other system hardening, pretty much same approach Heroku uses so you judge whether that's multi-tenant or not. We are looking into lightweight containers like lxc and friends for another implementation of the multi-tenancy.
In web hosting, virtualization is usually excuse for bad design. Personally I'm glad that VMware (virtualization company!) managed to pull this without it.
Comments
I was suprised no virtualisation is included in the solution (or I did not find the parts in the github repos). Seriously, shared-hosting is so 1996 from a security perspective.
So for me It will be "just" an "internal cloud" solution and maybe replace capistrano. Still, puppet and chef will do the "physical"/"system" provisioning for my customers and my projects.
Virtualization isn't the only way to isolate apps. What happened to good old Unix user accounts? It seems ridiculous to me to allocate entire kernels and OS runtimes per user/app when they can just share all that stuff and have the kernel isolate access and divide resources.
Because since then code has got more hostile. Arbitrary code execution attacks and then local root exploits are not uncommon. You have to make some effort to protect against these. Lxc as mentioned at least isolates processes, file system and network access which helps a lot.
I've used linux-vserver.org years ago and lxc, which is in the official kernel, looks promising. This would be relativly efficient and secure (ok, one kernel exploit => all instances)
> shared-hosting is so 1996
Shared hosting is now called "Multi-tenant", and that is how Heroku, Google Appengine, Windows Azure and other multi-tenant PaaS hosters work. Their thousands of users don't seem to mind.
As far as I can make out so far it is not designed to be multitenant. Each client gets an instance for their apps which can consist of multiple VMs. Based on interpreting the install guide here https://github.com/cloudfoundry/vcap
It currently supports multi-tenant and single tenant, you choose when you set it up.
Currently the multi-tenancy is based on locked down unix users and permissions and other system hardening, pretty much same approach Heroku uses so you judge whether that's multi-tenant or not. We are looking into lightweight containers like lxc and friends for another implementation of the multi-tenancy.
In web hosting, virtualization is usually excuse for bad design. Personally I'm glad that VMware (virtualization company!) managed to pull this without it.