Finding a differentiator

The commodity battle is only one front in the cloud wars

It’s nothing not new to say that there’s a battle raging amongst the cloud providers for the price of compute, storage and networking. Amazon started everything off with regular price cuts — mostly to its own Amazon Web Services to begin with, but now it’s fighting with Google and Microsoft.

The core services such as EC2, GCE, S3 and Azure VMs are commodities because such basic services are not differentiated, aside from small feature differences. This is the commodity pricing battle — as each provider uses its scale to produce more efficient data centers, it is able to pass on the savings in raw compute, storage and networking costs directly to customers.

Such scale makes it very difficult for other providers to compete because they have to be able to invest the huge sums of money to execute on otherwise crazy projects such as laying their own trans-Pacific fiber or building their own electricity sub-stations. Indeed, this is why public cloud is usually a better choice than building your own data center.

Yet this doesn’t mean it’s a race to the bottom — there’s more than one battle being fought in the cloud war. Commodities are low-margin products used as components to create much higher-margin goods, and all three cloud providers offer a range of additional services built on top of the commodity infrastructure. These are products like DynamoDB, BigQuery, Stream Analytics, API Management, CodeCommit and Global Load Balancing.

[company]Amazon[/company] is in the lead with its cloud portfolio, followed closely by [company]Microsoft[/company] Azure and then [company]Google[/company]. Although we have new instance types and related features being announced for the core commodity products, most of the new releases are for portfolio products that all add to the toolset you buy into when picking a cloud vendor. There are still innovations behind the scenes that go into helping improve performance or reduce cost, but the strategy has shifted to software providing the differentiator.

Software is a very high-margin business. When you have a highly efficient underlying infrastructure, you can price based on value, which leads to a healthy profit. There are some concerns about Amazon’s resources in relation to the effect of the commodity-style pricing, but that ignores where the real profit comes from — software, delivered as a cloud service.  This is important in the context of the cloud vendors’ ability to spend on infrastructure improvements.

It also means that companies such as Google, which have very strong core engineering cultures, can compete by productizing systems they already have in-house. Google already had an incredibly efficient and large-scale infrastructure powering its consumer products, and that’s allowed it to rapidly release new features in Google Cloud Platform. Microsoft is not dissimilar with its own software engineering abilities.

The problem for any would-be competitor is that there’s a very high barrier to entry if it wants to compete with the commodity products. You need to at least match the level of scale and efficiency to hit the pricing points of the Big Three before you can even start to be competitive. This is why we saw [company]Rackspace[/company] adjust its strategy, focusing on the “managed” aspect of hosting rather than trying to directly compete on compute, storage and networking — even though it had existing data center deployments around the world.

Commodity means self-service through APIs and DIY management consoles; support is extra. That’s a good model if you can build systems yourself (or have in-house teams to do it for you), but it isn’t necessarily appropriate for the vast majority of small and medium companies that want everything managed for them, and it makes Rackspace’s managed services a valid differentiator.

Going after developers is another way to differentiate. Providing a fast deployment model and very simple services is how Digital Ocean has been able to grow its customer base so quickly. Compare this to the way Twilio took over the developer mindshare for the old SMS telephony business, or how Stripe reinvented the way developers work with payment processors. But it can’t be said that Amazon, Google and Microsoft ignore developers — indeed, both Google and Microsoft have very strong connections in the developer communities, so this may be a risky strategy. It will be interesting to see how Digital Ocean maintain its lead.

Where does this place other cloud competitors? As noted by Stephen O’Grady at Red Monk: “Such businesses must differentiate themselves quickly and clearly, offering something larger, more cost-competitive players are either unable or unwilling to.”

Location seems to be part of the strategy for IBM/Softlayer, combined with its push for big data and analytics with the Watson software line. What about Verizon, HP, CA, Cisco and Oracle? These players have yet to reveal how they intend to differentiate, and they need to do soon or risk being left behind. The war is fought on many different fronts. Focusing on a single battle will not end well.

9 Responses to “The commodity battle is only one front in the cloud wars”

  1. Rich Hintz

    I wasn’t aware of SaaS providers running top of multiple cloud providers. Any names you can share? There doesn’t seem to be much info on using Mesos cross provider. Any references you can share on that, too?

    Maybe I don’t understand what you mean by the usual definition of commodity. Would you explain this a bit more?

    • One startup I know has written about this publicly[1] is PagerDuty, who use x2 AWS regions (or at least x2 zones in a single region) + x1 Linode data center. And anecdotally, from working with customers at my company, Server Density, I know of several who are deployed across AWS + Rackspace, or AWS + Azure. And we’re seeing people start to test out Google in conjunction with AWS or Azure, too.

      Mesos abstracts away the underlying IaaS so whilst their current examples/deployments show within a single provider, it makes sense that this would be extended in the future to go across providers. It doesn’t need to be a particular feature in the product because they support HA[2], so if you manage your own network across data centers then that’d give you the effect of deploying across providers. Mesosphere specifically says[3]: “Mesosphere is capable of adding significant value on IaaS, on bare metal or a combination of those environments”

      As for the definition of “commodity”, you can take it from https://en.wikipedia.org/wiki/Commodity i.e. “a class of goods for which there is demand, but which is supplied without qualitative differentiation across a market…the market treats its instances as equivalent or nearly so”.

      But the technical definition isn’t so important – the idea as I described in the article works as a way to understand the current situation even if it doesn’t strictly match every requirement to be called a “commodity”. The important thing is the IaaS services form a foundation for the services built on top. From Wikipedia, “There is a spectrum of commoditization, rather than a binary distinction of “commodity versus differentiable product”. Few products have complete undifferentiability and hence fungibility…”

      [1] https://www.pagerduty.com/blog/surviving-datacenter-outage/
      [2] https://mesos.apache.org/documentation/latest/high-availability/
      [3] http://mesosphere.com/docs/benefits-cloud/

      • Rich Hintz

        This has been an interesting discussion. Thanks for bringing up the topic. I sense the discussion is running out of gas, so some final comments.

        The Pagerduty use case is pretty specific for machine-machine replication transactions, where order, latency, and single message execution aren’t too important. Yes, this is an important use case, especially in HA architectures. I don’t, however, think it represents what one would expect in the usual human-machine interactions.

        Also, the case where one would want to port a base transaction app from provider to provider with minimal or no changes isn’t really in play here. The experience you allude to with customers cross AWS & Azure, for example, may be more of what at least I’m thinking of as commodity interchangeability. YMMV.

        And, yes, I know what Mesos does, I just wasn’t aware of in real life working apps that were cross provider. That doesn’t mean there aren’t any, of course.

        Yeah, I was using the economic definition of commodity, which is pretty much the Wikipedia definition, “…without qualitative differentiation…” To me, as I mentioned earlier, this would allow auto forklift of an app, cross provider. I don’t think anyone disagrees that IaaS form a foundation for services built on top. They just aren’t readily interchangeable in a useful sense, today at least.

        Full OaaS fungibility isn’t likely, but I can conceive likely scenarios where apps seek lowest cost, best availability, lowest latency providers, probably for in-memory apps with a Pagerduty like approach to committing persistent transaction results.

  2. Azian Rahman

    HP, IBM, Cisco, etc, aren’t they all banking on the investment each of them has made in OpenStack to help them compete in the IaaS “commodity offerings” at least against AWS, Google, MS?

    • Rich Hintz

      The issue with vendor OpenStack distros today is that the vendors are trying to show added value in their specific offerings, so they’re moving away from undifferentiated commodity.

  3. Rich Hintz

    Cloud services aren’t really commodity until a workload with active-active persistent data store backing can auto seek the cheapest, fastest, most resilient supplier, then move non disruptively according to policy.

    A non technical, economic indicator would be the emergence of a cloud resource “future” options market and hedging, when supplier differentiation including networking is sufficiently small.

    The innovation in the sector and current, pervasive, non SDN networking infrastructure would seem to make this unlikely anytime soon.

    • The underlying compute, storage and networking products are what I’m calling commodity, not “cloud services” broadly. That’s the whole point – the SaaS products that are built on top using these commodity components.

      We’re already seeing the marketplaces you’re describing with Amazon’s spot pricing within a single provider and across providers with something like OnApp Federation.

      • Rich Hintz

        But the SaaS products built on top of IaaS don’t freely switch to other IaaS providers based on cost, availability (SLA), and latency as a steel mill would pick iron ore from Supplier A in preference to Supplier B based on similar criteria.

        “Commodity” has a fairly standard economic meaning, which is why I made the futures market comment. We can say “commodity in the cloud/IT sense,” but it’s really not the same. I agree that spot market pricing is an interesting development, but it really has to be cross supplier to reflect a true commodity characterization.

        I wasn’t familiar with OnApp, but it looks like a broker service. You wouldn’t for example, move a workload from a Xen to a VMWare environment without a lot of technical heavy lifting, even if administratively you could do it with a couple of clicks.

        • It is becoming more common to run SaaS on top of multiple cloud providers for failover, perhaps less so for SLA or latency, but with projects like Mesos then this is more likely. The only reason this doesn’t happen for the SaaS apps I was mentioning is because they’re owned by the same companies than own the underlying services e.g. CodeCommit runs on EC2/S3/etc.

          I think the IaaS features match the conditions under the usual definition of commodity, but are still early in their commoditisation so the marketplaces and things like futures aren’t there yet.