Can your eCommerce platform keep up with current demands?
Your commerce platform is very likely struggling to keep up with today's demands. Features that came out of the box with your big monolithic system have now become obsolete (who still uses the famous 'poll-module' in their Magento store?), while new features are constantly added, for example the capability to sell your products via a marketplace. As a result, these applications become more and more complex, to a point where even your developers are losing track. For example, if they fix something on the shopping cart system, it could break something else, causing delays in the introduction of new features that would have brought you on par with your competition.
This lack of agility is at least partly due to the fact that, with monolithic commerce solutions, teams are typically structured according to their individual functions (back-end, database, front-end etc.). A request that affects all of these teams can result in huge delays because tasks have to be shared with a lot of different team members. For example, let's assume you want to register date of birth in the checkout (in a fully GDPR compliant way, of course!). This is what typically happens:
- Java girl receives your requirement
- Java girl must use DBA's ticketing system to file a ticket
- DBA team receives work order, prioritises it, and assigns it
- DBA dude adds column to database per work order
- DBA dude updates ticket, requesting that the Java developer view that it was added correctly
- Java girl logs into database and hopefully finds that it was added correctly
- Java girl updates ticket, stating that the column was added correctly and that the change can be promoted
- Java girl waits for next database build
- Java girl updates the registration API to include birthdate
- Only now can the front-end guy add the field to the checkout template
As a result, rolling out new features or entering new markets takes too long and leads to missed business opportunities.
Another disadvantage of monolithic systems (for the sake of a balanced story; there are advantages too, for example easier deployment) is that because of their centralised architecture, the individual pieces are tightly coupled and, thus, very much dependent on each other. And, over time, when the number of code changes grow, the number of dependencies grow too, and, as a result, more and more potential single points of failure are created. This puts more stress on testing; even after a small code change, the entire system needs to be tested.
The last but - in a rapidly growing market - not least issue with monolithic systems is scaling, because you can only horizontal scale the whole application. But what is you see calls to an inventory service spiking? In this case, you'd want to scale just this service without wasting resources on scaling other parts of the application with less traffic.
ecommerce platform on life support? microservices to the rescue!
So, how do the likes of Amazon, Uber and Netflix keep up with rapid changes in consumer behaviour, reducing time to market and scaling where scale is needed? They have broken up their entire monolithic system in microservices; each business capability is encapsulated into individual services that interact with each other via APIs.
Picture the Amazon product detail page: functions like reviews, recommendations, pricing, inventory, cart; they all represent individual microservices. These microservices are maintained by small, self-steering teams. These teams have a high degree of independency when it comes to selecting the technology stack. For example, one microservice might be better off by using a traditional RDMS like Oracle, while another microservice will use its own MongoDB NoSQL database. Modern cloud providers like Amazon and Azure conveniently serve you with just enough Oracle and Mongo to suit your needs, and vertically scale your microservices with demand.
The teams behind a microservice own it end-to-end: not just the development but also the deployment and operations side. This DevOps approach - or, in Amazon-speak: "you build it, you run it" - will increase commitment and ownership. Imagine being called to the rescue in the middle of the night a couple of times because of a bug in your code... That will indeed incentivise your focus on quality code! Moreover, the reduced dependency on other resources will enable microservice teams to release new code to production more often; ramping up from a typical quarterly release in a monolith to multiple releases a day. How is that for improved time-to-market?!
Despite all the advantages, microservices are no silver bullet. They do not reduce the complexity of a system as a whole, but they will break up complexity in smaller, easier to maintain modules. Also, the orchestration of microservices and the different teams behind it will impose some challenges.
should it stay or should it go?
So, should you dump your current monolithic platform today and run to one of the new kids on the block, like commercetools who have fully embraced this API-driven microservices architecture?
While most of us would love to start with a greenfield situation, completely abandoning your legacy system, this is not always the most realistic approach. Maybe you just want to start with a replacement of your cart service or integrate a configure-price-quote module. That is why all major commerce platform providers are transforming their architecture from a monolithic structure to a more API/microservices based architecture, allowing for a more gradual approach. For instance, SAP Hybris is rolling out its YaaS microservices ecosystem; Magento has introduced the modular Service Contract concept in version 2; and Intershop is now jumping on microservices too. So, unless your entire commerce platform is up for replacement, you might as well follow your current platform vendor in a gradual approach to microservices.