VMware vs. Amazon … ROUND ONE … FIGHT!

Posted on by Randy Bias


More and more it’s becoming apparent that VMware and Amazon are headed for a serious collision.  Amazon is eager to capture more of the enterprise business market, VMware’s bread and butter.  Meanwhile, VMware is actively supporting a new crop of Amazon competitors with its recent vCloud Express release.  More importantly, what perhaps neither have realized or, at least as far I can tell Amazon hasn’t realized, is that the battle isn’t ultimately about so-called ‘public’ or ‘private’ clouds[1], but about standards, de facto or otherwise.

Infrastructure History & Standards
Like railways, the telephone system, or any other kind of infrastructure that supports business today, IT is quickly commoditizing and turning from a competitive advantage into a cost of doing business.  Cloud computing is an accelerator in this process.  As I’ve asserted before, the ‘cloud’ is less about technology or where the resources reside and more about a fundamental change in the way that we use and understand IT infrastructure.

I like to think of ‘cloud’ as a group ‘A-HA!’ moment, much like the one that happened with other foundational infrastructure changes.  Early in the advent of railroads, trains, track gauges, switching equipment was all custom and had little or no interoperability.  Eventually it became apparent that standards would allow greater aggregate value to all involved.  Nicholas Carr nails it in his book Does IT Matter?:

As was true with railroads and electricity and highways, it is only by becoming a shared and standardized infrastructure that IT will be able to deliver its greatest economic and social benefits, raising productivity and living standards and serving as a platform for a range of new and desirable consumer goods and services.  History reveals that IT needs to become ordinary—needs to lose its strategic importance as a differentiator of companies—if it is to fulfill its potential.

The primary point being here that market demands will essentially force standardization, one way or another.  Of course, we would all like to see open standards, but even de facto standards will work.  This is what’s at stake in this battle.

The Contenders & Their Market Positions
It’s interesting how two such different businesses can suddenly see themselves at odds, but with a multi-billion dollar future market in cloud computing at stake, it’s not surprising that we may see all kinds of players emerge.  Looking at the relative market cap (AMZN @ 36.5B and VMW @ 15.5B) and stock performance of the two tells one story:

VMW vs. AMZN

VMW vs. AMZN

Digging into this a bit more we can see that the story is a lot bigger than a simple tale of revenues, especially as it relates to enterprise businesses.

Amazon
Amazon (AMZN), as a whole, is roughly 3x in employees and 10x the size of VMware (VMW) in revenue.  The vast majority of this revenue comes from Amazon’s online retail business, which is consumer focused, while VMware is almost exclusively focused on large enterprise customers[2].  More telling are the recent 10-Q reports of both companies.

Amazon, unfortunately, does not provide the revenue numbers for Amazon Web Services (AWS) as part of their reports.  It is bundled into an ‘Other’ line, which includes a number of Amazon revenue streams.  Their most recent 10-Q reports the North American revenue for ‘Other’ as 217M for the 6 months ending June 30th, 2009.  I’m going to go out on a limb and suggest that AWS revenues are half of this number, but it’s certainly a wild guess.  Assuming that’s the case, the AWS business is a 200M annual business and undoubtedly growing rapidly.  It is very difficult to know what percentage of that revenue is large enterprise customers, but I feel safe concluding it can’t be more than 25-35% total.  My conclusion is based on the fact that enterprises are slow to adopt and that most of their current use cases are almost certainly non-production ones like batch processing.

If this is true, Amazon’s AWS business for enterprise is unlikely to be more than 70M annually.  This is a very impressive number given that Amazon is not traditionally an enterprise-focused business.  We should give them credit where credit is due.  By all accounts Amazon has generally had a large number of challenges shifting from it’s consumer, one-size-fits-all, business model, which is certainly a put-off for large enterprise customers.

VMware
In comparison, VMW’s recent 10-Q report shows a healthy 926M in revenues for the 6 months ending June 30th, 2009.  VMware’s license revenues dropped pretty significantly from the year before, but annual support licenses made up for it.  Most of this is certainly attributable to the current economic climate and their enterprise customer base.  Given that VMware’s customer base is largely enterprise customers, they are a roughly 2B dollar enterprise business.  About half of which is new license sales.

VMware has a long track record of providing tremendous value to enterprise customers, but by most reports, the penetration of virtualization inside the enterprise is still less than 20%.  This is due to a variety of factors, but anecdotally, it appears that virtualization and server consolidation suffers from many of the traditional issues that plague IT initiatives within the enterprise.  McKinsey’s cloud report predicted that enterprises, with tremendous effort, could reach virtualization rates of 38%.

Unless perhaps cloud computing, as an operational model change, can completely change the way that IT delivers it’s services.

AMZN vs. VMW in the Enterprise
So, while at a glance, Amazon is a bigger business, inside the enterprise VMware is actually a 10x bigger business with relatively low penetration of it’s technology and a lot of room to grow.

Now the 100B dollar question: Will enterprise business move outside to public clouds like Amazon OR use VMware and internal private clouds to change the way that IT does business?

It’s anyone’s guess how this will play out in the long term, but in the short term, we’re likely to see both routes taken.  While predicting the long term is outside the scope of this posting, I think the short to medium term fight (“ROUND ONE!”) that will directly impact how this plays out is cloud computing standards.

The Standards Collision
It’s clear from history that standards combined with infrastructure technology create a transformative opportunity.  While cloud computing has enjoyed some serious traction, we’re still early on and standards have not evolved yet.  Amazon and VMware, as standards competitors, are a bit like having two different railroad track gauges.  You won’t be able to run the same kind of trains on both sets of track gauge or connect railways based on either together.  Standards matter and making sure we have the same gauge rails everywhere is incredibly important to the rapid adoption of cloud computing[3].

At VMworld, VMware announced vCloud Express including the vCloud API.  The vCloud API was released under a very open license.  One that even allows building a cloud with alternative non-VMware hypervisors that provides this API.  As I mentioned at the time, it seems to me that this is going to drive de facto cloud computing standards.  In fact, VMware’s announcement included five new clouds supporting the standard and one very important cloud management vendor (RightScale).  In one fell swoop, VMware provided a standard across five clouds and one vendor.  This is certainly just the beginning.  Without a doubt many more will adopt the vCloud API.  Perhaps most telling of all is that VMware’s own cloud infrastructure product isn’t even shipping yet.  Once it ships, it will most certainly work with existing VMware products like vSphere and every new enterprise vCloud-based installation will have the same vCloud API.

But what about Amazon’s AWS APIs? Could those be a standard too?  They could be, but Amazon has been deliberately vague about the license for it’s cloud APIs.  Although certain vendors support AWS APIs, like EUCALYPTUS and OpenNebula, it has not been clear what their legal status is.  This is also why AWS competitors like GoGrid and RackSpace chose to develop their own APIs, when clearly supporting AWS-compatible APIs would have been more desirable.  Will Amazon license their APIs under an open license in response to VMware?  I think the answer is obvious.  Amazon Web Services must open license their cloud APIs or it will be one of the biggest mistakes they have made to date[4].  Clearly, they will make the standard Amazon play and only do the absolute minimum necessary, which likely means an open license on EC2 (Elastic Computing Cloud).

When AWS opens the EC2 API it will open the floodgates for folks like EUCALYPTUS, OpenNebula, DynamicOps, VMops, and other cloud vendors, effectively allowing them to compete against vCloud in the enterprise.

In effect, we’ll have two major competing cloud standards: the vCloud API and the EC2 API.

What Happens When Worlds Collide?
So, we have VMware moving into Amazon’s ‘public’ cloud territory by enabling AWS competitors, while Amazon is extremely likely to reciprocate by enabling VMware competitors for internal ‘private’ clouds.  Given that both external public and internal private clouds will see significant growth over the medium term and that there is tremendous value from joining external and internal clouds via standards, the writing is on the wall.

A standard has to win or, at least, dominate.  While Amazon is the 800lb gorilla in the public cloud computing space, VMware has a massive lead in the enterprise.  It really depends on where you think the enterprise is going to go.  Will they put more money into transforming the way IT works via internal clouds or begin to move to external clouds right away?

My bet is that enterprises are going to go for internal clouds before external clouds, at least for the majority of their sensitive and mission critical workloads.  If that’s the case then vCloud looks like a good bet and Amazon looks like they could eventually be playing second fiddle as the #1 player in the #2 market.


[1] ‘Private’ and ‘public’ can be confusing terms.  Usually people mean ‘internal’ clouds when they say ‘private’.  But a ‘private’ cloud could be both ‘internal’ or ‘external’.  I’ll mostly try to talk about ‘internal private’ or ‘external public’ in this article.
[2] As many of you may know, the prevailing wisdom is that the majority of ‘dollars’ in IT are spent by large enterprises, not smaller businesses.
[3] Of course, it will probably turn out, like railroad track gauges, that different standards or technology are good for different use cases.
[4] There is another possibility, although seemingly improbable, that Amazon could adopt the vCloud API.

This entry was posted in Cloud Computing and tagged , , , , , , , , , . Bookmark the permalink.

Previous post:
Next post:

  • http://twitter.com/jclouds jclouds

    WRT:

    “When AWS opens the EC2 API it will open the floodgates for folks like EUCALYPTUS, OpenNebula, DynamicOps, VMops, and other cloud vendors, effectively allowing them to compete against vCloud in the enterprise”

    I'm a fan of EC2 functionality, but not their API. I wouldn't wish propagation of the awkward EC2 query api on the greater community, or even people I don't like ;)

    It shouldn't be prohibitively difficult for the above players to also expose their functionality as vCloud, or any other open api for that matter.

    • http://cloudscaling.com randybias

      I agree. I think many folks will move towards the vCloud API, but will Amazon? Historically they don't have a history of 'playing nice'. It's been more typical for them to say “our way or the highway.”

      Can Amazon embrace vCloud? It would be the crafty move, but I suspect, instead, that they will open the APIs on EC2 and try to go head-to-head.

      • http://samj.net/ samj

        In claiming that Amazon don't have a history of 'playing nice' you're implying that VMware does. BS, they're just as ruthless as the next vendor and by “forcing” vCloud down everyone's throats rather than just using it themselves and letting us come knocking I'd say they're even moreso than Amazon.

        It'll be a cold day in hell when Amazon adopts vCloud and to be honest I don't think the API is up to the task (at least in its current form), which is no surprise given its lineage. OTOH I'd rather the Amazon EC2 API stay shacked up because it's very implementation-specific and would give them an unfair advantage similar to the one VMware is currently seeking.

        Sam

        • http://cloudscaling.com randybias

          No Sam. By claiming Amazon doesn't have a history of 'playing nice', I'm only claiming that. I'm not claiming VMware is any better. If I were, I would just say it directly.

  • Pingback: Tweets that mention VMware vs. Amazon … ROUND ONE … FIGHT! | Cloudscaling -- Topsy.com

    • http://twitter.com/majumdar Robin Majumdar

      Hmm competing vendors insisting on doing “standards” their own way? Sounds familiar, no ?

      I get the feeling that we'll be moving to an intercloud ecosystem connected by a mish-mash of (not always well-behaved) semi-proprietary APIs and EDI protocols.

      This is one reason why many enterprise IT architects may be more than hesitant to start pushing their corporate data up there.

      I know that I would be very nervous about the enterprise data, I'm trusted with, being in the clouds and getting caught in a nasty thunderstorm.

      For large organizations with expansive and geographically distributed DCs, I can see a VPC (virtual private cloud) or intracloud environment where the bits remain within their own systems.

      • http://cloudscaling.com randybias

        We're unlikely to see this play out in the way you are suggesting. The problem with the WS-I, WS-*, EDI, and related standards was that the tended to be design-by-committee standards. There isn't much danger here of that. For better, or worse (see @samj), there is one canonical source for both the AWS APIs and the vCloud APIs.

        Enterprise IT architects who are nervous about moving data outside the firewall are instead simply looking at building internal cloud computing systems first, most of which will use a vCloud-compatible API either now or in the future in order to achieve maximum interoperability.

        • http://somic.org Dmitriy

          Great post Randy. Even though API as you point out is very important, I personally don't think it's *that* important – please see my post on the subject:
          http://somic.org/2009/09/08/shiny-cloud-apis-ne

          Kudos on railroad analogy – one of my favorite as well:
          http://somic.org/2009/02/04/api-forever-look-at:)

          Functionality is more important, imho. As a hypothetical example, say there exists an EC2-like cloud where security groups span all regions (in EC2, as we all know, security groups are confined to a single region). Switching between EC2 and this new cloud and back for operations (start, stop, status) would be relatively easy, with help of abstraction libraries; but once you set up your architecture to use global security groups and rely on this fact when writing your app, it won't be as easy to switch back and forth.

          In other words, cloud lock-in via functionality is harder to overcome than cloud lock-in via API.

          @jclouds – you may have a point, but consider this: I have used EC2 extensively over past year, but have no idea about low-level impl of their API. All I care about is ec2dim, ec2din, ec2dgrp, ec2auth command line tools and ec2-metadata script. I suspect I am not alone – only library implementors care about API to such a low level, others (like me) simply use the libs.

          • http://cloudscaling.com randybias

            Insightful as always, Dmitriy. I agree that we're just at step one. We need not only standard APIs, but ability to make 'SLA contracts' with clouds for security, performance and similar. This was always one of @jamesurquhart's favorite topics.

            I think the vCloud API is a first step towards this, though. There is nothing to stop folks from overloading or extending the vCloud API to add these capabilities.

            This also showcases a good reason *for* lock-in. Meaning that, of course, clouds with the same hypervisor and same cloud architecture will facilitate application architectures that can be easily migrated between them.

            So, you're right, cloud lock-in via functionality is harder to overcome, but providers will move towards a lowest common denominator. One that, if you design towards, will guarantee your application's portability. Combined with SLA contracts, lock-in will be much harder.

            To be honest, while in the short term cloud lock-in is important, over the long haul I think it's a red herring. It's like thinking there will be lock-in for railroads. There can't be because they *must* interoperate in order to have value.

            I'm pretty sure the market is going to make lock-in impossible in this case.

  • jomaitland

    Interesting post, Chris. Thank you. I don't think it'll be an either or situation though. If I had to make a bet, 10 years from now vCloud will be the enterprise cloud and Amazon AWS will be the consumer cloud and the two will be separate markets with separate standards. But however it plays out, it feels like a great time to be in technology again as this shift takes place.

    • http://cloudscaling.com randybias

      Johanna, thanks for the comment. It's Randy, though, not Chris. ;)

      I agree with your primary reasoning, but want to clarify a couple of things. First, I don't think there is a 'consumer' cloud. I think it's more likely to be a 'commodity' cloud. Second, clouds are going to be segmented by use case, capabilities, and pricing, which means enterprises are likely to consume all types of clouds, even Amazon. The majority of their workloads, though, will go to 'enterprise-class' clouds that interoperate well with their internal cloud computing systems.

      I also predicted this fork in the two general types of clouds in posting. Also recommend this and this as well for more background.

      Best,

      –Randy

      • jomaitland

        Hey Randy,

        Sorry, I didn't realize the blog was by you. Good points below.

        Thanks,
        Jo

        Jo Maitland
        Executive Editor
        TechTarget

        SearchCloudComputing.com
        SearchVMware.com
        SearchServerVirtualization.com
        Email: jmaitland@techtarget.com
        Tel: 781-429-4137

        • http://cloudscaling.com randybias

          No worries, Jo. Thanks!

      • http://twitter.com/cloudbzz JohnTreadwayCloudBzz

        Randy – am agreeing on your general concept. I think it will be even more fragmented, with a few large competing commodity clouds (such as AWS, Google, Azure each with their own unique flavors, but each with a number of extensions up the value chain) and multiple types of enterprise clouds based on workloads and other parameters (HPC, OLTP, etc.).

  • http://techinstigator.com/ Chris Fleck

    Interesting analysis. I agree there is much more to come in this battle, I think the vCloud lock-in is not something Enterprises want from a Cloud provider.
    I did a brief comparison of Amazon vs Terremark Cloud Economics here:
    http://community.citrix.com/x/lgDuB

    • http://cloudscaling.com/blog randybias

      Thanks for the comment, Chris. Can you be a little more specific about what you mean by ‘vCloud lock-in’? Given that the principle interface to any cloud is it’s API, that the vCloud API can be put on any cloud that doesn’t infringe VMware’s trademarks (even Xen-based ones), I don’t see the lock-in.

      As far as I am aware the best case for lock-in would be to suggest that the hypervisor will force lock-in, not vCloud itself. I think there is a good argument to be made for that; however, as the hypervisor is only going to continue to commoditize, I think eventually it will be free or nearly so and it just won’t matter.

      Or are you referring to something else?

      • http://samj.net/ samj

        Sure there will be lock-in for both vCloud and OVF. Users aren’t stupid and will quickly learn that they need to use VMware to avoid compatibility reasons just as they continue to reach for Microsoft Word today even though document standards are “open”.

        Does OVF work for portability today? Not so much. Will vCloud (or whatever they end up calling it) work for interoperability tomorrow? I very much doubt it.

        Sam (who’d rather no particular vendor enjoy an unfair advantage by having their native standard “forced” on others)

        • http://cloudscaling.com/blog randybias

          I don’t think this is true, although I agree with your general thrust. Standards, interoperability, and compatibility are regularly achieved through both openness and ‘de facto’ standards.

          Using Microsoft Word, as an example, simply reinforces the primary point of my article, which is that Amazon missed the bigger opportunity by not being more open sooner and that because they did VMware is able to make a Microsoft-like play.

          Comparing to the Microsoft Office suite directly, however, doesn’t make sense as those were not open standards to begin with, while the vCloud API is starting out as open. Also, none of the vCloud-related products are shipping from VMware so plenty of folks have an opportunity to get in there and build vCloud API-compatible products. In other words, Microsoft dominated from two main factors: 1) a closed document standard and 2) market dominance. In this case, VMware does not have #1 and #2 it only has inside the enterprise market.

  • http://twitter.com/jclouds jclouds

    WRT:

    “When AWS opens the EC2 API it will open the floodgates for folks like EUCALYPTUS, OpenNebula, DynamicOps, VMops, and other cloud vendors, effectively allowing them to compete against vCloud in the enterprise”

    I’m a fan of EC2 functionality, but not their API. I wouldn’t wish propagation of the awkward EC2 query api on the greater community, or even people I don’t like ;)

    It shouldn’t be prohibitively difficult for the above players to also expose their functionality as vCloud, or any other open api for that matter.

    • http://cloudscaling.com/blog randybias

      I agree. I think many folks will move towards the vCloud API, but will Amazon? Historically they don’t have a history of ‘playing nice’. It’s been more typical for them to say “our way or the highway.”

      Can Amazon embrace vCloud? It would be the crafty move, but I suspect, instead, that they will open the APIs on EC2 and try to go head-to-head.

      • http://samj.net/ samj

        In claiming that Amazon don’t have a history of ‘playing nice’ you’re implying that VMware does. BS, they’re just as ruthless as the next vendor and by “forcing” vCloud down everyone’s throats rather than just using it themselves and letting us come knocking I’d say they’re even moreso than Amazon.

        It’ll be a cold day in hell when Amazon adopts vCloud and to be honest I don’t think the API is up to the task (at least in its current form), which is no surprise given its lineage. OTOH I’d rather the Amazon EC2 API stay shacked up because it’s very implementation-specific and would give them an unfair advantage similar to the one VMware is currently seeking.

        Sam

        • http://cloudscaling.com/blog randybias

          No Sam. By claiming Amazon doesn’t have a history of ‘playing nice’, I’m only claiming that. I’m not claiming VMware is any better. If I were, I would just say it directly.

  • gschofield

    Is it fair to compare VMware and Amazon on market cap? It would seem like the EMC ties VMware has should carry some weight.

    • http://samj.net/ samj

      No, it’s not at all fair to compare legacy vendors to cloud providers based on market cap. It’s like assessing the market share in terms of vehicles on the road by comparing the revenue of Toyota and Tesla – the former can get 10x as many cars on the road for the same price.

      Comparisons of Microsoft vs Google Apps revenues are similarly misleading as for each Microsoft user displaced by Google there is a much smaller spend (which is exactly why people are flocking to these services).

      Of course this means that the providers have to do a lot more with a lot less (ditto the ecosystem around them), but this also means the agile upstarts are relatively safe from the dinosaur incumbents.

      Sam

      • http://twitter.com/wattersjames James Watters

        Sam I think the variability of revenue is an important point here. Say Amazon has $200M in EC2 revenue (I know that’s more aggressive than Randy’s estimate but I’ve heard numbers that high often)…what would that have equated to in internal IT spending for VMwares customers? I think the number would be a multiple of 2-3x at least?

    • http://cloudscaling.com/blog randybias

      That’s of course the point of the article. At first glance based on ticker information it’s not an interesting story, but … dig in, and it’s quite interesting.

  • http://robinmajumdar.com/ Robin Majumdar

    Hmm competing vendors insisting on doing “standards” their own way? Sounds familiar, no ?

    I get the feeling that we’ll be moving to an intercloud ecosystem connected by a mish-mash of (not always well-behaved) semi-proprietary APIs and EDI protocols.

    This is one reason why many enterprise IT architects may be more than hesitant to start pushing their corporate data up there.

    I know that I would be very nervous about the enterprise data, I’m trusted with, being in the clouds and getting caught in a nasty thunderstorm.

    For large organizations with expansive and geographically distributed DCs, I can see a VPC (virtual private cloud) or intracloud environment where the bits remain within their own systems.

    • http://cloudscaling.com/blog randybias

      We’re unlikely to see this play out in the way you are suggesting. The problem with the WS-I, WS-*, EDI, and related standards was that the tended to be design-by-committee standards. There isn’t much danger here of that. For better, or worse (see @samj), there is one canonical source for both the AWS APIs and the vCloud APIs.

      Enterprise IT architects who are nervous about moving data outside the firewall are instead simply looking at building internal cloud computing systems first, most of which will use a vCloud-compatible API either now or in the future in order to achieve maximum interoperability.

  • kch2001

    VMware is target #1 on MSFT hit list. They are going to do everything they can to send VMW the way Netscape and the Dodo bird.

    • http://cloudscaling.com randybias

      I'm sure that MSFT is concerned about VMW, but the landscape couldn't be more different than when they torpedoed Netscape. The most interesting threat MSFT has to VMW is SystemCenter, not Hyper-V. I covered this in a little detail here

  • jomaitland

    Interesting post, Chris. Thank you. I don’t think it’ll be an either or situation though. If I had to make a bet, 10 years from now vCloud will be the enterprise cloud and Amazon AWS will be the consumer cloud and the two will be separate markets with separate standards. But however it plays out, it feels like a great time to be in technology again as this shift takes place.

    • http://cloudscaling.com/blog randybias

      Johanna, thanks for the comment. It’s Randy, though, not Chris. ;)

      I agree with your primary reasoning, but want to clarify a couple of things. First, I don’t think there is a ‘consumer’ cloud. I think it’s more likely to be a ‘commodity’ cloud. Second, clouds are going to be segmented by use case, capabilities, and pricing, which means enterprises are likely to consume all types of clouds, even Amazon. The majority of their workloads, though, will go to ‘enterprise-class’ clouds that interoperate well with their internal cloud computing systems.

      I also predicted this fork in the two general types of clouds in posting. Also recommend this and this as well for more background.

      Best,

      –Randy

      • jomaitland

        Hey Randy,

        Sorry, I didn’t realize the blog was by you. Good points below.

        Thanks,
        Jo

        Jo Maitland
        Executive Editor
        TechTarget

        SearchCloudComputing.com
        SearchVMware.com
        SearchServerVirtualization.com
        Email: jmaitland@techtarget.com
        Tel: 781-429-4137

        • http://cloudscaling.com/blog randybias

          No worries, Jo. Thanks!

      • http://twitter.com/cloudbzz JohnTreadwayCloudBzz

        Randy – am agreeing on your general concept. I think it will be even more fragmented, with a few large competing commodity clouds (such as AWS, Google, Azure each with their own unique flavors, but each with a number of extensions up the value chain) and multiple types of enterprise clouds based on workloads and other parameters (HPC, OLTP, etc.).

  • http://www.somic.org Dmitriy

    Great post Randy. Even though API as you point out is very important, I personally don’t think it’s *that* important – please see my post on the subject:
    http://somic.org/2009/09/08/shiny-cloud-apis-necessary-but-not-sufficient/

    Kudos on railroad analogy – one of my favorite as well:
    http://somic.org/2009/02/04/api-forever-look-at-cloud-computing-as-bubble/ :)

    Functionality is more important, imho. As a hypothetical example, say there exists an EC2-like cloud where security groups span all regions (in EC2, as we all know, security groups are confined to a single region). Switching between EC2 and this new cloud and back for operations (start, stop, status) would be relatively easy, with help of abstraction libraries; but once you set up your architecture to use global security groups and rely on this fact when writing your app, it won’t be as easy to switch back and forth.

    In other words, cloud lock-in via functionality is harder to overcome than cloud lock-in via API.

    @jclouds – you may have a point, but consider this: I have used EC2 extensively over past year, but have no idea about low-level impl of their API. All I care about is ec2dim, ec2din, ec2dgrp, ec2auth command line tools and ec2-metadata script. I suspect I am not alone – only library implementors care about API to such a low level, others (like me) simply use the libs.

    • http://cloudscaling.com/blog randybias

      Insightful as always, Dmitriy. I agree that we’re just at step one. We need not only standard APIs, but ability to make ‘SLA contracts’ with clouds for security, performance and similar. This was always one of @jamesurquhart’s favorite topics.

      I think the vCloud API is a first step towards this, though. There is nothing to stop folks from overloading or extending the vCloud API to add these capabilities.

      This also showcases a good reason *for* lock-in. Meaning that, of course, clouds with the same hypervisor and same cloud architecture will facilitate application architectures that can be easily migrated between them.

      So, you’re right, cloud lock-in via functionality is harder to overcome, but providers will move towards a lowest common denominator. One that, if you design towards, will guarantee your application’s portability. Combined with SLA contracts, lock-in will be much harder.

      To be honest, while in the short term cloud lock-in is important, over the long haul I think it’s a red herring. It’s like thinking there will be lock-in for railroads. There can’t be because they *must* interoperate in order to have value.

      I’m pretty sure the market is going to make lock-in impossible in this case.

  • kch2001

    VMware is target #1 on MSFT hit list. They are going to do everything they can to send VMW the way Netscape and the Dodo bird.

    • http://cloudscaling.com/blog randybias

      I’m sure that MSFT is concerned about VMW, but the landscape couldn’t be more different than when they torpedoed Netscape. The most interesting threat MSFT has to VMW is SystemCenter, not Hyper-V. I covered this in a little detail here

  • Pingback: RTFM Education » Blog Archive » VMware Vs Amazon?

  • http://twitter.com/cloudbzz JohnTreadwayCloudBzz

    Randy – In some sense, VMware is appearing to be the open one, while their control (de facto) of the standard gives them an unfair advantage (at least perceived) over competitors who adopt it. Nobody will trust them. Nobody will trust Amazon either, for that matter. As @botchagalupe has been saying, vCloud may have a lot of operational overhead that makes it not great as a public commodity cloud underpinning, and not even that great as a private cloud.

    I don't agree with your railroad analogy, however. Moving from one cloud to another requires translation, brokering or whatever, but it's not technically all that hard (CloudSwitch, RightScale, etc.). Taking a locomotive and adapting the wheels in real-time to switch track size… well, I think we'd all agree about the downside of a #FAIL scenario there! Standardization will unlock growth, but the market may well go along for many years with lots of heterogeneity. Fortunately, the enterprise is used to that complexity.

    Anyway, great post.

  • http://twitter.com/cloudbzz JohnTreadwayCloudBzz

    Randy – In some sense, VMware is appearing to be the open one, while their control (de facto) of the standard gives them an unfair advantage (at least perceived) over competitors who adopt it. Nobody will trust them. Nobody will trust Amazon either, for that matter. As @botchagalupe has been saying, vCloud may have a lot of operational overhead that makes it not great as a public commodity cloud underpinning, and not even that great as a private cloud.

    I don’t agree with your railroad analogy, however. Moving from one cloud to another requires translation, brokering or whatever, but it’s not technically all that hard (CloudSwitch, RightScale, etc.). Taking a locomotive and adapting the wheels in real-time to switch track size… well, I think we’d all agree about the downside of a #FAIL scenario there! Standardization will unlock growth, but the market may well go along for many years with lots of heterogeneity. Fortunately, the enterprise is used to that complexity.

    Anyway, great post.

  • Bob

    “Amazon (AMZN), as a whole, is roughly 10x the size of VMware (VMW) in both employees and revenue. “
    I am not sure how you figured this out. For your information, VMW has 6700 employees and AMZN has 18400.

    7 times 10 = 70, not 18.

    • http://cloudscaling.com randybias

      You are right. I stand corrected. I will update the article to say 3x the employees and 10x revenue.

  • Bob

    “Amazon (AMZN), as a whole, is roughly 10x the size of VMware (VMW) in both employees and revenue. ”
    I am not sure how you figured this out. For your information, VMW has 6700 employees and AMZN has 18400.

    7 times 10 = 70, not 18.

    • http://cloudscaling.com/blog randybias

      You are right. I stand corrected. I will update the article to say 3x the employees and 10x revenue.

  • bmullan

    I think one approach AWS has made is it's Virtual Private Cloud (VPC) offering.

    Many Enterprises that may have considered buying VMware (lets not forget how expensive VMware licensing is for an Enterprise) may start to consider VPC if the compute/storage resources are in their own address space allowing the enterprise to use their existing nms etc tools for both their existing DC and any “virtual” DC components inside their AWS hosted VPC.

    • Pingback: BotchagalupeMarks for September 15th - 14:26 | IT Management and Cloud Blog

    • http://cloudscaling.com randybias

      The Amazon VPC offering is a great start. It will definitely entice enterprise customers to move additional batch processing loads. However, this is not an isolated or dedicated offering, so it is unlikely that customers will move production or workloads that require security and data privacy.

      Amazon will continue to make minor inroads into the enterprise, but will never be able to make significant inroads without dramatically changing their offering.

  • bmullan

    I think one approach AWS has made is it’s Virtual Private Cloud (VPC) offering.

    Many Enterprises that may have considered buying VMware (lets not forget how expensive VMware licensing is for an Enterprise) may start to consider VPC if the compute/storage resources are in their own address space allowing the enterprise to use their existing nms etc tools for both their existing DC and any “virtual” DC components inside their AWS hosted VPC.

    • http://cloudscaling.com/blog randybias

      The Amazon VPC offering is a great start. It will definitely entice enterprise customers to move additional batch processing loads. However, this is not an isolated or dedicated offering, so it is unlikely that customers will move production or workloads that require security and data privacy.

      Amazon will continue to make minor inroads into the enterprise, but will never be able to make significant inroads without dramatically changing their offering.

  • Pingback: My Homepage

  • http://techinstigator.com/ Chris Fleck

    Interesting analysis. I agree there is much more to come in this battle, I think the vCloud lock-in is not something Enterprises want from a Cloud provider.
    I did a brief comparison of Amazon vs Terremark Cloud Economics here:
    http://community.citrix.com/x/lgDuB

  • http://cloudscaling.com randybias

    Thanks for the comment, Chris. Can you be a little more specific about what you mean by 'vCloud lock-in'? Given that the principle interface to any cloud is it's API, that the vCloud API can be put on any cloud that doesn't infringe VMware's trademarks (even Xen-based ones), I don't see the lock-in.

    As far as I am aware the best case for lock-in would be to suggest that the hypervisor will force lock-in, not vCloud itself. I think there is a good argument to be made for that; however, as the hypervisor is only going to continue to commoditize, I think eventually it will be free or nearly so and it just won't matter.

    Or are you referring to something else?

  • http://samj.net/ samj

    Sure there will be lock-in for both vCloud and OVF. Users aren't stupid and will quickly learn that they need to use VMware to avoid compatibility reasons just as they continue to reach for Microsoft Word today even though document standards are “open”.

    Does OVF work for portability today? Not so much. Will vCloud (or whatever they end up calling it) work for interoperability tomorrow? I very much doubt it.

    Sam (who'd rather no particular vendor enjoy an unfair advantage by having their native standard “forced” on others)

  • gschofield

    Is it fair to compare VMware and Amazon on market cap? It would seem like the EMC ties VMware has should carry some weight.

  • http://samj.net/ samj

    No, it's not at all fair to compare legacy vendors to cloud providers based on market cap. It's like assessing the market share in terms of vehicles on the road by comparing the revenue of Toyota and Tesla – the former can get 10x as many cars on the road for the same price.

    Comparisons of Microsoft vs Google Apps revenues are similarly misleading as for each Microsoft user displaced by Google there is a much smaller spend (which is exactly why people are flocking to these services).

    Of course this means that the providers have to do a lot more with a lot less (ditto the ecosystem around them), but this also means the agile upstarts are relatively safe from the dinosaur incumbents.

    Sam

  • http://cloudscaling.com randybias

    That's of course the point of the article. At first glance based on ticker information it's not an interesting story, but … dig in, and it's quite interesting.

  • http://cloudscaling.com randybias

    I don't think this is true, although I agree with your general thrust. Standards, interoperability, and compatibility are regularly achieved through both openness and 'de facto' standards.

    Using Microsoft Word, as an example, simply reinforces the primary point of my article, which is that Amazon missed the bigger opportunity by not being more open sooner and that because they did VMware is able to make a Microsoft-like play.

    Comparing to the Microsoft Office suite directly, however, doesn't make sense as those were not open standards to begin with, while the vCloud API is starting out as open. Also, none of the vCloud-related products are shipping from VMware so plenty of folks have an opportunity to get in there and build vCloud API-compatible products. In other words, Microsoft dominated from two main factors: 1) a closed document standard and 2) market dominance. In this case, VMware does not have #1 and #2 it only has inside the enterprise market.

  • http://twitter.com/wattersjames James Watters

    Sam I think the variability of revenue is an important point here. Say Amazon has $200M in EC2 revenue (I know that's more aggressive than Randy's estimate but I've heard numbers that high often)…what would that have equated to in internal IT spending for VMwares customers? I think the number would be a multiple of 2-3x at least?