Micro-Workers: A flavor or Microservices?
There is another word call: service. This is where SOA come to play, there is lots of people talking BAD about SOA now a days, but they dont realize MSA is SOA. Service is not a web service, so that word has more meaningful than people imagine.
SOA is about principles, its about great foundations that enable Service Orientation. That`s is an Architecture but its also a way to think also called SO(Service Oriented). Microservices make a lot of sense if you are coming down from a monolith its very DDD like if you pay attention.
SOA is about Contracts
In SOA we abstract implementations and leverage contracts, microservice is the same idea, but to have different contracts you need to have different services with different business units and different purposes. Contracts are everything. They are like interfaces or traits, allow us to hide implementation details and be able to change technology under the hood. The service is an abstraction, there is not Service without abstractions. If you create severies that just expose tables is not a service is a web service(SOAP or REST/POX) and there is no business value on that. The REAL value is around having abstractions.
Microservices are about abstractions too
You still need to have abstractions with microservices the difference with SOA is that MSA whats a finer grained business instead a monolith with lots of things into the same service which makes lots and lots of sense. This make sense with DDD but remember DDD is Domain Driven, most likely for transaction systems.
There are other kinda of systems, business systems that are not Domain Driven by nature, they are what we call Data Driven, for this systems micro-services could be leaky definition.
Microservices is about small units but different services
You will have 3 different services with 3 different business implementations and most important 3 different contracts, this 3 different contracts is what made they different services. Someone could argue this is physiologically question. I would say no is not. Because it matters cause we shall do the contracts oriented to the consumers, Consumer Contract driven SOA, thats the right choise.
As Martin fowler said, smart and points and dumb pipes, like unix philosophy. And here ins this context this is very true.
This previous microservice picture makes lots of sense with REST and DDD because of the very nature of being domain driven, but in data driven systems what happens?
Data Driven, workers rise!
In systems or part of the systems that are Data centric or Data Driven, you wont gonna have different services, you will have the same service because your contract most likely will be generic but what will change will be the data and data implementation but for the consumers there is no advantage whatsoever call individual services. So if the service is the same, i mean same contract, but the processing unit changes, a.k.a the workers, should not be a microworkers? Because we dont have want and wont have different services but different workers instead. For that scenario you wont have many discoverability issues since you dont have many services but you might have lots and lots of workers.
People could still argue this is flavor of microservices, because the workers still would have the isolation properties of microservices. And each worker wont be a monolith. But again for SOA is the contract that matters not the implementation, them is slice different thing :-)
Cheers,
Diego Pacheco
