The retail landscape as we know it is in trouble. Credit Suisse estimates that 25 percent of U.S. malls will close within the next five years. More than 5,300 physical stores have already closed in the U.S. between January 1, 2017 and June 20, 2017, with thousands more projected to close by the end of the year. According to some reports, Amazon.com accounts for 43 percent of all U.S. retail sales and 53 percent of all U.S. eCommerce growth. Retail is being disrupted, primarily by digitally native retailers such as Amazon, Jet.com, Bonobos, Zalando and B2W.

Legacy retailers are well known for being technology laggards, with many sticking to packaged enterprise-level commerce platforms that were brought to market in the late 1990s. While these platforms were truly innovative for their time, they’re big, centralized monolithic platforms that are deployed and statically managed on-premises. Users of these platforms deploy once a month to production, if they’re lucky. These platforms are showing their age. Our profession has been revolutionized over the past 10 years through agile, DevOps, cloud, distributed computing, containers and more, and microservices are the natural endpoint of these innovations. Nobody building a commerce platform today would build anything resembling the platforms that most retailers are still using.

Digitally native retailers are running circles around these legacy retailers through their use of microservices. Amazon.com releases an estimated 50 million times per year to production, allowing them to iterate on new features over the course of hours rather than months. The ability to release quickly and iterate on innovations is what has allowed these digitally native retailers to out-compete their legacy peers. Innovation is a direct result of iteration.

What are Microservices?

Microservices are individual pieces of business functionality (e.g., prices, shopping cart, search, etc.) that are independently developed, deployed and managed by a small vertical team of people from different disciplines. Applied to commerce, a small vertical team builds and exposes a pricing API to the organization. Another team would do the same for promotions, and so on.

Four central characteristics of microservices include:

  1. Single purpose: Do one thing and do it well. Retailers could have a handful of microservices such as Gilt.com, or many hundreds such as Jet.com. The granularity doesn’t matter all that much. What matters is that each team is as decoupled as possible from other teams and has the ability to build and release independently.
  2. Encapsulation: Each microservice owns its own data. Interaction with the world is through well-defined APIs – no directly accessing a microservice’s database, storage or other functions.
  3. Ownership: A single team of two to 15 people (seven people, plus or minus two, is the standard) develop, deploy and manage a single microservice through its lifecycle. Members of the promotions microservice team will tell people at cocktail parties “I’m the lead developer for promotions at Company X,” not “I’m one of 200 Java developers at Company X and this week I happen to be working on promotions.” Ownership is a different mindset.
  4. Autonomy: Each team is able to build and deploy its own microservice at any time for any reason, without having to coordinate with anyone else. This ability extends to technology and architecture decisions. If a developer uses v.1 of some new obscure JavaScript framework – fine. But, that developer will be the one to wake up in the middle of the night to troubleshoot it when it doesn’t work.

The end state should be a large catalog of independently consumable APIs that power a retailer’s entire back-end, with some of those APIs being developed in-house, some being developed by system integrators, and some being consumed from SaaS vendors. Many retailers already use third-party APIs for ratings and reviews, recommendations, payments, taxes, fraud and more. That catalog can then be handed to a creative agency, system integrator or even an in-house team to build a UI for a new device. Traditionally, entirely new vertical tech stacks are set up for each UI.

The major advantage of microservices is speed. Each small vertical self-contained team has what it needs to release quickly. Developers never have to ticket another team (e.g. database, infrastructure, security, etc.). Outsourcing is also easier. Imagine handing off an API specification to a third-party system integrator and giving them the job of implementing the code behind it.

A secondary but equally important benefit of microservices is innovation. Innovation requires iteration. If a feature requires four iterations to perfect and is released four times a day to production, a feature could be perfected in a single day, in theory. If releasing once a month, that same feature will take four months to perfect. Time is money in today’s economy. Additionally, each team is able to develop competency solving a specific business problem. For example, search requires deep competency to do well. A small team responsible only for search can go very deep in that domain and quickly become experts in it.  

Since retailers all have existing commerce platforms that can’t be thrown out overnight, they can gradually surround the legacy monolith with smaller services until the monolith shrinks to the point where it can be entirely removed. Martin Fowler calls this the “Strangler Pattern.” To get started, retailers should come up with a big list of discrete areas of functionality that different touchpoints use. Then, they should evaluate each by:

  • How frequently does business demand that the function changes — would it benefit from having its own release cycle? For example, the store locator probably doesn’t change that much, but the product detail page probably changes at least weekly.
  • Would it benefit from elastic public cloud infrastructure? If Selena Gomez posts a product link to her 116 million followers, will the retailer’s infrastructure be able to support it? Different pieces have different scalability needs. Pulling products out as an endpoint, for example, could easily save 75 percent of hosting costs, as product detail pages are by far the most trafficked pages today.
  • What are its dependencies? For example, inventory is fairly easy to extract out into a standalone service fronted by an API, because it doesn’t depend on anything and nothing really depends on it. But search is a lot harder — the retailer’s search service will need to know about products, categories, customer segments, etc.
  • Start with something small. Extract coupons out into a separate service. Inventory is great. Pricing. Product images. Demonstrate quick wins. Show internally that the approach works. This shouldn’t be a problem, as retailers are already doing this today with other functions such as taxes and payments. It’s a natural evolution — just do more of it.

Legacy retailers such as Best Buy, Home Depot, and Macy’s have successfully thrown out their legacy monolithic commerce platforms and have fully and publicly embraced microservices as a key to their future success. Microservices architecture and supporting technology has matured to the point where even laggards can use it to truly transform their business.