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?

Advertisement

Microservices: synchronous communication, data ownership and coupling

Danish version: http://qed.dk/jeppe-cramon/2014/02/01/soa-synkron-kommunikation-data-ejerskab-og-kobling/

Text updated on the 21st of June 2021

The other day I read that the new Proask system for the National Board of Industrial Injuries in Denmark, was the first major project that would realize the Ministry of Employment strategic decision to use a Service Oriented Architecture (SOA). For those who have not heard of Proask, it is yet another strongly delayed public project which, like most other public projects, are trying to solve a very big problem in a large chunk. A lot can be written about this approach, but in this blog post I will focus on here is their approach to SOA. A related article reports that the new Proask system is 5 times slower than their old system from 1991.

The Proask project was initiated in 2008. It made me think back on other ( private) SOA prestige project from the same period, for which I was the architect for a subcontractor. The entire project was built around SOA with many subsystems that would deliver services. The entire architecture was built around an ESB that would act as facilitator in terms of mapping and coordination. All communication was done as synchronous WebService calls over HTTP(S). So classic SOA for the period 2003-201? (sadly synchronous calls are still the predominant integration form today). This SOA realization was also characterized by very poor performance, high latency  and low stability.

But why ? The reason lies in the way they had chosen to split up the services and not least that they had chosen to communicate synchronously between the different services and made use of layered SOA approach.

Slides and video from our IDDD Tour DK talk – What SOA do you have (with extended EDA and CQRS material)

Most companies today use SOA to integrate their systems or mobile applications, or do they?
Join me on a historical trip where we will see how integration has remained stuck in the same patterns and we will also take a look at the emperors new clothes (or SOA as it’s practiced today).
After this we will look at how to do SOA better and the principles that will make this transition possible (keywords: Event Driven Architecture, Domain Driven Design, Composite UI’s and CQRS)

You can find the slides and video here.
Slideshare version of the slides is available here

If you have comments please post them below 🙂

/Jeppe