Microservices in e-commerce

Whereas in the past, online retail was limited to PCs and netbooks as touchpoints, customers today and in the future expect to be able to shop from anywhere and from any device. In order to achieve this goal, store applications need to map more and more use cases. If all these requirements are implemented in a single monolithic application, far-reaching problems will arise in the coming years. The costs for scaling, maintenance and feature implementation will increase.

This raises the question of whether microservices are an advantage as a supplement to a monolithic application.

The biggest difference to the classic approach of a monolithic application, where the individual components are only separated from each other in the source code and form one large application after deployment, is that the micro-service approach divides the individual components into many applications - microservices. This means that each microservice has its own runtime environment and can be deployed independently. As the name suggests, a microservice should be kept as small and manageable as possible. Due to the fact that microservices are operated as independent applications, communication is a key issue in the development of macro architecture. REST is often used for communication.

A classic solution - which comes to mind first - is probably the connection of a payment service provider. Like Wirecard, for example. However, other third-party systems often also need to be connected. Particularly in the cross-channel area, a store system interacts with a wide variety of services and platforms. For example, Newsletter tools, display advertising platforms, merchandise management systems and many more. For such use cases Shopware a REST Api is available.

One of the most common scenarios is the import of data. The import usually involves a transformation of the given data structure. Take, for example, the import of product data from a merchandise management system - WMS for short - such as openZ or Pickware. Although the ERP system provides the product data and product images for the import, the various product categories to which the product to be imported should be assigned are missing. This problem can now be solved in a variety of ways. We enter the missing data after the import via Shopware Backend , which is potentially the cheapest solution for smaller amounts of data. But what to do if thousands and thousands of product data have to be imported into the store system? One solution is to automate this process with a micro-service.

Two approaches have emerged for the development of a microservice: Code-first and contract-first development. This means that with the latter approach, the interface of the microservice is defined before the actual service is implemented.

According to the contract-first approach, the API interface is defined via www.editor.swagger.io. The swagger.json file shows an example definition for the Categoryfinder microservice. A product with title and description can be transferred via a POST request and then receives the appropriate categories. The interface description can now be used to create server stubs for the future microservice. These are then directly available in continuous integration pipelines for automated testing. As already mentioned, this is followed by the actual implementation of the business logic. A tensorflow model trained by machine learning is suitable for classifying the products. In simplified terms, the tensorflow model provides a value for each category that indicates how likely the product belongs to this category. For all categories that have a high value, the micro-service then returns the corresponding ID and the name of the category - as defined in the previously created contract - as a response. And thus completes the missing product information.

Thanks to independent deployment and the free choice of technology, micro-services offer good conditions for continuously providing customers with new features. Not only in a micro-service architecture. But also as a supplement to existing and new monolith applications. The contract-first approach is a good method for developing and providing microservices, whereby the tolerant reader pattern should be observed. This means that only the fields and exceptions that are actually required for the use case are defined or processed. The internal division of the micro-service into structure and behavior - instead of according to domain-driven design - also contributes to simplification and clarity.