CloudBzz » vmware

The Red Ocean of Cloud Infrastructure Stacks (updated)

john — Fri, 26 Aug 2011 19:51:11 +0000

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

OpenStack
- Ubuntu Enterprise Cloud (Canonical)
- Piston (coming)
- Nebula
- others…
OpenNebula
Nimbus Project
Wakame-VDC (Japan)

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

john — Fri, 15 Apr 2011 17:12:42 +0000

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.

——-

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

john — Fri, 19 Mar 2010 14:40:25 +0000

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.