Potentially move away from the pluggable model

[asim]

An existing audience of users have come to rely on Micro as a pluggable model, one that predominantly through Go Micro promoted the ability to plugin any infrastructure for any underlying abstraction. Go Micro has now been archived and is no longer the mode of use here and with that I'm rethinking the pluggable model. Being pluggable enables ability to drop into many ecosystems but it also comes with a lot of edge cases and problems. Having to build generic abstractions is incredibly difficult. In fact the one size fits all doesn't work for everything and we find that the opinions are so very opinionated that it doesn't scale.

I think Micro should stop being pluggable. Micro itself should support state via built-in persistence, it should support clustering via built-in gossip, it should be a drop-in system that does not require external dependencies. And for anything beyond Micro, we attempt to get out of the way. We do not try to solve every problem, but instead solve a subset of development problems that are at the heart of microservices development.

This will not play well with an existing audience, but I think it's time to let go of the past, 6 years is long enough to see that things that scale are narrowly focused as opposed to everything to everyone, and we need to stop trying to be everything to everyone.

[camba1]

I think having the team create something that will work for any type of solution to plugin into Micro is probably not the best use of their time at this stage. But, I also believe that giving people choice is something that attracts more people to the platform. As such, I think it would be good if Micro had a 'standard' functionality and at least one more option. So for example, one could choose to use the default pub/sub client or you could choose to use seamlessly switch RabbitMQ instead (Just using RabbitMQ as an example here).

[lambdaR]

I think Micro should stop being pluggable

totally agree, the more generic micro becomes the harder it gets to implements new things.

Micro itself should support state via built-in persistence

yes , and maybe also a state management like in font-end frameworks Vue, React and Angular where you can save data in-memory that are accessible to all services like sessions, metrics, performance counters and any metadata that are not sensitive in case of failure.

it should support clustering via built-in gossip

i think you need to add Raft also to solve the consensus problem, unless you want master-to-master model

[itzmanish]

Agree with @asim upto an extent.

We do not try to solve every problem, but instead solve a subset of development problems that are at the heart of microservices development.

Very true and no one should but one truth is that nobody wants to develop microservices if one can not deploy it well in production. Every company have different setup.

Micro is not just something to only play with. It is very powerful tool and believe me I feel it (I am talking about go-micro here).

Having to build generic abstractions is incredibly difficult.

Yes it is. But please try to build at least one or two alternative plugin for every service like go-micro have.