Service-Dominant Logic: Why AWS Is So Far Ahead

© 2013 Jeff Sussna, Ingineering.IT

A couple of years ago I migrated a LAMP application from a colo space to AWS. While for the most part I took a forklift approach, I did try to take advantage of basic AWS services such as ELB, auto-scaling, multi-AZ RDS, and so on. My application architecture included a memcached server. After investigating possible memcached fault-tolerance solutions, I ended up settling for a single instance.

Just a few weeks later, Amazon released their ElastiCache service. It felt as if they’d been reading my mind. In fact I think they were. I believe Amazon views their customers through a fundamentally different lens from their competitors. In my opinion this lens explains both their mind-reading abilities and their dramatic lead in the cloud market.

As I see it, Amazon hasn’t fooled themselves into thinking they’re in the servers-on-demand business. They don’t care whether they’re selling Infrastructure-as-a-Service, Platform-as-a-Service, or Beer-as-a-Service. They understand that their customers don’t just come to them looking for Elastic Things, whether servers or storage or load balancers. Instead, customers use Amazon’s elastic things to help themselves operate scalable, fault-tolerant, cost-effective web applications. Amazon’s understanding comes from applying service-dominant rather than goods-dominant logic.

According to goods-dominant logic, a vendor creates value, and gives it to a customer in exchange for money. According to service-dominant logic, the vendor and the customer co-create value together. The customer hires the vendor’s products, as it were, almost as it would workers, to accomplish a so-called “job to be done”. In the case of cloud, customers hire Elastic Things to help themselves build and operate resilient applications.

Amazon is able to read their customers’ minds because they’re always thinking about their customers’ jobs-to-be-done. They constantly strive to better understand those jobs, and to help their customers better accomplish them. This approach explains why Amazon releases composable components, not just monolithic systems. Not every customer’s job-to-be-done is identical; AWS components let customers combine them in subtly different ways to suit subtly different requirements.

Amazon differs from many of their competitors by virtue of always having been a service company. They’ve also benefitted from being their own customer. Companies such as Oracle, Dell, HP, Microsoft, and VMWare, on the other hand, have product pedigrees. I find it interesting that Google, considered by some to be the only truly viable competitor to Amazon on its own terms, also has always been a service company, and also has been its own cloud platform customer.

Speculation abounds regarding what Amazon’s competitors need to do to catch up. I don’t think it’s just a matter of innovating faster, or spending more money, or applying any kind of straightforward business strategy pivot. I think Amazon’s competitors need to accomplish nothing less profound than a complete change of perspective. They need to pivot from goods-dominant logic to service-dominant logic.

Originally published at

I help SaaS delivery teams & executives meet the demand for continuously evolving value & dependability.

I help SaaS delivery teams & executives meet the demand for continuously evolving value & dependability.