Twenty years ago, monolithic systems were essentially the only choice for ecommerce websites. These all-in-one platforms provided a one-size-fits-all solution on which to launch a website.
However, today’s ecommerce brands need more than a one-size-fits-all approach. Increasing competition and rising customer expectations mean brands need to be fast and flexible. That’s why many ecommerce businesses are turning to another way of structuring their tech stacks: microservices.
Microservices can enable ecommerce businesses to adapt quickly and stay on the cutting edge of market demands. Read on to learn more about microservices, what they are, how they’re different from monolith models, how they’re related to headless commerce and more.
What are Microservices?
Microservices, or microservices architecture, is a method of developing software systems in which different single-function applications are coupled together; think of them like LEGO bricks stacking together to build a complete system.
Microservices get their name because each application operates as a small independent service. The advantage of this type of structuring is that each service can be scaled independently of any others without disrupting its neighbours. Because it is a distributed system, a microservices framework is highly scalable and can avoid the bottlenecks of a monolithic architecture (one in which all the components are unified in a single main system).
Traditional Digital Commerce
To illustrate why microservices are taking the reins after decades of dependency on monoliths, let’s go way back to the beginning of human history. Long before there was ecommerce or software or even money, there was simply mankind trying to get by on some good old-fashioned hunting and gathering.
Hunter-gatherer bands were self-sufficient, self-contained systems. Everyone knew everything and could decently do most tasks required for survival.
Even after the Agricultural Revolution, humans lived in small, intimate communities where they could still manage to get by with economies of barter and reciprocity. Then, life got a lot more complicated.
The rise of cities and improved transport brought new opportunities for specialisation. People could no longer know everything, so they started to master specific tasks, which was how shoemakers, potters, bakers, and doctors were born.
In many ways, we can see parallels in the evolution of microservices architecture from monoliths.
Until relatively recently, most ecommerce platforms were supported by monolith architectures. These are the original self-sufficient, self-hosted, jack-of-all-trades systems. They provide businesses a centralised, on-premise, feature-rich system to meet their needs. However, as a business gets more complex, these systems can often be slow and difficult to scale.
Microservice architecture offers a decentralised, decoupled approach. Instead of one solution that does everything, it separates different business requirements into different services which then communicate with each other.
This means even as the business and its needs grow more complex, microservices can offer speed and flexibility.
Just as early humans discovered they could get better resources and services if they traded (and later paid) for them from specialists, microservices offer businesses a chance to combine the best individual services to suit their business.
The result is an agile platform that can take care of all the business requirements but also quickly innovate with changing market demands.
Issues with Monolith Models
As explained above, two decades ago, monolith architectures were the only option for ecommerce businesses. Enterprises had no choice but to build on and constantly update and maintain these increasingly complicated structures.
In some ways, a monolith would seem to be simpler. All of the necessary components are contained in a single system. However, as time goes on, many brands have experienced challenges and issues with these all-in-one structures.
1. Customisations lead to complications.
Monolith platforms by definition work with a tightly-coupled front-end and back-end system. In order to update them to create personalisations or customisations, developers have to alter the underlying database code and the front-end platform. This can be very time-intensive. It can also make the system more and more complicated over time, especially with increased business capabilities and different development teams working on the system over the years.
2. Response to new market trends is slow.
Customers are expecting more and more from their ecommerce shopping experiences. Brands need to be nimble in order to quickly implement changes and meet new trends and expectations.
Because a monolith platform can be slower and more complicated to update, it can slow the DevOps cycle and make it harder for the brand to make swift updates.
3. High dependency leads to a single point of failure.
Monolith platforms are fragile. Because the parts are coupled together and dependent on each other, when one piece of the puzzle doesn’t fit, it can bring down the entire system.
4. Updates need a lot of testing before going live.
Because of the potential for a simple change bringing down the system, all updates need to be carefully tested. This requires more manpower and time to undergo all of the testing necessary to make sure nothing goes wrong.
Headless Commerce
One version of a microservices approach is headless commerce. Headless commerce entails decoupling the front-end presentation layer from the back-end ecommerce engine.
1. How headless commerce works.
The front-end or the ‘head’ of most ecommerce websites is the theme or template that controls what customers see. Headless allows for more flexibility in content delivery because you can connect a content management system (CMS) or digital experience platform (DXP) or Internet of Things device (IoT) that is specifically designed for creating content- or experience-led commerce. You can then swap out the front-end without affecting the back-end operations. Your chosen front-end communicates to the back-end ecommerce through simple API calls.
2. Headless meets rising customer expectations.
Customer expectations are rising. They want fast shipping options and unique personalised experiences. Headless and microservices can help address these expectations.
As Adam Grohs, the co-founder of the digital innovation agency Particular, writes: “The next generation of commerce platforms will wholeheartedly embrace microservices, headless and event-driven architecture as ecommerce for brands is no longer about a destination. Monetisable events and experiences will be more of the norm than an ecommerce website as a destination.”
Headless enables enterprises to be nimble and to innovate because they can make changes to their front-end faster without compromising essential ecommerce components like their checkout and security.
For more about headless commerce and the reasons brands are embracing it, check out this in depth article.
How Is Headless Different from Microservice Architecture?
With headless, some of the parts of the system are decoupled (the front-end from the back-end). However, a true microservices architecture allows the platform and service-oriented architecture to be fully decoupled.
With both decoupled and headless platforms, the content management application and content delivery application environments are separated. In a decoupled environment, however, the content is actively pushed into the delivery environment. A headless CMS, on the other hand, sits idly in a reactive state until a request is sent for content.
A headless CMS comprises content creation and editorial tools, and it has an API that is made available to third-party applications that publish its content. By contrast, a decoupled CMS is more proactive, as it has all the features of a headless CMS and also templating tools. It not only covers the preparation of content but also pushes it into a delivery environment.
Reasons for the Move to Microservices and Headless
Given the issues with a monolith system mentioned above, it’s no wonder that enterprise brands began to look for new solutions. To quickly respond to customers’ needs and market trends, a microservices architecture provides a flexible foundation.
Using loosely-coupled microservice components to create the complete system has a number of advantages for both developers and end users.
1. Heavy front-end traffic does not affect the back-end.
One distinct advantage of having a microservice architecture is that the front-end and back-end can be individually scaled. Developers can extend services where they are needed without needing the whole system to adjust. This means high traffic on the front-end won’t impact back-end operations.
2. Increased opportunities for customisation and personalisation.
With a headless system, you can have multiple front-ends that connect to one back-end system. This presents opportunities to implement multiple new touchpoints to the front-end.
3. Tech stack enables rapid implementation.
Because microservices or headless systems have a decentralised development process, it’s easier for developers from different teams to collaborate to adjust the code base and get to market faster.
4. Get only what you need.
A monolith is a feature-rich, all-in-one system, but you may end up paying for and working around features and functionality your business doesn’t require. With a microservices approach, each microservice serves a business function. You can add only what you actually will use to your system, creating a leaner and more efficient technology stack.
5. Get best-of-breed solutions.
Instead of relying on one system to try to do everything, you can pick and choose the services and service providers that will specialise in exactly what you need. Having a vendor-agnostic approach will allow you to really hone in on services that match your exact business needs.
BigCommerce allows for the flexibility of microservices, but at a more affordable price point.
Potential Disadvantages of Microservices vs. Headless Commerce
There are clearly a number of advantages to a microservices architecture, which explains why so many businesses are moving in that direction. However, what are some of the potential roadblocks and challenges you will need to take into consideration?
1. It will require organisational changes.
Switching to a microservices architecture doesn’t just require a change to how your ecommerce platform is organised. It can cause a change to your whole organisational structure. Managing the different microservices requires cross-functional, vertical teams who can work together to develop and maintain the site. Headless doesn’t necessarily require these same changes. You can usually keep many of your same systems and connect them to an ecommerce engine like BigCommerce.
2. It may require infrastructure changes.
Another potential consideration of switching to a microservice system is that it might change the infrastructure and tools you need to monitor the different microservices. Be aware of what changes will be required and factor those into your total cost of ownership. This again is why headless may be preferable, as you can get the advantages of flexibility with fewer changes to your existing systems.
3. Fully decoupled microservices can be costly.
Depending on your budget, the cost of a fully decoupled microservices system may be a deterrent. Tools like Elastic Path and commercetools offer fully decoupled microservices architecture, but they can also be incredibly expensive. This is one reason brands may consider a headless solution through BigCommerce as an alternative.
Businesses Choosing Headless Commerce Over Microservices
Here are a few businesses that are seeing the advantages of a headless, API-driven approach to their ecommerce.
1. Carluccio’s
Carluccio’s Italian restaurant and specialty food provider is another example of a business built using the BigCommerce for WordPress plugin to create a headless solution.
By building its presentation layer on WordPress, the company is able to create a consistent buyer journey from product page through checkout.
2. LARQ.
LARQ is a seller of self-purifying water bottles that were carefully engineered to solve many of the issues of traditional water bottles. LARQ needed an ecommerce platform that could not only scale with its growth but provide flexibility for customisation. The company also needed specific features like multi-currency because it was launching multiple international sites to expand its
A headless build provided the customisation that LARQ needed and gave the company complete control over its content and customer journey. LARQ’s sites are run with BigCommerce as the ecommerce engine on the backend and a custom solution built with React on the frontend. This enabled LARQ to control its regional sites (currently US, EU, UK and Canada) on one single domain.
Moving from a Monolith to Microservices Architecture or Headless Solution
There are a number of reasons you might want to move from a monolith to a microservices or headless architecture.
Perhaps you are finding limitations with your current system and making and testing changes is becoming too slow a process. You’d like a system that breaks your system into smaller, self-sufficient sections that are easier to test and deploy.
Unlike switching from one monolith to another, switching from a monolith to a microservices or headless platform can be done incrementally.
As Shane Baker, Digital Strategist and Brand Influencer Consultant at Shane Barker Consulting, explains: “It’s super easy to adopt a microservices approach because you can do it gradually. You don’t have to prepare for a big and instant change that could disrupt your operations. It’s very easy to scale the most crucial services and functions without the need to scale the whole application.”
With an incremental approach, you can first decide which capabilities to decouple and when to slowly separate your entire monolith into a system of microservices. You can start transitioning to your new platform while you’re still building out the rest of the parts.
Through a method known as the strangler pattern, you essentially break the monolith into single service components and replace them with microservices piece by piece.
Wrapping Up
Microservices, headless and distributed models are not the only solution, but for many businesses they can provide the extra flexibility they need to be successful.
Modular approaches through microservices architecture reflect the larger — and growing — need to create a powerful and changeable customer experience across channels. Consider your business needs and if having a headless or microservices model might better help you achieve your goals.