How the battle for Cloud was lost, mapped

When we look at history, we see maps used to explain strategies used in conflict, and help us understand how battles were won or lost. In this post, I’m going to try to map out something based on what I’ve read, to see if it makes an argument easier to understand, and also to get faster at making maps, and demonstrate the process I used.


What I’m basing this post on

When reading Simon Wardley’s book type thing on Medium, a paragraph here leapt out at me, and it felt worth having a go at mapping out it. In chapter 17, Simon writes a bit about how the battle for cloud computing, specifically the Infrastructure As a Service market wasn’t so much won by Amazon, but lost by everyone else:

For example, it would have been relatively trivial for the hardware manufacturers to create Amazon clones and a price war in the IaaS space around 2008–2010 in order to fragment the market by increasing demand beyond the capability of Amazon to supply due to the constraint of building data centres. I had these exact conversations with Dell, IBM and HP throughout 2008 and 2009. I even told them their own inertia would fight against this necessary change and they would deny the existence of the punctuated equilibrium until it was too late.

It seemed a good candidate for mapping, and much writing I see only seems to focus on the details of what an API is, rather than the wider context this was occuring in.

So, off we go.

You can follow along with this deck I’ve made. Please make a copy and share one back if you have a different take on this!

Using cloud computing back in the late-noughties

I’m going to start simple with a simplified value chain, along one dimension, then over time, flesh it out with the second evolution axis, before adding various other bits, so you can follow along.

Making a value chain first

2017-09 Wardley Map for AWS in 2006

The diagram above is a very abridged value chain, of the components you might find needed to let someone do something useful online (I’ve chosen a vague need of buying something, as the anchor).

To by something online, well… you typically need a website, and that runs on a server operating system (server OS), which uses relies on computing power, typically provided by the server the operating system is running on. If you want the website to be available 24/7 you’ll probably put it in a data centre (i.e. room or building full of other servers).

Mapping the value chain

2017-09 Wardley Map for AWS in 2006 - value chain

Okay, now to plot this in the evolution axis ( you might think of how ‘boring’ or universally accepted/used something is.

You’d typically have a custom website, tailored to fit your products and audience, but it likely uses from framework, so you haven’t coded everything yourself, I’ve put that towards the custom build section, but not all the way for that reason. Likewise, the Server OS is probably one you’ve downloaded (probably linux), but someone has typically set it up to run websites, so it’s not totally commodity. Compute power is running on a load of chips, that are in the Server, which was probably purchased from someone like Dell, HP or so on. It’s more a product than anything else.

With me so far?

Adding VMs and putting an API on it

2017-09 Wardley Map for AWS in 2006 - AWS VMs

Physical servers aren’t the only way to provide computing power though. You can use virtual machines too, which typically would be easier to replace, and you wouldn’t expect them to last as long.

The big idea for Amazon’s Web Services was having an API exposed over the internet reachable by other computers, to let you spin up a virtual machine, which you could do whatever you wanted. It was much, much faster than waiting authorisation to buy a server, then waiting for IT to set it up for you.

When updating the map below, I’ve listed an API as relatively novel here, because if you’ve heard of an API to give you an virtual machine, it’s probably Amazon who you’d be getting it from, and at this point there aren’t that many others pushing well developed APIs as the way to use their services at this point.

For this reason, I’ve put the API to the left.


Hard limits further down the value chain

2017-09 Wardley Map for AWS in 2006 - DCs

Having access to computing resources like this turned out to be very popular, as it made it easier to start working on project. Amazon’s products – Elastic Compute Cloud (EC2) , and Simple Storage Service (S3) sell very well, and it quickly becomes the market leader in this new market.

Someone eventually needs to be running servers somewhere though, and these servers typically need to live in a data centre. And data centres of the scale Amazon is using are big expensive things to build.

So Amazon is now struggling to keep up with demand for it’s cloud computing – it can’t build data centres fast enough, so there is hard limit on how fast it can grow.

I’ve represented this with the big black block on the map above.

A possible counter for people who aren’t Amazon – using openness to attack the choke point

2017-09 Wardley Map for AWS in 2006 - API.png

As I understand it, Simon Wardley makes an argument that if you’re in a market where there’s a dominant player, you can counter this by finding ways to make the market grow faster than they do, deliberately trying to fragment the market.

The way you would do this would be to find the thing limiting the growth for a market leader, and attack there.

If you look at the map here, I’ve shown the API moved all the way to the right – as if someone had created an open API here, perhaps though an open source project like Openstack, that would be freely available for anyone to build into their products.

How this changes the map

2017-09 Wardley Map for AWS in 2006 AWS DC bottleneck

It stops Amazon being so special, and being such a rare provider of business agility through cloud computing. If you’re already an Amazon AWS customer, you can move to another provider more easily. Because the API is open, and can be adopted easily, as long as another provider offers the same API, you can move to them too if the current provider turns out to be too pricey, or below par.

This increases competition, and creates downward pressure on pricing. As pricing falls, more people end up using cloud computing, the entire market grows faster.

Remember the limiting factor being the speed at which Amazon’s can build data centres?

This is a bit I didn’t really understand for quite a while when thinking about open source. It’s important to see the open source move here as a deliberate offensive strategy at a weak point of a larger player, not just something people do out of altruism.

If the entire market is growing faster than the market leader, than its share of the market decreases, and as a result its influence over the market is reduced. You have a healthier ecosystem of providers, and the profits don’t end up being captured by a single player.


What happened instead – open but not API compatible

2017-09 Wardley Map for AWS in 2006 - a bit less common

As it turned out, more than one open source competing project was started to provide an alternative to Amazon AWS – Open stack was one, and Cloudstack was another.

Neither have had the same kind of adoption Amazon’s APIs have had.

Openstack had their own API that wasn’t compatible with AWS, who were already the market leader by this point. This meant even were already using AWS, and you wanted to move to using Openstack, moving away from once you had dipped your toes in the water was more difficult, and hard to justify.

As I understand it, Cloudstack might have been API compatible, but it didn’t get as much buy-in as Openstack, so its played a less prominent part in history.

Worse, the providers of different flavours of Openstack ended up differentiating parts of their APIs amongst themselves, so migrating from one provider to another wasn’t particularly easy.

This meant that when they did make sales, each Openstack vendor might have made short term profits, and helped sell some servers at the nice margins they were used to.

However more organisations moving to cloud just went with the market leader, Amazon.

Worse still, because Amazon had such a dominant position, it had less pressure to lower its prices to fend off competition, and could instead invest subsequent profits in running ever more efficiently, or coming up with more complex products it could sell at higher margins (i.e. Amazon has a similarly dominant position now with AWS Lambda in the new Functions As a Service market)

Even with more major players in the market now (Google and Microsoft in particular), I can’t see Amazon really losing its lead over the next 5 years.

Does this sound about right?

Does this sound convincing to you? Is there something obvious missing here you would add?

I’d love to hear back from ideally using a map as conversation aid – feel free to make a copy and edit the deck I created as a shortcut.




Leave a Reply


You are commenting using your account. Log Out /  Change )

Google+ photo


Twitter picture


Facebook photo


Connecting to %s