The Retailer's Servers
You are a senior executive at an online retailer that has only just become profitable. Your engineers have spent years rebuilding the company's systems as reusable internal services. Some propose selling raw computing and storage to outside developers.
Should a retailer become a supplier of computing infrastructure to anyone who wants it?
The situation
It is 2003. Your company sells books, music, electronics and much else online, and it hosts other merchants on its site. After years of losses, it has recently become profitable, and investors are watching its margins closely.
Behind the scenes, your engineers have spent years untangling the company’s systems. Early on, the website was one large program; scaling it was painful. Teams now build and expose their functions as services with defined interfaces, so that other teams can use them without coordination. Your engineers have also built shared infrastructure, storage, computing and databases, that internal teams use to launch projects quickly.
What you know
Your engineers say the infrastructure is reliable at very large scale and that running it is a core competence. They have noticed that start-ups and developers everywhere face the same problems your teams used to face: buying servers, finding space, setting them up and paying for capacity they rarely use.
Software that lets one physical server act as many virtual ones has matured. Bandwidth is getting cheaper. Your company has run online services for others, including its marketplace, for some years.
What you don’t know
You do not know whether developers would trust a retailer with their computing, whether a pay-per-use business could ever be profitable, or whether large technology companies would quickly copy the idea and crush it. You do not know whether running infrastructure for outsiders would distract the company or create risks for the retail site.
The voices in the room
Some argue that this is a distraction from retail, the business investors understand, at a moment when profitability is fragile, and that selling infrastructure could help competitors. Others argue that the company has built something rare, and that selling it could become as big as the retail business. A middle group suggests licensing the software or spinning the business off.
What happened
The company was Amazon. Over 2003 and 2004 its leaders discussed turning the company’s infrastructure capabilities into services for outside developers. Amazon Web Services launched its Simple Storage Service (S3) in March 2006 and its Elastic Compute Cloud (EC2), in beta, in August 2006: simple building blocks, priced by usage. Developers and start-ups adopted them quickly, followed by larger companies. When Amazon first reported AWS results separately, for 2015, the business had revenue of about $7.9 billion and was highly profitable. By the mid-2020s AWS revenue exceeded $100 billion a year.
Judging the decision apart from the outcome
Process and outcome were both strong. Three features of the process stand out. First, it started small: storage and computing primitives, not a complete platform, launched and priced so they could be improved quickly. That kept the bet reversible while it was uncertain, in line with the two-way door principle Amazon later articulated. Second, it rested on a real, existing capability, built for internal reasons, as described in Yegge’s Platforms Rant. Third, it applied the logic of transaction costs in reverse: by making computing trivially easy to buy, Amazon changed which companies should build it.
It was not without risk. Competitors with deeper experience in enterprise computing could have moved faster. That they took several years to respond seriously was partly luck, and partly, perhaps, the innovator’s dilemma: cheap, simple, self-service computing looked unattractive to companies selling expensive servers and software.
What a good process would have weighed
The case against was real: distraction, thin margins, risk to the retail site and helping competitors. The case for rested on the size of the unmet need, the company’s genuine capability and the possibility of starting small. Licensing or spinning off would have reduced risk but forfeited the learning and the scale that came from running the service directly.
Sources and limitations
Launch dates are from Amazon’s announcements, and the 2015 revenue figure from Amazon’s annual report. The account of internal discussions draws on books by Brad Stone and by former Amazon executives Colin Bryar and Bill Carr; these are secondary and participant accounts. The interpretation of competitors’ slow response is the author’s.
The reveal
Amazon, 2003
Offer simple building blocks, storage and computing, to any developer, priced by usage.
Paid off
The company launched simple storage and computing services in 2006, priced by usage. They grew into the world's largest cloud computing business, with revenue of about $7.9 billion when first reported separately for 2015, and over $100 billion a year by the mid-2020s.
Strong
Judged on what could be known at the time, separately from the outcome. See moral luck.
The forces pulling at the people deciding
-
Why firms buy instead of build
Most companies built their own servers because renting computing was awkward and inflexible. A simple, reliable, pay-per-use service lowered the transaction costs of buying computing so far that building it in-house stopped making sense for many.
-
Making computing cheap and instant to obtain did not just serve existing demand. It created enormous new demand, from start-ups to large companies running things they would never have built a data centre for.
-
The first services were simple primitives, storage and virtual machines, that could be launched, priced and improved without betting the company. Commitments grew as demand proved itself.
-
Architecture mirrors organisation
The company had already reorganised so that internal teams communicated through service interfaces. That structure made its infrastructure something that could be offered to outsiders.
Signals that were visible at the time
- Internal teams had standardised on shared infrastructure services with clear interfaces.
- Many developers and start-ups found buying and running servers slow and expensive.
- Virtualisation software made it possible to divide physical servers into many rentable virtual machines.
- The company had experience running a marketplace for third-party sellers on its platform.
Your best internal capability may be someone else's missing product.
Follow the thread
Connections
Where this comes from
Sources
- Amazon Web Services, “Announcing Amazon Elastic Compute Cloud (Amazon EC2) – beta” (August 2006).
- Amazon.com, Annual Report 2015 (Form 10-K), segment results for AWS.
- Brad Stone, The Everything Store (Little, Brown, 2013).
- Colin Bryar and Bill Carr, Working Backwards (St. Martin's Press, 2021).
Teaching this case? The teaching note has learning objectives, a 60-minute session plan, discussion questions and the key facts on one page.
Shrikant Kumar. “The Retailer's Servers.” Decide case, Telos. https://shrikantk.com/decide/the-retailers-servers/