Open Call to VMware – Commercialize Cloud Foundry Software!

After spending time at VMware and Cloud Expo last week, I believe that VMware’s lack of full backing for Cloud Foundry software is holding back the entire PaaS market in the enterprise.

Don’t get me wrong, there’s a lot of momentum in PaaS despite how very immature the market is. But this momentum is in pockets and largely outside of the core of software development in the enterprise. CloudFoundry.com might be moving along, but most enterprises don’t want to run the bulk of their applications in a public cloud. Only through the Cloud Foundry software layer will enterprises really be able to invest. And invest they will.

PaaS-based applications running in the enterprise data center are going to replace (or envelope) traditional app server-based approaches. It is just a matter of time due to productivity and support for cloud models. Cloud Foundry has the opportunity to be one of the winners but it won’t happen if VMware fails to put their weight behind it.

Some nice projects like Stackato from ActiveState are springing up around cfoundry, but the enterprises I deal with every day (big banks, insurance companies, manufacturers) will be far more likely to commit to PaaS if a vendor like VMware gets fully behind the software layer. Providing an open source software support model is fine and perhaps a good way to start. However, this is going to be a lot more interesting if VMW provides a fully commercialized offering with all of the R&D enhancements, etc.

This market is going to be huge – as big or bigger than the traditional web app server space. It’s just a matter of time. Cloud Foundry is dominating the current discussion about PaaS software but lacks the full support of VMware (commercial support, full productization). This is just holding people back from investing.  VMware reps ought to be including Cloud Foundry in every ELA, every sales discussion, etc. and they need to have some way to get paid a commission if that is to happen. That means they need something to sell.

VMware’s dev teams are still focused on making Cloud Foundry more robust and scalable. Stop! It’s far better to release something that’s “good enough” than to keep perfecting and scaling it.
“The perfect is the enemy of the good.” – Voltaire

It’s time for VMware to get with the program and recognize what you they and how it can be a huge profit engine going forward – but they need to go all in starting now!

(c) 2011 CloudBzz / TechBzz Media, LLC. All rights reserved. This post originally appeared at http://www.cloudbzz.com/. You can follow CloudBzz on Twitter @CloudBzz.

Advertisements

VMware’s OpenStack Hook-up

VMware has applied to join the OpenStack Foundation, potentially giving the burgeoning open source cloud stack movement a huge dose of credibility in the enterprise. There are risks to the community in VMware’s involvement, of course, but on the balance this could be a pivotal event. There is an alternative explanation, which I will hit at the end, but it’s a pretty exciting development no matter VMware’s true motivations.

VMware has been the leading actor for cloud computing in the enterprise. Most “private clouds” today run vSphere, and many service providers have used their VMware capabilities to woo corporate IT managers. While the mass-market providers like Amazon and Rackspace are built on open source hypervisors (typically Xen though KVM is becoming more important), the enterprise cloud is still an ESXi hypervisor stronghold.

Soapbox Rant: Despite the fact that most of the enterprise identifies VMware as their private cloud supplier, a very large majority of claimed “private clouds” are really nothing more than virtualized infrastructure. Yes, we are still fighting the “virtualization does not equal cloud” fight in the 2nd half of 2012. On the “Journey to the Cloud,” most VMware private clouds are still in the Phase I or early Phase II stages and nowhere near a fully elastic and end-to-automated environment driven by a flexible service catalog etc.

VMware’s vCloud program includes a lot of components, old and new, anchored by the vCloud Director (“vCD”) cloud management environment. vCD is a fairly rich cloud management solution, with APIs, and several interesting features and add-ons (such as vCloud Connector).

vCD today competes directly with OpenStack Compute (Nova) and related modules. However, it is not really all that widely used in the enterprises (I have yet to find a production vCD cloud but I know they exist). Sure, there are plenty of vCD installations out there, but I’m pretty sure that adoption has been nowhere near where VMware had hoped (queue the VMware fan boys).

From early days, OpenStack has supported the ESXi hypervisor (while giving Microsoft’s Hyper-V a cold shoulder). It’s a simple calculus – if OpenStack wants to operate in the enterprise, ESXi support is not optional.

With VMware’s overtures to the OpenStack community, if that is what this is, it is possible that the future of vCloud Director could be very tied to the future of OpenStack. OpenStack innovation seems to be rapidly outpacing vCD, which looks very much like a project suffering from bloated development processes and an apparent lack of innovation. At some point it may have become obvious to people well above the vCD team that OpenStack’s momentum and widespread support could no longer be ignored in a protectionist bubble.

If so, VMware should be commended for their courage and openness to support external technology that competes with one of their strategic product investments from the past few years. VMware would be joining the following partial list of OpenStack backers with real solutions in (or coming to) the market:

  • Rackspace
  • Red Hat
  • Canonical
  • Dell
  • Cloudscaling
  • Piston
  • Nebula
  • StackOps

Ramifications

Assuming the future is a converged vCD OpenStack distro (huge assumption), and that VMware is really serious about backing the OpenStack movement, the guys at Rackspace deserve a huge round of applause. Let’s explore some of the potential downstream impacts of this scenario:

  • The future of non-OpenStack cloud stacks is even more in doubt. Vendors currently enjoying some commercial success that are now under serious threat of “nichification” or irrelevancy, include: Citrix (CloudStack), Eucalyptus, BMC (Cloud Lifecycle Management), and… well, is there really anybody else? You’re either an OpenStack distro, and OpenStack extension, or an appliance embedding OpenStack if you want to succeed. At least until some amazingly new innovation comes along to kill it. OpenStack is to CloudStack as Linux is to SCO? Or perhaps FreeBSD?
    • Just weigh the non-OpenStack community against OpenStack’s “who’s who” list above. If you’re a non-OpenStack vendor and you are not scared yet, you may be already dead but just not know it.
    • As with Linux v. Unix, there will be a couple of dominant offerings and a lot of niche plays supporting specific workload patterns.  And there will be niche offerings that are not OpenStack.  In the long run, however, the bulk of the market will go to OpenStack.
  • The automation vendors (BMC, IBM, CA, HP) will need to embrace and extend OpenStack to stay in the game. Mind you, there is a LOT of potential value to what you can do with these tools. Patch management and compliance is just scratching the surface (though you can use Chef for that too, of course). Lots of governance, compliance, integration, and related opportunities for big markets here, and potentially all more lucrative and open to differentiated value. I’ve been telling my friends at BMC this for the past couple of years – perhaps I’ve got to get a bit more vociferous…
  • The OpenStack startups are in a pretty tough position right now. The OpenStack ecosystem has become it’s own pretty frothy and shark-filled “red ocean,” and the noise from the big guys – Rackspace, Red Hat, VMware, Dell, etc. – will be hard to overcome. I foresee a handful of winners, some successful pivots, and the inevitable failures (VCs invest in risk, right?). There are a lot of very smart people working at these startups, and at cloudTP we work with several of them, so I wouldn’t count any of them out yet. But in the long run, if the history of open source is any indicator, the market can’t support 10+ successful OpenStack software vendors.
  • Most importantly, it is my opinion that OpenStack WILL be the enterprise choice in the next 2-3 years. Vendors who could stop this – including VMware and Microsoft – are not getting it done (Microsoft is particularly missing the boat on the cloud stack layer). We’ll see the typical adoption curve with the most aggressive early adopters deploying OpenStack today and driving ecosystem innovation.
  • Finally, with the cloud stack battle all but a foregone conclusion, the battle for the PaaS layer is ripe for a blowout. And unlike the IaaS stack layer, the PaaS market will be a lot less commoditized in the near future.  There is so much opportunity for differentiation and innovation here that we will all have a lot to keep track of in the coming years.

Alternative Explanations

Perhaps I am wrong and the real motivation here for VMware is to tactically protect their interests in the OpenStack project – ESXi integration, new features tied to the vSphere roadmap, etc. The vCD team may also be looking to leverage the OpenStack innovation curve and liberal licensing model (Apache) to find and port new capabilities to the proprietary VMware stack – getting the benefit of community development efforts without having to invent them.

My gut tells me, however, that this move by VMware will lead to a long-term and strategic commitment that will accelerate the OpenStack in the Enterprise market.

Either way, VMware’s involvement in OpenStack is sure to change the dynamic and market for cloud automation solutions.

——-

(c) 2011 CloudBzz / TechBzz Media, LLC. All rights reserved. This post originally appeared at http://www.cloudbzz.com/. You can follow CloudBzz on Twitter @CloudBzz.

The Red Ocean of Cloud Infrastructure Stacks (updated)

Update: am revising this still… Reposting now – but send me your comments via @CloudBzz on Twitter if you have them.

It seems like every day there’s a new company touting their infrastructure stack.   I’m sure I’m missing some, but I show more than 30 solutions for building clouds below, and I am sure that more are on their way.  The market certainly can’t support so many participants!  Not for very long anyway.  This is the definition of a “red ocean” situation — lots of noise, and lots of blood in the water.

This is the list of the stacks that I am aware of:

I. Dedicated Commercial Cloud Stacks

II.  Open Source Cloud Stacks

III.  IT Automation Tools with Cloud Functionality

IV.  Private Cloud Appliances

I hope you’ll pardon my dubious take, but I can’t possibly understand how most of these will survive.  Sure, some will because they are big and others because they are great leaps forward in technology (though I see only a bit of that now).  There are three primary markets for stacks:  enterprise private clouds, provider public clouds, and public sector clouds.  In five years there will probably be at most 5 or 6 companies that matter in the cloud IaaS stack space, and the rest will have gone away or taken different routes to survive and (hopefully) thrive.

If you’re one of the new stack providers – think long and hard about this situation before you make your splash.  Sometimes the best strategy is to pick another fight.  If you swim in this red ocean, you might end up as shark bait.

Forward PaaS: VMware’s Cloud Foundry First Down

I know it’s baseball season, but there’s no passing in baseball and this post will just work better as a football analogy.

VMware’s announcement this week of Cloud Foundry (twitter @cloudfoundry) has gotten a lot of attention from the cloud community, and for good reason. Just as hardware is a low-margin commodity business, hardware as a service (e.g. IaaS) is the same. Ultimately, price will be the core basis for competition in the IaaS space and a lot of high-cost “enterprise” clouds will struggle to compete for business without some real differentiation.

For the past few years, PaaS offerings from Salesforce (force.com)a, Microsoft (Azure), Google (AppEngine) and newcomers like Heroku (now owned by Salesforce), EngineYard and others have really gained a lot of traction. Developers really don’t like sysadmin work as a rule, and provisioning instances of EC2 is sysadmin work. Writing code that turns into applications, features, etc. that end-users use is far more interesting to the developers I’ve worked with (and who’ve worked for me). PaaS, then, is for developers.

But PaaS before this week meant lock-in. Developers, and the people who pay them, don’t like to be locked into specific vendor solutions. If you write for Azure, the fear (warranted or not) is that you can only run on Azure. Given that Microsoft has totally fumbled the opportunity to make Azure a partner-centric platform play, that means you need to run your Azure apps on Microsoft’s cloud. Force.com is even worse – with it’s own language, data model, etc. there’s not even the chance that you can run your code elsewhere without major rework. Force.com got traction primarily for people building extensions to Salesforce’s SFA and CRM offerings – though some people did do more with it. VMforce (Spring on Force.com) was supposed to change the openness issue by providing a framework for any Java apps to run. Google AppEngine is also proprietary in many respects, and when it launched with just a single language (Python!), a lot of developers shrugged. Even the proprietary PaaS components of AWS have been a problem. I could not get my developers to use SimpleDB back in 2008 because, as the rightly pointed out, we’d be stuck if we wanted to move off of EC2 at some point.

Lots of flags on the field. Holding! Illegal receiver! Neutral zone infraction!

There have been some attempts to publish PaaS frameworks that can run on other clouds, but they have failed to gain much traction. (carried off the field on a stretcher? yeah, that works).

Along comes CloudFoundry by VMware and — INTERCEPTION!

In fact, it’s like a whole new game just started. On their first possession VMware completed a perfectly executed forward PaaS. It’s 1st & 10 on their own 20 yard line. There’s a lot of field out there, and while the defense is in total disarray for the moment, it’s going to take a lot of perfect execution to score a CloudFoundry touchdown.

The Cloud Foundry Playbook

VMware really nailed it on the launch, with very compelling playbook of offensive and defensive plays that should have most PaaS competitors reeling. Here’s their graphic that shows the core concepts:

Shotgun Formation: Across the top you can see three programming frameworks included at launch.  Spring (Java – SpringSource owned by VMware), Rails, and node.js.  You can expect more frameworks to be supported – including Python and PHP.  Ideally they would add .NET too, though not sure if the licensing can work there (a huge chunk of corporate apps are Windows/.NET based).  They also added support for MongoDB, MySQL and Redis for data management.

The Open Blitz: VMware did an incredibly good thing by launching the core Cloud Foundry project as an Apache-licensed open source project.  While I have some concerns around their lack of a community governance model, the fact that they went with Apache vs. a dual-license GPL/Commercial model like MySQL is incredibly aggressive.  I could, if I wanted to, grab Cloud Foundry code, create my own version (e.g. Bzz Foundry) and sell it for license fees with no need to pay VMware anything.  The reality is that I could, but I would not do that and VMware knows that their own development teams will be the key to long term sustainability of this solution.  That said, a cloud service provider that wants to add Cloud Foundry on top of their OpenStack-based cloud could do so without any licensing fees.  I can be part of the “Cloud Foundry Federation” without having to be a vCloud VSPP provider.

Special Teams: Cloud Foundry is deployable in an enterprise private cloud, a public cloud, or what they call a “micro cloud” model (to run on a laptop for development).  I suspect they will have a very strong licensing and maintenance business for the enterprise versions of Cloud Foundry.  They’ll also get support and maintenance fees from many cloud service providers who see the value in paying for it.  Of course, CloudFoundry.com is a service itself, which may be a problem for other cloud service providers to join the federated model.  This is something they will need to think about – EMC Atmos Online eventually had to be closed to new customers based on push back from other service providers who were looking to also be in the cloud storage business.  It’s hard to get service providers to use your stuff if you’re competing against them.

Just over a year ago I argued that VMware should “Run a Cloud…” as one of their options.  In fact, I predicted a Spring is the key to them being a cloud provider:

Their alternative at that point is to offer their own cloud service to capture the value from their enterprise relationships and dominant position.  They can copy the vertically integrated strategy of Microsoft to make push-button deployment to their cloud service from both Spring and vCenter.

Gartner’s Chris Wolf is following a similar line of thinking, especially when you add last week’s EMC -> VMware Mozy transfer.

So where does that leave Team CloudFoundry?

For now, they are on the field, in the game, and playing like winners.  Let’s see if they can march down the field before the defense gets into a position of strength.

——-

(c) 2011 CloudBzz / TechBzz Media, LLC.  All rights reserved.  This post originally appeared at http://www.cloudbzz.com/seamicro-atom-and-the-ants/. You can follow CloudBzz on Twitter @CloudBzz.

 

 

 

VMware Should Run a Cloud or Stop Charging for the Hypervisor (or both)

I had a number of conversations this past week at CloudConnect in Santa Clara regarding the relative offerings of Microsoft and VMware in the cloud market.  Microsoft is going the vertically integrated route by offering their own Windows Azure cloud with a variety of interesting and innovated features.  VMware, in contrast, is focused on building out their vCloud network of service providers that would use VMware virtualization in their clouds. VMware wants to get by with a little help from their friends.

The problem is that few service providers are really VMware’s friend in the long run.  Sure, some enterprise-oriented providers will provide VMware capabilities to their customers, but it is highly likely that they will quickly offer support for other hypervisors (Xen, Hyper-V, KVM).  The primary reason for this is cost.  VMware charges too much for the hypervisor, making it hard to be price-competitive vs. non-VMware clouds.  You might expect to see service providers move to a tiered pricing model where the incremental cost for VMware might be passed onto the end-customers, which will incentivize migration to the cheaper solutions.  If they want to continue this channel approach but stop enterprises from migrating their apps to Xen, perhaps VMware needs to give away the hypervisor – or at least drop the price to a level that it is easy to absorb and still maintain profitability ($1/month per VM – billed by the hour at $0.0014 per hour plus some modest annual support fee would be ideal).

Think about it… If every enterprise-oriented cloud provider lost their incentive to go to Xen, VMware would win.  Being the default hypervisor for all of these clouds would provide even more incentive for enterprise customers to continue to adopt VMware for internal deployments  (which is where VMware makes all of their money).  Further, if they offered something truly differentiated (no, not vMotion or DRS), then they could charge a premium.

If VMware does not make this change, I believe that they can kiss their position in the cloud goodbye in the next 2 years or so.  Their alternative at that point is to offer their own cloud service to capture the value from their enterprise relationships and dominant position.  They can copy the vertically integrated strategy of Microsoft to make push-button deployment to their cloud service from both Spring and vCenter.  This has some nice advantages to them culturally as well.  VMware has a reasonably large enterprise sales force (especially when combined with EMC’s…), and these high-paid guns are unlikely to get any compensation when a customer migrates to Terremark.  There’s a separate provider sales force that does get paid.  If VMware created their own managed service and compensated their direct reps to sell it, adoption would soar.  With their position in the developer community via the Spring acquisition, they’ll get some easy low-hanging fruit as well. 

Now, put these concepts together – free hypervisor and managed offering.  Would they lose their services providers?  I doubt it.  Enterprises want choices while continuing to use what they already know.  Terremark, Savvis, and others will have good marketing success with VMware as long as it doesn’t break their financial model.  Further, VMware’s “rising tide” would actually float all of the other VMware-based service providers and help them to better position against and compete with the Xen-based mass-market clouds.  A “VMware Inside” campaign that actually promoted other service providers would also help. 

Being in the managed services space is a very different business for VMware.  The margins are lower, but they could build a very large and profitable cloud offering with their position in the enterprise.  Similarly, a unified communications service based on Zimbra would give them even more value to sell (and to offer through vCloud partners).  As long as they remove the financial incentive for providers to switch to Xen at the same time, they could have a very strong play in this space.

If VMware does not at least make the pricing change for service providers, their future in the cloud is very much at risk. 

p.s. While they’re at it, VMware needs to allow us to integrate directly with ESX and get rid of vCenter in a service provider environment.