Ecommerce Microservices: The Good, the Bad and the Ugly
As previously published on LinkedIn, Ana Milevskaja outlines the facts about microservices that commerce pros should know about.
Hardly a day goes by without an article about ecommerce microservices. Microservices is a hot new paradigm for commerce back end among many commerce practitioners. Many developers are experimenting with microservices and others are embracing them head on. Many more practitioners out there will get on the microservices bandwagon in the near future. Here is 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 microservices ecommerce platform as an organization, it is really hard. You have invested in a monolithic pattern. You got your Oracle licenses, you got infrastructure and organizational inertia to keep doing things the way you have always done them. You have to tell people that bless the release that they no longer have a job or they have to retrain. You have to tell engineers they have to build their own build pipelines, figure out their own data storage. It becomes a big lift on the existing organization to make this change.
You may end up using existing database, because why not, you already have it. Microservices take concept of DRY (“Don’t repeat yourself”) that is typical of a monolithic development and throws it out the window. You end up with connections that don’t need to be there and when you need to release a microservice, you need to negotiate with the teams. What makes it harder is that you don’t know where those teams are all the time. You don’t control the database. You now need to have a white board to tell you about the teams using the same database or using the same shared library. You end up with the distributed monolith to handle the cross-functional concerns.
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 by 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 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.
GDPR compliance is another issue. If personal data is distributed among multiple services, how do you delete someone from the multiple databases and report on compliance?
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!
View original content: Here
Related Elastic Path News: