Microservices for similar products

Question

We are a mid sized moving and shipping company that is transitioning our custom applications to microservices. Our business was originally based on shipping, but we found some niche areas in moving/relocation of employees and groups of employees (offices/companies). There were also a few acquisitions over the past decade. This leaves us with many domains, some of which are very similar across company offerings.

Company executives would like to merge many of these products to reduce redundancy and cost. On the surface the user interfaces can be designed to meet this need. Under the surface, both products have extremely unique back ends. Nobody wants a multiple year big bang release, we are all in agreement that we want incremental change.

So, starting with a microservice for CustomerProfile, the back ends are wildly unique. We are debating between two approaches.

• Create one common api gateway endpoint and let api gateway route traffic to two separate microservices to the correct product specific CustomerProfile microservice.
• Create one common api gateway with one microservice, but in that microservice there would be some feature flag implementation to direct the request to the correct "strategy" design pattern for the unique implementaion.

The first option is easier, but some of us are concerned that we will never merge these two separate microservies. The second one has some developers concerned that it would be too complex, but the advantage is that the implementation of feature flags will provide a baseline for future microservice implementations.

Thoughts?

-A

Answer 1

TL;DR: You can have both by applying the strangler pattern.

What you can do is to start out with a minimal product agnoistic service for CustomerProfile, with the only thing it does is to route traffic to CustomerProfileRelocations, CustomerProfileShipping etc. All it really would do in the beginning would decide for the right service to redirect to and map the request and response between different interfaces (you want consumers of the new service not to have to worry about different formats at all). This would be very simple, since all you need to do is to build one new service and only integrate it with the new UI. If you still have legacy services that are specific to a specific product, you don't mind if they still talk to the legacy services directly.

On the long term you want to move all new developments to use the new API and be (at least technically) able to use it for all products. If you add new capabilities to CustomerProfile for one or more products, you do it directly on the new CustomerProfile service and the only time you touch CustomerProfileRelocations and CustomerProfileShipping is for small bug fixes, or if you deprecate older functionality. Over time the product specific services will shrink and the common one will grow in functionality, but you will never have to do a big bang release.

This approach has been coined the strangler pattern