That's the idea, I'm taking this in mind while developing redis cluster, for instance a must is the ability to create and manage clusters by using redis-trib in scripts, so that it is possible to have one click provisioning of a Redis cluster of N nodes automatically. You can see that in the unstable branch there is already some initial version of redis-trib I'm developing in this days to allow this kind of things.
What do they mean by "Spring applications"? That's quite obscure. Do they mean they handle .war J2EE applications? Or they only support Spring libraries?
I agree and I'm working with marketing folks to make this stuff more clear. There are just so many details to get a release like this out the door that some things didn't get as much attention as they deserved. But your point is well taken and I'll try to get the message cleared up as it is pretty cool IMHO.
Also look for some more technical deep dive blog posts on my blog by tomorrow at http://brainspl.at where I will clarify a bunch of this stuff.(right after I get some sleep;)
Which would mean that Clojure apps would qualify as well - now that might be interesting. We're running our apps on Amazon EC2 right now, managing Redis ourselves.
Preso just ended, small update: there will be both free + pay service. For now, everything free.
So we still don't have details, but we know the model they are pursuing.
Very interesting. I'm glad more Heroku-like services are sprining up, specially with support for Node.js
This is a much needed service, and although some solutions already exist, they're far from perfect, and there's certainly lots of space for competition.
Well, to make the license question easier, their invite request form is utterly unusable on Android. I apparently need to 'scroll to the bottom' to submit to a dubiously enforceable license before even being allowed to see their beta, exciting action made anyway imposible by the broken design.
Node.js notwithstanding, this tastes from the start like a proper enterprise service.
If only it were that easy..
For the record, the default Android browser seems to (still) have an issue with the 'overflow' CSS property, causing overflow:auto and overflow:scroll to show up as overflow:hidden. http://code.google.com/p/android/issues/detail?id=2911
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.
It definitely makes sense for VMware to build and open source this, since their core business is selling the virtualization software this runs on top of (I assume).
Though I wonder how much of it is really VMware specific, or if it would be relatively easy to port to Xen, etc.
Edit: actually it appears it might be agnostic to the virtualization layer.
It seems that VMware's long term view is that virtualisation itself is a commodity (which it is, KVM and Xen are both "good enough" already), and it's going to be the management of IT resources which is financially lucrative in the future.
Their core business today is selling vSphere 4 management with ESXi as the hypervisor, I think they see their core business in 10 years as being the management layer for your entire IT infrastructure, wherever it runs.
ESXi is excellent, I think one of the best x86 kernels in existence. The management software is nowhere near on par with it; it is finicky Windows software that doesn't match the hypervisor's speed or reliability. The long-rumoured Linux version of the management platform still has not materialised.
The Linux version of vCenter is part of vSphere 5. There's also a cross platform version of the vSphere client, though it's written in Adobe Flex, so who knows how good that'll be..
It'll be interesting to see if/when Python/Django support emerges for CloudFoundry. In the meantime, the DjangoZoom PaaS provides automated deployments of your Django app in as little as 30 seconds. Sign up for the private beta and mention that you saw this Hacker News thread to get priority in the queue. http://djangozoom.com
It doesn't seem like its different people from Heroku. If you've seen Mark Benioff's cloudforce pitch (link below), he mentions that they're partnering with VMWare to launch a PaaS similar to Heroku (which they acquired in December).
That said, I think its a bit surprising that VMWare is launching this under their branding - the machinations of large corporations continuously confound me.
"Cloud Foundry serves as the basis for the VMforce platform cloud VMware is building in tandem with Salesforce.com. Therefore, Chen tells us, developers will be able to readily move applications between VMforce and other Cloud Foundry services"
So they are both apparently releasing differently branded versions of the same stack.
There is no history in the git repos, so not clear if any of the code comes from Heroku.
Technically, so does Heroku. CloudFoundry does offer Java support, which is a bit different.
I am interested to see how it looks once it gets out of beta. I am betting it will be a solid platform, but after seeing the demo a few months ago at RubyConf, it did feel like a model I had seen before.
No worries and I am good friends with the Heroku guys and I fully give them props for lots of the pioneering ideas in this space.
This project means to take it further though and be one everyone's cloud operating system, the Linux of cloud OS's if you will. It will live or die based on the open source can build around it. I fully intend to try to build this community and nurture it so this project flourishes. The personal PaaS angle is what I'm most excited about. Whatch for my technical blog posts tomorrow after I get some rest for more info...
As someone who would like to give Heroku a bit of a twisting sometimes, I'm all for it (even if that's all it is). Having a company like VMware offer to run my Rack and Node apps side by side would be useful.
This seems fine for fun apps or testing, but I would be incredibly concerned to agree with these terms of service if I was running production software or charging for it.
From their terms of service:
b. Your Applications and Code. If You create online applications or program code using the Service, You authorize Cloud Foundry to host, copy, transmit, display and adapt such applications and program code, solely as necessary for Cloud Foundry to provide the Service in accordance with this Agreement. Subject to the above, Cloud Foundry acquires no right, title or interest from You or Your licensors under this Agreement in or to such applications or program code, including any intellectual property rights therein.
...and yet somehow you own exclusive rights to the data.
Just so I understand you correctly, does that imply that their intention is to prevent being sued if they need to change your code in order for it to work on the platform, in the event of say, an upgrade of their core infrastructure? If so, that makes a lot more sense. Thanks.
I think their intention is to not be sued if they need to redistribute your code in order to run the platform. This means they might need to copy it to other instances, send copyrightable assets (javascript, css, images) to users as is, etc.
But yes, it would also give them the right to change things as necessary to run the service. It could cover installing additional plugins like Heroku does, or munging config files, or even doing things like partially compiling source to some target.
By default, they really don't have the legal right to do a bunch of those things. Some of them are vague and arguable since hosting doesn't exactly fit into copyright law all the time, so companies will sometimes put in clauses like this that explicitly grant them rights that might otherwise seem like common sense. It may be obvious to you and me, but it's now spelled out in an agreement "just in case".
For example, if you upload a Rails 3 application that (as per the default) disables serving javascript and html files, CloudFoundry (and any PaaS that runs Rack basically) have to flip that switch for you. I believe that clause just makes sure such things are permitted. For Java apps, you have to generate XML files containing whatever the values turned out to be at runtime, etc.
