Is there an architecture pattern for “microservice as a plugin”?

Question

Long story short - I would like to make a web application, solely for self-education purposes, that should allow user to add additional functionalities via plugins - just like Jenkins - https://jenkins.io/doc/book/managing/plugins/ - which does it via extension points.

But beside that, at the same time I would like each of the plugin itself to be a self sustainable process on an arbitrary host, arbitrary technology stack, to be scalable and not be able to affect host with core systems anyhow, which already feels more like a microservice.

The main points to me are:

• Plugins to be add/removed on fly via web UI;

• Plugins to sit arbitrary on the same host as core, or any other
  host;

• Plugins to be scalable both on I/O and performance;

• Plugins to be written with arbitrary technology and only required to follow some basic contract to expose its functionality and available settings/controls to the core.

My brain was capable to produce only such a simple idea https://svgshare.com/s/FSo

So in the end of the day I have a feeling like I am trying to reinvent the wheel here, and there are ready solutions either in plugins or microservices architectures that cover these requirements - are there any really?

Answer 1

There seem to be an incompatibility between the two concepts:

• Microservices are by design meant to be independently deployable services that remain loosely coupled.

• Plugins are meant to extend something existing, which means that the plugin has no value on its own.

But you may be interestted in client-side discovery pattern, which suits your flexibility needs with a microservice-oriented mind. You may use it :

• with a classical plugin architecture: you create plugins able to find a suitable microservice and use its functionality for the extended the basic service.
• by designing your wholde app as microservices which dynamically find other microservices.

Answer 2

I don't know what you are talking about already exists. But I feel that it is not something unusual. It sounds like something that is "ideal state" of (micro)service-oriented architecture. The original "dream" of (micro)service-oriented architecture was basically what you are describing. "simply" add new service and it automatically and seamlessly integrates with already existing services.

Designing architecture where new service "hooks up" with rest of the services and the core should be relatively simple. New service can either broadcast it's presence for everyone, so that they can setup connection with it. Or it can contact some central broker and discover services it needs or can use.

The tough part is designing API between the core and the plugins that actually allows the kind of extensibility you are envisioning. The API would need to have really good design to allow for future extensibility of features you haven't though of beforehand. You shouldn't really get into situation where you need to change the API for each plugin you add.

Another problem is debugging the system as a whole. You would need lots of monitoring and instrumentation to figure out unexpected emergent behavior between different services.

Answer 3

Long story short - I would like to make a web application, solely for self-education purposes, that should allow user to add additional functionalities via plugins - just like Jenkins - https://jenkins.io/doc/book/managing/plugins/ - which does it via extension points.

You may do this by providing Webhooks for your users to send / receive messages. An example of this is in Shopify

You can set up common events in your education application which you think will be useful for third-party services to listen / react to. Then, these events are subscribed when your user registers a webhook on your platform. Subsequently, when these events are triggered, they will call your user's third-party service.

The deployment topology (hosting, technology, orchestration, etc.) should be completely agnostic to you as it will be just a HTTP endpoint from your platform's perspective.

Note: you still need to take care of security and don't allow your user's services to take down your infrastructure.