Ecommerce Microservices: The Good, the Bad and the Ugly

This post was originally published on October 21, 2018 and has been updated for accuracy and relevancy in the market.

Hardly a day goes by without an article about eCommerce microservices.

Microservices are small services that are loosely coupled, independently deployed and are organized around business capabilities that enable the rapid, frequent and reliable delivery of large complex applications. Though they were established a decade ago, Microservices still remains as a hot new paradigm for commerce back end among many commerce practitioners. While many developers are experimenting with microservices and others are embracing them head on, others have continued to shy away from them because of the perceived complexity and risk.Over the next upcoming years however, we do expect many more practitioners to get on the microservices bandwagon as concepts like Composable Commerce continue to democratize working with Microservices architectures. In the meantime, we want to continue to educate the market on what to expect when adopting a Microservices Architecture. Therefore in this article we will quickly highlight the good, the bad and the ugly about ecommerce microservices everyone should know about.

The Good: Microservices offer unparalleled flexibility and modularity when it comes to standing up a new customer experience and rapidly adding additional ones. Microservices share nothing: platform, deployment and data storage are all independent. If a developer needs to make a new microservice and s/he works in Javascript, they can just do it in Javascript. They don’t need to learn a new language in order to keep growing the platform. Developers can work in parallel and release all day long, which significantly reduces time to market for any new application.

This is the complete opposite of a full-stack monolithic suite where the majority of functionality lives in a single service that is tested, deployed, and scaled as a single unit. It requires integration phases of the project, quality assurance, etc. to make sure the platform works as one unit because it shares everything. Expanding it into other touchpoints and devices requires a significant amount of customization, making it cost-prohibitive to explore new ideas.

The Bad: When companies are moving from a monolith to a microservices eCommerce solution it can be very difficult depending on the process that is taken. Imagine, you have already invested in a monolithic pattern that you have established through your company. You would have already had your licenses from institutions like Oracle, and have your infrastructure and organisational inertia to continue business as usual. Then, if you choose to replatform your solution that was not built from ground up with APIs and microservices based, you could incur quite a bit of problems.

You may end up having to lay off or retrain workers; have duplicative data and connections; lose control of the database and overall are left with a distributed monolith to handle the cross-functional concerns.

However, if you end up choosing an API-first, Microservices-based commerce solution like Elastic Path, then it becomes a lot easier. Of course, microservices will require a higher digitally mature team, but teams are able to incrementally replace their monolithic system that makes the management, retraining and implementation of your new solution more seamless.

The Ugly: The real downside of microservices is the complexity the mini-services introduce into the architecture. Developers end up needing a microservice to search for a microservice. The more microservices are being used, the more there is a risk of things getting out of control. In her post, Goodbye Microservices: From 100s of problem children to 1 superstar, Alexandra Noonan of Segment described the pain developers went through with the explosion of the microservices and what they did to end it. Another great story, What I Wish I Had Known Before Scaling Uber to 1000 Services, is from Matt Raney, Chief Systems Architect of Uber. You end up breaking the services into so many pieces that you no longer know what is going on. You can’t bring change because every time you make a tiny change and you think it is independent, it actually turns out not to be. To make matters worse, you may run into a problem where you may not know how a particular service exists. You couldn’t rebuild it if it died. You don’t know how to make changes to it because the person who made it is gone. You end up in a pretty big mess.

One way we have begun to address these issues is with the Packaged Business Capabilities(PBC’s) with Composable Commerce. Many may think PBCs and Microservices are the same, but not really. All Microservices are PBCs but not all PBCs are microservices. The key difference is business capability, and the acid test is whether a microservice is designed to deliver a well-defined business capability, recognized as such by business users. By packaging these microservices to specifically satisfy business needs, users will experience reduced complexity, enhanced clarity, and business centric planning. Learn more about how they are beneficial to your business here.

To sum up: Great News! Defining the structure of the data required to perform the service is key. Exactly the same structure of the data is returned from the server, therefore preventing excessively large amounts of data from being returned.

After all, if you set things up the proper way and learn from the mistakes the pioneers have made, you are on your way to success!