AWS & strategy over the years
Wardley what?

I started using and consulting on AWS somewhere around 2008. Over the years AWS has extended its service portfolio and its geographic presence, not to speak of the huge increase in computing and storage capacity in all its datacenters.

While the increase in geographical reach and absolute capacity are easy to understand — simple response to raw customer demand — the updates to service portfolio require more thinking. Why this service? Why at that particular time? Are there any clear patterns? Could you predict future AWS services?

Viewpoint: Adoption life cycle

One can look at AWS through the adoption life cycle, and say that

• Initially AWS targeted innovators by producing useful MVP services (I’ve discussed one aspect of this in 2013 and still stand by that reasoning.)
• Once “cloud” became as a viable business platform (“early adopters”), it broadened its service coverage.
• … and so on …

Viewpoint: Developer-visible phases

I chance at another timeline categorization based on my own perception of using AWS services:

1. Establishing “cloud” as a viable option for new development projects, offering minimal but valuable services via leveragable interfaces (aka APIs)
2. Pivoting towards making AWS viable for enterprises to integrate and later migrate existing systems to, adding more varied and less developer-focused services, expanding features of existing services
3. Making everybody’s head spin with a plethora of overlapping and confusing services announced at increasingly rapid pace

The first two are clear, and I would put the dividing line between those two phases at the the introduction of VPC in August 2011 and Direct Connect in September 2011. Why? Because Direct Connect makes more sense in integration with existing workloads in enterprise data center than for cloud-only projects. While VPCs were useful for cloud-native workloads, they were essential for enterprise data center integration and Direct Connect.

This does not mean that enterprises jumped on AWS bandwagon at that point. No no no! — Yet, there is a strategy. Simple toe-dipping projects can be isolated, but to do real business, enterprises needed integration with existing CRM and ERP systems. For that, more enterprise-oriented features came along. Eventually enterprises gained more confidence and actually started migrating existing workloads off their own data centers (an obvious progression).

Viewpoint: Software engineers a.k.a. chaotic code cranking machines

What about the third step, the head spinning and confusion? (I alluded this in 2015 when lamenting the loss of “expert cloud generalist”.)

AWS is announcing new services and new features on existing services at an astonishing pace. Some years back I looked at AWS’s open positions, and was thinking like why is AWS hiring all these developers?

To write software, of course. For existing services? No, while you need some more people when the service is growing exponentially, the basic tenet of cloud engineering it to create systems that scale well. Neither it was tenable that AWS’s retention would have been so bad to require hiring software engineers at the pace that was apparent from their open positions.

To write software for new services.

It often feels that AWS is overrun by engineering teams and service ideas and cannot always produce coherent and co-working interfaces. Maybe we are a phase where AWS usage is growing so fast, they put resources to any development that seems to be “cloud”.

This is a possibility, but it might not be true, or only a partial truth.

Viewpoint: It’s all intentional

Another, a bit more sinister possibility is that AWS is doing the innovate-leverage-commoditize (ILC) cycle faster, and faster, and with more and more software engineers (speeding up internal development cycle multiplied by more developers)

You really should check Simon Wardley’s work on strategy. I’ll let this one tweet from him (with pictures!) lead into why he things AWS is getting faster.

X: Why do you think Amazon is so dangerous? Don't you think they will slow down?
Me: No, they'll get faster.https://t.co/LiUlzyn9RZ pic.twitter.com/TpWmGdulaQ

— Simon Wardley #EEA (@swardley) 30. lokakuuta 2017

Just looking at the ludicrous number of launches and updates would appear to support better the former — chaos — hypothesis. WTF satellite ground station as a service? That’s hardly a high-volume low-margin business. What is next, purchase satellites on a credit card?

On the other hand, it could be that Amazon is using AWS’s momentum in the cloud space to rush into any high-margin high technology area, and assume it has the technological cloud and enough runway to cause chaos and panic on incumbents in any area (satellites?). Leapfrogging to providing lower cost, automated, self-service, something-as-a-service, attempting to exploit the inherent slowness and obstacles of existing market players.

In this context, it would not be a terrible loss if some of these eventually fail. Why would you attempt to compete in the current market, when you have the chance of owning the future market?

I am no strategist, but I’ve learned that most of what appears as strategy is often just a retroactive narrative. What in reality was a jumble of intentional strategies, bunch of accidents and a lot of groping in the dark is often cleaned up, diced and re-assembled into a narrative that promotes the supreme wisdom of the supreme leader company. The question is not whether Amazon slash AWS is chaotic. It undoubtedly is, and a lot of the history will be written into a nice, retroactive, primetime story. Nevertheless, this does not exclude the possibility that amid all of the chaos there is a conscious, strategic direction being implemented.

(You can see all posts from re:Invent 2018 footpedalling down the reinvent2018 tag.)