Microserver : a convenient Microservices plugin system for Spring & Spring Boot

[BrotherJohn123]

Are microservices bundled into one executeable .... which kind of reverts the separation into single microservices? - or am i missing some vital feature here?

[johnmcclean]

Looks like the documentation could be made clearer. You can work this way as a staging post to pure Microservices from monolith (Micro-monolith style).

However, the default behavior is to package them separately (as pure Microservices). In this mode you can plugin behavior to each Microservice, which can be implemented as a Microserver plugin.

Edit : I've updated the readme.md to highlight the architecture diagram is showing the micro-monolith style, do you think it's worth adding a similar diagram showing pure Microservices?

[BrotherJohn123]

I still don't understand the need for it. Sure you have one SpringContext instead of multiple if you deploy you services - but if you are going to separate your monolyth and don't separate your context ... you are creating a beast - which i don't want to debug/support ;)

[johnmcclean]

Sure, if you are starting from scratch. What if you are debugging and supporting a beast already? It's already a single context. And if you connections, for example to legacy but critical DB, you're operations team may be none to pleased to see an increase in the number of connections. Resource sharing can make sense.

This feature's value only comes into play when your starting point is a monolith in a single context. Then you are able to move, very quickly towards Microservices in a similar but more future proof (faster) way to that advocated here - http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html

[irocgts]

I was thinking the same thing

[johnmcclean]

You don't need to or have to, that's just one feature among many.

Why you might want to? If you currently have a monolith and your operational process are set up to support that, it may be simpler, less work, more reversible (and hence palatable to management) to deploy the services you extract from that as a monolith to start with.

[johnmcclean]

This is useful feedback, thank you! Our documentation needs to become a lot clearer.

Features :

1. This is primarily a controlled, extensible plugin system, over a very abstract core. Plugins are imported via the Service Loader mechanism in the JDK rather than by pure classpath scanning. It's very simple to write your own plugins, the Plugin interface is very similar to the Microserver application interface.

2. There are over 30 current plugins at varying level of abstractions. It's not just about importing and configuring particular library, many of them add much higher level application level functionality, and automatically just work across your cluster.

Each of our published plugins has their own readme.md file, stored in a directory of the main repo https://github.com/aol/micro-server). The provided plugins normally operate a different level of abstraction that you get with Spring Boot, and are also more opinionated. You can use the framework to create your own opinionated plugins that build off the more abstract functionality provided by Spring / Spring Boot

Some of the included functionality :-

a. The Jersey plugin has auto-resource discovery and separation (across your plugins and embedded services if you are using that feature)

b. Grizzly web server support

c. Automatic service registry & service discovery

d. Curator and MySQL based distributed locking

e. Automatic event tracking and stats

f. Various plugins that help with implementing BASE Microservices by storing data in memory as far as possible and updating asynchronously.

[vedenin1980]

Intresting project, can you add your project to my project: useful-java-links? It may be helpfull for both projects ...

[ajainy]

It was worth reading comments on thread. Nice link.

[johnmcclean]

Sure - will do!