eCommerce in the Cloud

Introduction

We are in the midst of an ecommerce-driven revolution in retail. Prior to the mid-1990s, ecommerce didn’t exist. Today, business-to-consumer (B2C) ecommerce is a $1 trillion per year business worldwide,^[2] directly accounting for 6.5% of total global retail sales.^[3] Over 50%^[4] of retail sales in the US are now influenced by ecommerce. Emerging markets like Brazil, Russia, India, and China offer nearly limitless growth potential.

Note

For the purposes of this book, ecommerce is defined as any commercial transaction facilitated between two parties using the Internet. This book will be most useful to those running $100 million/year businesses selling physical goods and services over the Internet to end consumers, though the principles will be applicable to all forms of ecommerce.

eCommerce Deployment Architecture: Frozen in Time

In addition to becoming increasingly important to business, ecommerce is a fairly unique use case within information technology (IT). It’s perhaps the most visible platform a retailer has, either influencing or directly contributing around half of revenue.^[5] Failures lead to front-page news, disclosures in earnings calls, reduction in stock price, and firings. Most applications are just not that important—if payroll is processed five hours late, nobody cares. All customer touchpoints are increasingly likely to be facilitated by ecommerce, as point-of-sale systems are being replaced with tablets that connect to a single ecommerce platform. An outage now is the equivalent of barring customers from entering all physical stores.

Because of increasing competition and the maturity of offerings, customers are increasingly fickle about performance. They expect response times to be instant. The New York Times recently said: “The old two-second guideline has long been surpassed on the racetrack of Web expectations.”^[6] Going on further to say: “Two hundred fifty milliseconds, either slower or faster, is close to the magic number now for competitive advantage on the Web.” Amazon.com saw a 1% increase in revenue for every 100 milliseconds of response-time improvement.^[7] In today’s world, milliseconds matter.

Availability and performance are becoming increasingly difficult to offer as traffic has become more prone to rapid spikes due to an increasing reliance on promotions and marketing-driven events. We’ll discuss this more later, but it’s not uncommon to see spikes in traffic that are one or two orders of magnitude above steady state. Social media–based marketing can lead to campaigns going viral. From an IT administrator’s standpoint, the traffic can come so quickly that it looks like a distributed denial-of-service attack, when in reality it’s likely to be a few million kids hitting refresh on their pages in anticipation of the release of the latest hot basketball shoe.

While ecommerce has been maturing over the past two decades, the prevailing deployment architecture looks largely as it did in the beginning—mostly static environments fronted by web servers deployed out of a single data center. Many simply guess at what their peaks will be and then multiply that number by five for safety. Hardware is statically deployed and idle for most of the year. It’s been done this way for four reasons:

• IT administrators fear losing their jobs because of outages. It’s simply less risky to throw hardware at problems.
• For a while, ecommerce deployments were small enough that the hardware cost was negligible.
• There hasn’t been a good alternative to the static approach—cloud in its present form didn’t exist until very recently, and it’s matured only recently.
• The old models of hosting had more accountability. If there was an outage, you could always escalate to your vendor.

The current approach to ecommerce deployment architecture is not scalable. The rise in traffic has ballooned environments from dozens to hundreds or even thousands of servers. Given today’s extremely competitive business climate, it’s not feasible to have hundreds or thousands of servers sit idle for all but a few hours out of the year. It’s also increasingly difficult to predict traffic. Most important, and central to this book, is that cloud computing has matured to the point where it can be used for ecommerce.

What Is Cloud?

Cloud is one of those ineffable terms that has been redefined to encompass everything, yet means nothing. For the purposes of this book, the cloud is best characterized by three adjectives: elastic, on demand, and metered. Let’s look at each in greater detail:

Elastic

To be considered cloud, you must be able to increase or decrease a given resource either automatically or on demand by using self-service user interfaces or APIs. A resource can include anything you have in your data center today—from commoditized hardware running Linux (Infrastructure-as-a-Service), to application servers (Platform-as-a-Service), up to applications (Software-as-a-Service). The “what” doesn’t matter all that much; it’s the fact that you can provision new resources.

On Demand

Seeing as elastic is the first word used to describe the cloud, you must be able to provision a resource precisely when you need it and release it when you don’t.

Metered

You should pay only for what you use. This has enormous implications, as the costs directly reflect usage and can therefore be substantially lower.

When the term cloud is used in this book, it generally refers to public Infrastructure-as-a-Service. We’ll spend Chapter 3 describing cloud in more detail.

Why Is the Cloud a Fit for eCommerce?

Cloud is a natural fit for ecommerce because you can provision and pay for resources when you need them instead of building enormous static environments scaled for peaks. The goal is to provision automatically, which we’ll discuss in Chapter 4. Without the cloud, environments are statically built and scaled for peak load. It doesn’t make sense when you can use a cloud. The problem of underutilization is even worse for preproduction environments, many of which are built to some scale of production yet sit even more idle than production. Most deployments have approximately the following environments:

• Two production environments (each capable of handling 500% of the peak production traffic)
• Three staging environments (each being 50% of production)
• Three QA environments (each being 25% of production)
• Three or more development environments (each being 10% of production)

The staging environments are likely to be used for some form of automated testing about once a week or so. QA environments are likely to be used by a handful of QA testers. But that’s it. If you look at the average CPU usage of all these preproduction environments, it’s likely to be less than 1% for any given week, yet these environments consume the equivalent of multiple production environments’ worth of hardware. The situation is slightly better with production but not much.

In addition to being wasteful, building out and maintaining these environments is likely not your core competency as an organization and is likely distracting you from what you do best—whether that’s selling the latest iPhone or selling diapers. Let the few major cloud vendors hire the right talent to build infrastructure. Cloud computing makes so much sense for ecommerce that its proper use can provide you with serious competitive differentiation while lowering costs. Let’s explore how ecommerce and retail are changing.

---

^[2] Amy Dusto, “Global e-commerce Tops $1 Trillion in 2012,” http://bit.ly/MrUzqB (5 February 2013).

^[3] eCommerce Disruption: A Global Theme. Transforming Traditional Retail. Morgan Stanley, January 6 2013.

^[4] Rigby, Darrell, et al. “Omnichannel Retailing: Digital Disruption and Retailer Opportunities,” Bain Retail Holiday Newsletter (9 November 2012), http://bit.ly/1k7ypJ5.

^[5] http://bit.ly/1fwVX2r

^[6] Steve Lohr, “For Impatient Web Users, an Eye Blink Is Just Too Long to Wait,” New York Times (2012), http://nyti.ms/1esukXm

^[7] Greg Linden, “Make Data Useful,” Amazon.com and Findory, http://bit.ly/1k7ypZw (PowerPoint file download).