4

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?

lGSMl
  • 43
  • 1
  • 3
  • 1
    Sounds like a microservices architecture built using containers, with the ability to add/remove containers on the fly. – Dan Wilson Oct 10 '19 at 17:58
  • We can put it this way as well, though there should also be some kind of "extension points" from a core service, so it knows what new functionality is available with added container. Or any other way to communicate that. – lGSMl Oct 10 '19 at 18:04
  • In Jenkins, the user (admin) is who adds plugins and usually, it takes to restart the application. That's different than services **subscribing** to another remote service without causing interrumption. For such a thing we have the pattern Discovery Service (products like Consul, Eureka, Zookeeper, etc, implement it). If we were speaking only of Java, I would suggest CORBA. The question is What protocol or communication channel do you want to rely on? – Laiv Oct 11 '19 at 12:48
  • Actually I was thinking more about regular REST rather than CORBA, so there as much decoupling as possible between services, and just enough contracts to keep core<>plugin relation, nothing above that – lGSMl Oct 11 '19 at 13:21

3 Answers3

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.
Christophe
  • 74,672
  • 10
  • 115
  • 187
  • thank you for the reference, this is indeed looks like something I am looking for. In my case I suppose I will just extend the service registry to also validate if registered service honors the contract between client and plugins, or will make an additional service alongside with registry to do it. – lGSMl Oct 11 '19 at 12:01
  • @lGSMl This sounds to be a sound architectural orientation indeed. The contract verification could be integrated into the registry if it’s not too complex, alternatively you could put it in a separate microservice (if it’s complex and general). Not sure, but Perhaps you could even see the contract verification as an additional responsibility — a kind of trial drive — for the consuming services (if it’s a very specific verification, and if it’s feasible). – Christophe Oct 11 '19 at 12:12
1

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.

Euphoric
  • 36,735
  • 6
  • 78
  • 110
  • just to clarify the part regarding the API - you are referring to the classic API change problems when in order to modify API you either need to make sure all clients are updated as well or keeping compatibility with annoying versioning like v1, v2, etc? – lGSMl Oct 11 '19 at 12:04
  • @IGSMI No, while those are also problems. The thing I mean is that API should be generic enough and should provide endpoints with enough information or should be able to process broad enough input data. So that when new, never-before-assumed plugin is developed, the API doesn't need to change. It is super-difficult to design such API for in-process plugins. It is going to be a nightmare to do that with out-of-process plugins. – Euphoric Oct 11 '19 at 12:23
  • ok, now I see what do you mean - so e.g. if we would need a new plugin that will add new page in core service, and we never expected such a functionality available from plugins, there is a chance API will have to be reworked in order to allow such an extension. Yep, looks like it has to be super generic initially, thanks! – lGSMl Oct 11 '19 at 12:55
0

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.

unclelim12
  • 325
  • 1
  • 6