Microservices extensions/plugins architecture

Question

We are building a platform based on microservices. The platform will provide a number of basic functions that will be used in various independent projects. We need to come up with such an architecture that will allow us to extend the basic functionality and interact with existing services. The main task is to ensure that the code of the main services remains unchanged, and custom solutions based on the platform can be easily reused.

We are considering several options. For example, there is a certain service "foo" which provides the functions foo1 and foo2. To extend the functions, we can create an independent "foobar" service and put it in front of the foo service, accept API requests, execute custom functions, and then redirect the request to foo. It turns out a kind of intermediary service, which acts as the main link in the implementation of the functions specific to a given project and the main platform. The advantage of this approach can be attributed to complete independence from the code base of basic services. And the main disadvantage is the complexity of implementation and the need to greatly fragment the functions of the main service.

The second option under consideration is similar to the approach that is often used in monolithic applications - the hook system, which allows you to override the behavior of the system. For example, you can create an independent service that will connect events and subscribers. This approach is more flexible, but at the same time it is still quite difficult to implement. The main disadvantage of this approach is synchronous blocking network calls.

The third option that we are considering is the construction of the microservices themselves in such a way that additional modules can be added to them so that services can be customized at the build stage. The main code remains unchanged, but inside the process, the already mentioned scheme of hooks and events is implemented (at the code level of individual services). Benefit is ease of implementation. Of the cons, it is very difficult to implement customizations in the case multiple services are involved.

Perhaps we are trying to invent a bicycle and there are exist good solution(s) for the problem. If you know such, or you have a good idea about possible ways to solve this problem, please share.

Midtown

Answer 1

I don't think there is an answer to this generic problem. The third solution seems pretty good. You might take advantage of chain-of-responsabilities or request-response pipelines paradigm to implement the open/closed principle pretty easily. This should ensure that you can add/modify features into your foo service without touching the existing code.

If you are looking for something to tackle to whole architecture rather than a single microservice, you might want to give a look at the Event-Driven microservices design.

This design approach is similar to your option 2, with the difference that it uses a message broker and async communication to let the microservices communicate. There are a lot of advantages, like more resiliency and decoupling of the services.

Cholecystotomy

I would like to add that one of the most important aspects in designing is defining responsibilities. If you successfully isolate business logic from application logic, then many microservices become generic in their own, without the need for complex customization. A small example: earlier we used a fairly large authorization service, after refactoring, instead of this service, we use several independent services. Schematically 1. Able to issue JWT; 2. Contains information about users; 3. Refers to 1 and 2 in order to authorize a specific user; 4. Able to check JWT in incoming requests. – Midtown