“We believe the current [platform clouds, such as Azure and App Engine] are incomplete,” [VMware senior director of cloud and application services Jerry] Chen says. “There is no one platform that is multi-cloud – private and public – and no one cloud is architected, out of the gate, to be extensible to many different frameworks and many different languages.”
In summary, they’ve put together a “bring your own PaaS” with wide language support and a VMware run instance you can use as well, if you don’t want to bring anything and just go directly to a cloud that has it all wired-up.
The most critical thing for VMware to do is to let this “open is best” philosophy play out in their application development strategy. VMware’s current fortunes were built on distinctly not that philosophy and it’d be easy for the kernel geniuses who must hold much of the corporate power to derail the appdev strategy, which is a much different beast than virtualization and other business models closer to the metal than the glass.
Overview via Press Pass
Nancy Gohring of IDG sent over a few questions on the topic (see her piece), so why not inline the answers here? (I’ve summarized the questions, so they’re not directly Nancy’s):
As a counter example, Microsoft has to work very hard to convince developers that it’s not some kind of “evil empire” when it comes to locking in developers to Azure. Somehow Amazon (which is pretty “open,” actually), Google, and Apple get free passes on this: the perception that a ready user base and that there’s money on the table for the clever app developer in Apple-land gets developers to put up with the otherwise heinous “developer relations” Apple does.
Will this help move developers to adopt PaaS? They’re doing the right things to position themselves well: not just being Java, hosting on GitHub (an obvious thing I wouldn’t expect any BigCo to be “smart” enough to do), and providing the PaaS layer as open source for developers to run where-ever they like. Other PaaS vendors typically choose a point of lock-in to monetize every install on, where-as what VMware appears to be doing is trying to create a giant pie of which they only monetize a several hefty slices. I hope that’s what they’re doing at least: the bad thing would be for their business folks to worry about monetizing every single Cloud Foundry instance. Coming from a shop that makes its money selling licensed software and that seems to be fast trying to be the new Microsoft, you always have to understand where VMware is going to take it’s cut and see if that fits with your architectural plans. So far, CloudFoundry looks OK on that front, though.
What’s the “big picture”? So far, most people have been pleased with this. (Although @williamlouth claims to need facial reconstruction after looking at the code.) I haven’t checked out the code or anything [over the next few weeks, expect lots of snarky commentary from those who do], but the open nature of this and the wide-range of languages they’re targeting is looking good. If VMware can make Java just one of the many technologies that run on their clouds and if they can allow anyone to use their cloud software without having to give a dime to VMware or use their tools (see “The VisualStudio Test”), they should have a good chance at building a big cloud ecosystem that they can siphon cash off from. It’s a long play, but this is a good time to be putting all the pieces into place: all of their competitors are for sure.
Cloud Foundry can be deployed in public or private clouds. It runs on top of vSphere and vCloud infrastructure but can also run on top of other infrastructure clouds. Our partner RightScale today is demonstrating the deployment of Cloud Foundry on top of Amazon Web Services. Because of the open architecture, it could also be implemented on top of other infrastructure technologies like Eucalyptus or OpenStack. —Steve Herrod, VMware CTO
Here’s what I’d expect from the competitors:
- Amazon – as always, they’ll say nothing and just keep putting out new services. Perhaps they’ll lower prices, as they often do. <EOM>
- Google – what with an existing Spring partnership, this is odder. Google likes to brass-ring to open when possible: we’re more open. People always list Google as a major cloud vendor, but I must have my head stuck in the cupboard because I rarely, if ever, hear about people deploying apps on AppEngine. Google Marketplace integrations, sure, but when’s the last time you heard about some mega-supercool thing on “Google’s cloud” that wasn’t just “Google’s own SaaSes”? Really, Google’s time is probably better spent on things like Android, Google Apps, and avoiding being disrupted in Google Search and the ad revenue it drives. It’s odd to think of Google as doing as well at cloud developer relations as others could.
- Rackspace, OpenStack – in theory, these guys exist below the PaaS layer, but the competition from PaaS stuff like Cloud Foundry is The Battle for Developers to Care. If the PaaS takes care of all the operational concerns, the IaaS layer becomes irrelevant enough that developers don’t care. It’s like the x86 server market: a tough layer to be in because the lack of differentiation based on technology is almost in there by design. All that matters in price. What you’d want to see from the OpenStack folks is rapid enablement on Cloud Foundry and any other PaaS layer. They really need to shoot to be, as The Register put it a while ago, “the Linux of the clouds” and that means lots of effort to make everything work on OpenStack. The same applies for Eucalyptus, Cloud.com, and other cloud vendors. PaaS folks like CloudBees are a slightly different case: PaaS startups main hope is to use their scrappy smallness to out-innovate big ol’ VMware.
- IBM – at their Cloud Forum last wek, these guys already laid out their reply, and it’s pretty solid if you’re an enterprise-minded person: enterprise applications are complex. IBM has been doing business work for a 100 years. We know our stuff, and yours. Good luck with those other guys. Their launch of actual cloud offerings – the two SmartClouds – last week is more important. IBM just needs to move past, way past, the dev/test stage of cloud they’re in an re-discover developer relations big-time. Once they hammer out the path between “Enterprise Software Development” and “Cloud Development” (using dev/ops as a sort of lubrication, if they can understand how it’s different than ITSM, which is apparently “dead” now) and update their portfolio appropriately, they could do well. Speed is the problem here. As Amazon and the dizzying, fragmented array of open source technologies used there-in has shown, marketing to cloud developers has a distinct first mover advantage, if not a “fast and quick to change” advantage. Their other tact (which is far more likely to suck up all the marketing-oxygen) is to speak to the “C-level” and talk about
applicationssolutions, costs, and “industries”: the technology is just some details for those poor saps who live their lives in flying metal-tubes to sort out.
- Salesforce – as with Google, there’s partnership’ing here to consider. Salesforce has declared that ruby is the language of the cloud, not just SaaS CRM, so they clearly are looking towards general cloud development with their Heroku acquisition. The advantage Salesforce has is zero allegiance to legacy (on-premise) IT and IT departments. In fact, Salesforce would probably be just fine – if not prefer – the IT department to go away. Most of the other elder companies working in this space don’t have that luxury. Most existing vendors feel the need to comfort instead of destroy-cum-transform legacy IT people, products, and models. Salesforce just has to demonstrate how they can make Heroku better: what can Salesforce+Heroku do that Heroku couldn’t do on it’s own?
- Red Hat – we haven’t heard from the Red Hat cloud story in awhile. With Makara they have PaaS technology and, as you’d expect, they’ll fall back on their “we’re truly open, what-are-you-gonna-trust-THEM?!” posturing. In theory, Red Hat should have the same check-boxes as VMware does here, minus running their own cloud (or maybe they will?). Their big event is coming up in a few weeks, so you’d expect to hear a lot there. See Derrick Harris’ commentary about small-fries in the PaaS market for more here.
What most BigCo’s wanting to get into the cloud development space fail to recognize is that cloud development has little to do with the massive, billions of dollars worth of existing code out there. It has almost everything to do with green-field development. Cloud has little to offer legacy applications*, at the moment. Most everything cloud has to offer is for new applications. As I’m fond of saying now: if it ain’t broke, don’t cloud it.
A company going after cloud development would start talking about how cloud allows you to deliver new functionality in your applications: what new features and software development processes does cloud allow that legacy models simply can’t do? I’m pretty bad at this myself, but I’ve taken a whack at it from time-to-time: “Useful things to do with the cloud, developer edition” and “Considering PaaS,” for example
(* Some of IBM’s announcement last week show them honing in on what cloud can offer for legacy support: solving all sorts of operator things like back-ups, replications, and slicing out cloud-friendly parts of things like SAP installs.)
On the meta-level, the almost complete focus on developers highlights how operations obsessed much of the recent (private) cloud talk has been. It’s almost as if the rhetoric of this Cloud Foundry announcement is implicitly saying: all that doesn’t really matter to developers, they don’t care about those “legacy” corporate IT concerns. I like how Stacey Higginbotham puts this point as well:
Charles Fitzgerald says that Cloud Foundry will sit on top of platform plays such as OpenStack, but in truth it is likely to hurt that effort by obviating the need for enterprises and other developers to worry about the underlying infrastructure platform. For those who want to build out an app, electing to deploy using Cloud Foundry means the developer can choose where to host its app without ever caring if it’s using OpenStack.
- The official press release, including a quote from our own Stephen O’Grady.
- Rod Johnson’s overview of Cloud Foundry.
- Write-up from VMware CTO Steve Herrod.
- the GitHub repository for their various Cloud Foundry projects.
- Stacey Higginbotham covers Cloud Foundry for GigaOm.
- Cade Metz covers Cloud Foundry for The Register.
- Quentin Hardy covers it: “Compared with the early ‘nineties, when I was doing this at Microsoft, the whole open source world has changed,” [Paul Maritz, VMware’s chief executive] says. “It is so much bigger. Second, now it is about driving things at a higher level – not just in a single (software) framework, but to lots of systems.”
Disclosure: VMware, Cloud.com, Eucalyptus, GitHub, Red Hat, Salesforce, CloudBees, Microsoft, Rackspace Cloud, and IBM are clients. See the RedMonk clients page for others.