Microservices for Modern Commerce

Chapter 1. A New Commerce Landscape

Changing Consumer Demands

We are entering a new era in commerce. Consumers demand to seamlessly transact anywhere, anytime, on any client. Every sale is the culmination of potentially dozens of interactions with a consumer. Today, smartphones alone influence 84% of millennials’ purchases. Digital touchpoints influence 56% of all purchases. Selling something to an end consumer is far more complicated than it used to be, even just 10 years ago. Consumers are firmly in charge and expect to make purchases on their terms.

What do today’s consumers want?

A Brand Experience—Not Simply a Transaction

Those engaged in commerce are surviving and thriving in today’s era of commoditized goods by creating experiences, often through the use of content. Consumers want a story behind the product they’re buying. A product is never just a product—it’s a reflection of the consumer. It’s a statement. Today’s brands are successful because they are able to de-commoditize the products they sell. This requires the extensive use of content—text, video, audio, and so on.

Consistency of Experience Across Channels

Consumers no longer see divisions between channels (point of sale, web, mobile, kiosk, etc.). Consumers expect to see the same inventory levels, product assortment, pricing, and other aspects, regardless of how they interact with a brand. Whereas tailoring an experience to a channel is acceptable, offering a fragmented experience is not.

Value-Added Features

A primary driver of online shopping is the additional functionality that that it offers beyond that of a physical store. These features include a larger product assortment, ratings/reviews, more in-depth product descriptions, additional media (enhanced product photos/videos), related products, tie-ins to social media, and so on.

Convenience

Barely a hundred years ago, physical retail stores were the only way to make a purchase. Then, catalogs came of age. In the late 1990s, the Internet began to take off, and consumers could purchase through a website. Later, smartphones came of age when the iPhone was released in 2007. In the decade since then, the number of devices on the market has exploded, from smart watches to Internet-enabled TVs. Nearly every Internet-connected consumer electronic device hitting the market today offers an interface that consumers can use for shopping. New user interfaces are hitting the market weekly and successful brands must be able to offer their unique experience on every one of these new devices.

Retailers (and Everyone Else) Are Now Powered by Software

Technology permeates every sector of the economy, even those not formally classified as high-tech. These days every company is a tech company.

The New York Times

The increased demands from consumers have forced retailers to turn into software companies who happen to be in the business of selling physical or virtual products. Every aspect of a retailer runs on software—from product placement on shelves, to the robots that power warehouses, to the app that runs on the latest Apple Watch.

Software not only saves money by improving efficiency, it can drive top-line growth by enabling marketers to build successful brands. Consumers want an experience—not simply to buy a commoditized product. Marketers can use technology to form life-long bonds with end consumers by matching the right content to the right consumer.

Differentiation through software is driving retailers to build software from scratch rather than buy it prepackaged from a third-party software vendor. Differentiation in the marketplace is difficult to accomplish when everyone is using the same software. If software is the core of the business, it makes sense to make substantial investments in it to provide market-leading differentiation. It’s no longer an IT cost that needs to be minimized.

The Status Quo Is Too Slow

Most enterprises with $100 million per year in online revenue release code to production too slowly. Releases often occur once each quarter and require an evening of downtime. Often, the entire team must come in over a weekend.

Enterprises are still learning how to reorient themselves around software. It wasn’t too long ago that commerce was seen as an IT-only expense, out on the periphery of an organization.

Let’s explore a few of the varied issues.

IT Is Seen as an Expense to be Minimized

Many enterprises still see IT as an expense—not as the business. Work is submitted to IT, as if it were an external system integrator, rather than an enabler of the business. If work is submitted to third-party system integrators, the lowest cost bid often wins out. Software and services are often centrally procured and an entire enterprise is forced to use the same technology stack regardless of fit. This culture of cost minimization comes from the days when IT was more on the periphery of business rather than the business itself.

Organization Structure

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Mel Conway (1968)

Conway’s famous observation in his seminal paper has been so crucial to microservices that microservices is often called “Hacking Conway’s Law.”

Most IT organizations are set up to minimize cost through specialization (see Figure 1-1). Storage administrators are in their own group, Java developers are in their own group, and so on. This allows each person to be fairly efficient, but the system as a whole is slower.

Figure 1-1. Typical horizontal-focused specialization within an enterprise

Each team has its own work location, process for receiving work (typically a ticketing system of some sort), service level agreements, process for assigning work to individuals, release cycles, and so on. This strict separation makes it difficult to make any changes that span multiple teams. For example, suppose that a Java developer receives a requirement to begin capturing a customer’s shoe size during registration. In a typical enterprise, this would be incredibly difficult even though the work should take about two minutes for any competent developer to perform. Here’s a non-exhaustive list of the serial steps required to perform this:

1. Java developer receives requirement

2. Java developer must use DBA’s ticketing system to file a ticket

3. DBA team receives work order, prioritizes it, and assigns it

4. DBA adds column to database per work order

5. DBA updates ticket, requesting that the Java developer view that it was added correctly

6. Java developer logs in to database and finds that it was added correctly

7. Java developer updates ticket stating that the column was added correctly and that the change can be promoted

8. Java developer waits for next database build

9. Java developer updates the object relational mapping system to look for the new column in the database

10. Java developer updates the registration API to include birth date

These steps are exhausting even just to read, yet this is how even minor changes are implemented in enterprises. These steps don’t even include the UI updates. This bureaucracy, due to horizontally specialized teams, is what leads to quarterly releases.

With teams so large and isolated, a corrosive culture of distrust develops. Rather than working together, teams are motivated to erect more bureaucracy (change requests, architecture review panels, change control boards, etc.) to cover themselves in the event of a problem.

Coupling

Today’s enterprises are characterized by extreme coupling, both in terms of organization and architecture.

Let’s begin with organization.

Enterprises cause extremely tight coupling between horizontal layers because they build teams of people who have only one focus. For example, each user interface (point of sale, web, mobile, kiosk, etc.) has its own team. Those UIs are tightly coupled to one or more applications, which are each owned by a separate team. Often, there’s an integration team that glues together the different applications. Then, there’s a database on which all teams are completely dependent. Infrastructure is managed by yet another team. Each team, no doubt, is good at what they do. But those barriers cause tight coupling between teams, which introduces communication overhead and causes delays.

It would be as if an auto repair shop had one person to order tires, another person to unscrew the lug nuts, another person to remove the old tire, another person to balance the new tire, another person to mount it, and one final person to screw on the lug nuts. Sure, each of those six people are the best at what they do but the overhead of coordinating those activities across six people far outweighs any gains had by the efficiency improvement at each step. Yet this is how enterprises operate today. In the past, this was necessary because these layers all required extensive expertise. For example, networking required decades of experience and real competency. Now it’s all software-based, as illustrated here:

$ docker network create frontend-network

To further complicate matters, enterprises encourage too much code sharing. Because IT is seen as a cost, and code is expensive to develop, many enterprises force development teams to reuse as much code as possible. For example, suppose that a team within an enterprise builds a new OAuth client that is forced onto the other teams within the entrprise as a form of cost savings. Every team that this library is forced on now has a firm dependency on the team that created the OAuth client. There is now a tight coupling between teams where one didn’t exist before. A typical enterprise application could have hundreds of shared libraries, creating a web of dependencies. Over time, this complex labyrinth devolves into paralysis; everyone is afraid to touch anything because it could break the entire system.

Architecture introduces even more coupling. Enterprises have a handful of large, monolithic applications such as ERP, CRM, WMS, OMS, CMS, and so on. These large monolithic applications often expose many different endpoints, but those endpoints are often not independently consumable. The endpoints must be called in a specific order and fed specific data. That’s why these monolithic applications are glued together by the use of enterprise service buses, with a lot of business logic residing in those buses. This tight coupling of large monolithic applications results in testing and releasing all monolithic applications together as an atomic unit. Changing one endpoint in one monolithic can have wide-ranging consequences across many of the other monolithic applications that might be consuming it.

Yet one more way of coupling is the practice of releasing only one version of an application to production at any time. Suppose that a company deploys version 3.2 of a monolithic commerce application to production. The website, iOS, Android, kiosk, and chatbot clients have all coded to version 3.2 of that application. What happens when the company deploys version 4 of the commerce application? It’s going to break all of the clients that have coded to version 3.2. With only one version of an application deployed, you must update your monolith and all clients at the same time, which is coupling at its most extreme.

The coupling introduced by organization structure and architecture choices has one major consequence—decreased speed.

Packaged Applications

Many of today’s enterprise applications are large, monolithic packaged applications that are bought from a handful of large software vendors, deployed on-premises, and heavily customized. Many packaged commerce applications have millions of lines of customized code.

These applications are sold to thousands of customers. Those thousands of customers each write millions of lines of customized code on top of the application. As the number of customers increases, the vendors that sell the software are increasingly unable to make changes because of all the trouble it would create. The more successful the product, the slower it evolves. It gets frozen in time.

(Real) Omnichannel Is the Future

Omnichannel is the future of retail. Today’s top leaders have mastered it, but the vast majority of retailers have yet to adopt it.

To end consumers, omnichannel means having a consistent experience with a brand, regardless of how they interact with it. Whether through a website, mobile device, wearable device, or in store, the experience is the same and integrated.

The web is dead. Long live the Internet.

Chris Anderson and Michael Wolff , August 17 , 2010

This is why many in the industry have dropped “e” from “eCommerce” to reflect that it’s not something different. Consumers should be able to buy online and pick up or return in-store, browse in-store and buy online, have access to the same promotions, and so on. If channels are offering different data (subset of products, different prices, etc.) it should be because the experience is being optimized for each channel or there are opportunities to price discriminate.

To technologists, omnichannel means having one backend system of record for each bit of functionality (pricing, promotions, products, inventory, etc.), with UIs being more or less disposable. Developers of UIs get a large catalog of clearly defined APIs (often HTTP plus REST) that can be composed into a single application, as demonstrated in Figure 1-2.

Figure 1-2. True omnichannel—single systems of record for each business function; disposable UIs

Again, the experience per channel can vary, but the variations are deliberate rather than as a result of IT fragmentation.

Most of today’s enterprise commerce platforms are sidecars on top of the old in-store retail platforms. There might be additional sidecars on top of the commerce platforms for other channels, such as mobile. Each of these systems acts as its own mini system of record, with heavy integration back to the old in-store retail platform, as shown in Figure 1-3.

Each system has its own view of pricing, promotions, products, inventory, and so on, which might or might not ever be reconciled with the eventual system of record. For example, many retailers have web-only pricing, promotions, products, inventory, and so forth.

Figure 1-3. Typical commerce application—large monolithic applications tightly coupled with legacy backend systems of record (ERP, CRM, etc.)

This approach worked adequately when there were just physical stores and a website. But now, there are dozens if not hundreds of channels. The old approach just doesn’t scale anymore. As a thought experiment, could you deploy Amazon.com as a single monolithic application as one large EAR file? No. It’s ludicrous to think about it. But retailers trying to unseat Amazon.com regularly deploy large monolithic applications, expecting to be able to release new functionality with the same agility as those who have implemented omnichannel from the very beginning. Amazon.com has famously used microservices since 2006. Today, it has thousands of individual microservices that serve as building blocks for dozens of UIs.

Fortunately, there is a better way….