Blog

Headless digital commerce is growing in popularity because it enables companies to integrate commerce capabilities into custom front-end solutions. But as the number of channels for a commerce interaction grows, companies are finding that they may need something even more decoupled and granular. That’s where micro-services come in.

The evolution of commerce software

As a quick trip back through time – e-commerce started with the website, and it’s still a primary place for many to go to buy products and services, although retailers report increasing preference for accessing these via mobile platforms. Way back when (or maybe just last month, who knows), a brand would buy e-commerce software and build their product website on it. It was an all-in-one kind thing. In addition to pure commerce platforms, we also saw many digital experience platforms (Web CMS plus) add built-in commerce capabilities. But again, these provide website commerce as the primary channel.

As time went on, other channels started appearing that provide prime opportunities to sell to consumers like mobile apps and social media, and traditional e-commerce software and DXP solutions struggled to support these new experiences without the need to duplicate efforts.

Now we have even more channels from which we can sell products and services, including chatbots, more social networks, VR, IoT, kiosks, even those cool Magic Mirrors. And the idea today is that anywhere you can meet your customers, you should be providing the ability to purchase your product.

Which is where headless commerce solutions come in. Headless commerce is essentially what it says; it’s the backend commerce engine without the front-end website very much like headless content management. The front-end experience is decoupled from the backend, enabling a brand to connect its commerce engine to any front-end they want.

If only it were really that simple.

The difference between headless and micro-services is subtle, but important.

When we talk about headless commerce today, there are two things we can talk about: headless and micro-services. Interestingly, you often hear the two terms used interchangeably, but it’s not always the case.

Headless commerce means you provide an API that calls your commerce engine capabilities. In many cases, it’s an all in one kind of deal with one API providing the product catalog, shopping cart, account information, and more. So you take everything, whether you need it or not.

Of course, not all headless commerce solutions are the same. Some commerce software vendors added headless as an option but aren’t architected for true headless. Others provide different levels of functionality, which makes it important that you understand how a headless vendor’s API works.

Along with headless commerce, there’s now a lot of discussion around commerce micro-services. A micro-services architecture is also headless, but it breaks the headless API into a number of distinct services, each available via its own API. You then mix and match the services to get the functionality you need. The benefit of micro-services is flexibility and performance. Because each key function exists as a microservice, you can make changes to it and add new functionality without affecting other functions. The disadvantage is that it can make development and management much more complex, often too complex for the value it provides.

What’s great about headless commerce is that you can carry the customer’s shopping experience across channels, enabling a consumer to start their shopping on one channel and finish it on another. It also means you track what a customer looks at or buys in one place and use that information to personalize the next experience for that consumer.

The path forward for one digital commerce vendor

ElasticPath is a digital commerce vendor specializing in headless commerce (a few others include BigCommerce, Shopify, Mobify, and Commercetools). ElasticPath also provides an orchestration API called Cortex that supports a micro-services approach. It recently acquired another commerce vendor out of Boston called Moltin, and a key part of the acquisition was Moltin’s micro-services capabilities.

According to Harry Chemko, co-founder and CEO of Elastic Path, the acquisition is driven by synergy:

On the technology side, the acquisition brings things like multi-tenant SaaS micro-services, intuitive business user tooling, and new ready-to-use commerce experiences. These functionalities help Elastic Path customers innovate at scale and deploy new commerce experiences quickly and easily.

This begs two  important points. The first is that Moltin brings to the table example and reference applications that help developers put together the micro-services they need more quickly get a commerce experience up and running. Snapping these tools into the ElasticPath Commerce Cloud should improve the onboarding process. Jamus Driscoll said in a post discussing Moltin’s decision,

Combining forces brings API orchestration together with the flexibility of a micro-services architecture to help customers more quickly and easily deliver unique and differentiating commerce experiences.

The other point is that together, ElasticPath and Moltin now offer a wide range of ready-to-use commerce experiences including a progressive web application (PWA), Alexa Voice Assistant, Facebook chatbot, social login, self-checkout for retail stores, Zendesk customer service, magic mirror, self-checkout for pop-up events, embeddable cart and checkout buy button, and more.

My take

Micro-services have been a big topic in many areas of software development, but much of that conversation has been about how difficult they are to design, implement, and manage. Micro-services are supposed to help build better applications. The question then becomes, do they provide enough added value to make up for the complexity of using them?

For many organizations delivering commerce experiences, the answer is likely no. Headless solutions should be good enough. But if there are solutions that leverage a microservice architecture that hides the complexities from the organization, then they are worth examining.

Understanding how a commerce solution architecture will change how the organization operates and what new levels of support and management are necessary must be weighed against the improvements to commerce experiences, including the number of new channels they can support and how seamless those experiences are.