Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 3

Danish version: http://qed.dk/jeppe-cramon/2014/04/22/micro-services-det-er-ikke-kun-stoerrelsen-der-er-vigtigt-det-er-ogsaa-hvordan-du-bruger-dem-del-3/

Part 1 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 2 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 4 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 5 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 6 – Service vs Components vs Microservices

Text updated the 26th of June 2021

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 coupling problems 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” (original article from 2007) / “Life Beyond Distributed Transactions – An Apostate’s Opinion” (updated and abbreviated version from 2016), which takes the position that Distributed transactions are not the solution for coordinating updates between services. Finally we discussed why distributed transactions are problematic and what approach Pat Helland proposed instead.

According to Pat Helland, we must find the solution to our problem by looking at:

1. How do we split our data between services
2. How do we identify our data within services
3. How do we communicate between our services

Section 1 and 2 were covered in Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 2 and can be summarized:

• Our data must be collected in pieces called entities or aggregates (in DDD terminology).
• Each aggreate is uniquely identifiable by an ID (for example a UUID / GUID).
• These aggregates need to be limited in size, so that they after a transaction are consistent.
• The rule of thumb is: 1 use case = 1 transaction = 1 aggregate.

In this blog post we will look at section 3 “How do we communicate between our data / services”

Advertisement

Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 2

Danish version: http://qed.dk/jeppe-cramon/2014/03/13/micro-services-det-er-ikke-kun-stoerrelsen-der-er-vigtigt-det-er-ogsaa-hvordan-du-bruger-dem-del-2/

Part 1 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 3 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 4 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 5 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 6 – Service vs Components vs Microservices

Text updated the 23rd of June 2021

In Micro services: It’s not (only) the size that matters, it’s (also) how you use them – part 1, we discussed how the number of lines of code is a very poor measure for whether a service has the correct size and it’s totally useless for determining whether a service has the right responsibilities.

We also discussed how using 2 way (synchronous) communication between our services results in tight coupling and other annoyances, amongst other things communication related coupling, because data and logic often aren’t in the same service.

2 way (synchronous) communication between services also causes:

• Higher latency due to network communication
• Contractual-, data– and functional coupling
• Layered coupling, because persistence logic often isn’t in the same service that owns the business logic
• Temporal coupling, which means that our service can not operate if it is unable to communicate with the services it depends on
• Lower services autonomy and less reliability, because our service depends on other services to perform its job
• All of this also introduces the need for complex compensation logic due to the lack of reliable messaging and coordinating transactions.

Reusable service, 2 way (synchronous) communication and coupling

Worst case, If we combine (synchronous) 2 way communication with nano- / micro-services, modelled according to e.g. the rule 1 class = 1 service, we have basically returned to the 1990s where Corba and J2EE/EJB’s and distributed objects ruled.

Unfortunately, it seems that new generations of developers, who did not experience distributed objects and therefore haven’t yet realized how bad an idea it was to overuse this, is bound to repeat history.
This time we have just switched technologies like RMI or IIOP out with HTTP+JSON instead.

Jay Kreps summed up the common Micro Service approach, using two way communication, very aptly:

Jay Kreps – Microservice == distributed objects for hipsters (what could possibly go wrong?)

Using Functional Principles in Java 8 to improve code quality

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.

Enjoy 🙂

Using Functional Principles in Java 8 to improve code quality from Jeppe Cramon on Vimeo.

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.

Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 1

Danish version: http://qed.dk/jeppe-cramon/2014/02/24/microservices-det-er-ikke-kun-stoerrelsen-det-er-vigtigt-det-er-ogsaa-hvordan-du-bruger-dem-del-1/

Part 2 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 3 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 4 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 5 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 6 – Service vs Components vs Microservices

Text updated the 22nd of June 2021

We have finally come to the exciting development I hinted at in SOA – Hierarchy or organic growth?
In the blog post Microservices: synchronous communication, data ownership and coupling, we examined the 4 Tenets of Service Orientation and specifically focused on service boundaries and autonomy problems due (synchronous) 2 way communication between Services. With this knowledge in hand, we are well prepared for the topic of this blog post.

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 small and 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).

So are the services within a classic layered SOA real micro services?