3 ms·
So I can just rename my "microservice" to "module" right? That is all the author seems to have done in my eyes, but then also thrown away the bits that make it
by supermatt 2y ago
So I can just rename my "microservice" to "module" right? That is all the author seems to have done in my eyes, but then also thrown away the bits that make it scale - for no less complexity.
First of, I am going to disagree with the microservices.io definition the author references, because it is short-sighted and ends up contradicting itself when talking about assemblage. Chris Richardsons book is definitely worth a read, but we clearly come from different worlds when it comes to a core belief of microservice architecture.
Too many people who complain about microservices are clearly unaware that a microservice doesnt mean remote, or distributed. It can have local transport - even a simple function call - which is the same as the "modular" approach the author dictates - but is also more flexible in that you CAN have remote transport with no additional effort because the service locator handles it for you.
Its just building your code in a modular way, with a defined interface between isolated components, a service locator (this is effectively an index of your modules (microservices) and where they are located - local, remote, etc) and some mechanism to call them based on the supported transports (thread local, RPC, whatever) of that "module".
It can all reside in a single repo. Your microservices can all be compiled in a single app, your service locator can be a switch statement, and your transport can be a function call. The only requirement is that they never perform a task that another microservice can handle - and if we were just talking programming, we would just call that "modularization" or using DRY principles! Microservice architecture is just non-monolithic DRY.
Anyone NOT writing microservices that way is just making life hard for themselves and probably hasn't read even the most archaic book on microservice architecture. Remove the remote transports, and you have a well built, domain driven monolith...