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:
I have created a short instructional video that focuses on how we can improve our codes readability and quality by applying functional principles made easily available with Java 8. We will specifically learn how to avoid NullPointerExceptions in our code base by using the new Optional class.
This talk with focus on how we can improve our codes readability and quality by applying functional principles made easily available with Java 8. We will specifically learn how to avoid NullPointerExceptions in our code base by using the new Optional class.
The subject, as the title indicates, is micro services, which in many ways is a response to monolithic architectures. As with SOA, Micro Services also lack a clear definition . The only thing people seem to agree on is that Micro services are smalland they are individually deployable . Rule of thumb says that Micro services weigh in around 10-100 lines of code (for languages with minimal ceremony and excl. Frameworks and libraries – although the last point is disputed among purists). Number of lines of code is in my opinion a horrible measuring stick for determining whether a (micro) service has the correct size or for that matter if it is a good service.
Good guidelines for designing micro services in terms of scope (size) and integration form (how to use them) seems to be lacking. Without these guidelines it becomes difficult to separate the wheat from the chaff and one could easily be tempted to claim that the layered SOA (anti) pattern (see diagram below) also meets the micro service size rule of thumb (and then we know that some people will be tempted to cross off micro services on their list and say that they have them too, without looking closely at what micro services is all about and therefore never will come near designing proper micro services).