Value of Ecommerce Microservices Architecture

Microservices have been a hot topic for a long while, with many success stories demonstrating the potential benefits of the approach. In this post, we will talk about the nuances of the microservices architecture in the context of SaaS commerce.

We all know how digital-first companies, including Netflix and Amazon, have pioneered microservices. They were able to achieve superior business agility to develop, test, and release features into production daily. These are genuinely great success stories, but there is a caveat. Those companies did not buy/consume microservices but have built them. They have organized their departments in small independent teams, have created their solution leveraging microservices-based architecture, and have set up the necessary CI/CT/D processes. They fully own the source code and the roadmap for their internal products.

When it comes to SaaS products, be it marketing automation, commerce, or CRM, most of the time, the customer won’t have access to the source code. They will either consume the application via APIs or use the application user interface. Some of the applications can be deployed in a private cloud or on-premises, but this doesn’t automatically mean access to the source code. As a result, the architecture is hidden from the customer, and they can’t leverage the CI/CT/CD practices to make changes to the service source code.

So, does it mean that microservices-based architecture has no value for the customer?

The answer is “NO”. While the architecture of a particular commerce service does impact customer, who is consuming the solution via APIs or user interface, they still will enjoy the indirect benefits provided by the microservices:

• Operational Costs. If the service architecture is adequately designed, all the microservices can be scaled independently. The value of this approach is since some of the entities, for example, the catalog can remain of the same size irrespectively of the transaction volume. At the same time, the cart service will scale accordingly. This allows optimizing infrastructure costs of the commerce service. While the SaaS vendor usually pays the infrastructure costs, the customer will still benefit from this aspect since the vendor will be able to provide service at a lower price.
• Composability. One of the drawbacks of the monolith solutions is that it might be hard to replace a single piece of functionality with a 3rd party service. For example, it can be extremely costly to integrate with a 3rd party Product Information Management or Order Management, because all other components in the solution (including their data model and processes) are tied to the embedded functionality. With each microservice being independent, it is possible to replace any of them with a home-grown or a 3rd party service. Customers can leverage this to create a best-of-breed solution picking the best-in-class functionality instead of being limited to what is available in the best-of-suite approach.
• High Availability. Fault isolation is another benefit of an ecommerce microservices architecture. While it may result in some compilations in the testing process for the vendor, it allows for higher solution availability. If one of the microservices is down, the other microservices should still be able to operate. So any use-cases not dependent on the faulty microservice should be executed accordingly.
• Seamless Upgrades. Since each microservices can be changed independently, there is no technical need to package new features, patches, updates, and upgrades into more significant releases for rollout. Customers can get access to the new code as soon as it is released and is pushed into production. On the flip side, the vendor needs to make sure that all the updates are backward compatible, or this may result in undesirable consequences such as broken integrations.

An important thing to mention is that while the microservices architecture of a SaaS service provides tangible benefits for the customers, it does not guarantee technical agility. There are a couple of reasons for this:

• The speed to market depends a lot based on the internal setup of processes and teams within the organization. To be able to deliver new experiences quickly, the organization should operate in an agile manner, including small independent teams, decentralized decision making, and all necessary tools.
• On top of leveraging microservices-based architecture, commerce service needs to provide developer teams with the necessary tools to iterate quickly. These tools include intuitive and well-designed APIs which are easy to use, comprehensive extensions model, and easy-to-navigate documentation.

Learn more about how Elastic Path Commerce Cloud microservices-based architecture enables superior technical agility.