In part 3 we saw, that in order to ensure a higher degree of autonomy for our services, we need to avoid(synchronous) 2 way communication (RPC/REST/etc.) between services and instead use 1 way communication.
A higher level of autonomy goes hand in hand with a lower degree of coupling. The less coupling we have, the less we need to bother with contract and data versioning.
We also increase our services stability – failure in other services doesn’t directly affect our services ability to respond to stimuli.
But how can we get any work done, if we only use 1 way communication? How can we get any data back from other services this way?
Short answer is you can’t, but with welldefined Service Boundaries you (in most cases) shouldn’t need to call other services directly from your service to get data back.
What is a service boundary?
It’s basically a word that’s used to define the business data and functionality that a Service is responsible for. In SOA: synchronous communication, data ownership and coupling we covered Service principles such as Boundaries and Autonomy in detail.
Boundaries determine what’s inside and outside of a Service. In part 2 we used the aggregate pattern to analyse which data belonged inside the Legal Entity service.
In the case of the Legal Entity service we realised that the association between Legal Entity and Addresses belonged together because LegalEntity and its associated Addresses were created, changed and deleted together. By replacing two services with one we gained full autonomy for the Legal Entity service whereby we could avoid the need for orchestration and handling all the error scenarios that can result of orchestrating data mutating calls between services (LegalEntity service and Address service).
In the case of the Legal Entity the issue of coupling was easily solved, but what happens when you have a more complex set of data and relationships between these data? We could just pile all of that data into one service and thereby avoid the problem of having data mutations across processing boundaries (i.e. different services that are hosted in other OS processes or on different physical servers). The issue with this approach is that this quickly brings us into monolith territory. There’s n0thing per se wrong with monoliths. Monoliths can be build using many the same design principles described here, e.g. as modules instead of as microservices, which are bundled together and deployed as a single unit – where as microservices often are deployedindividually (that’s at least one of the major qualities that people talk about in relation to microservices). Continue reading “Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 4”→
In Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 2, we again discussed the problems with using (synchronous) 2 way communication between distributed (micro) services. We discussed how the couplingproblems caused by 2 way communication combined with micro services actually result in the reinvention of distributed objects. We also discussed how the combination of 2 way communication and the lack of reliable messaging and transactions cause complex compensation logic in the event of a failure.
After a refresher of the 8 fallacies of distributed computing, we examined an alternative to the 2 way communications between services. We applied Pat Hellands “Life Beyond Distributed Transactions ? – An Apostate ‘s Opinion” (PDF format) which takes the position that Distributed transactions are not the solution for coordinatingupdates between services. We discussed why distributedtransactions are problematic.
According to Pat Helland, we must find the solution to our problem by looking at:
We also discussed how using 2 way (synchronous) communication between our services results in hard coupling and other annoyances:
It results in communication related coupling (because data and logic are not always in the same service )
It also results in contractual-, data- and functional coupling as well as high latency due to network communication
Layered coupling (persistence is not always in the same service )
Temporal coupling (our service can not operate if it is unable to communicate with the services it depends upon)
The fact that our service depends on other services decreases its autonomy and makes it less reliable
All of this results in the need for complex logic compensation due to the lack of reliable messaging and transactions.
If we combine (synchronous) 2 way communication with small / micro-services, modelled according to e.g. the rule 1 class = 1 service, we are actually sent back to the 1990s with Corba and J2EE and distributed objects.
Unfortunately, it seems that new generations of developers, who did notexperiencedistributed objects and therefore not take part in the realization of how bad the idea was, is trying to repeat the history. This time only with new technologies, such as HTTP instead of RMI or IIOP.
Jay Kreps summed up the current Micro Service approach, using two way communication, very aptly: