All posts in Enterprise Architecture

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

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” (PDF format) which takes the position that Distributed transactions are not the solution for coordinating updates between services. We discussed why distributed transactions are problematic.

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

  1. How do we split our data / services
  2. How do we identify our data / services
  3. How do we communicate between our data / 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 from 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”
Read more

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

In Micro services: Micro services: It’s not (only) the size that matters, it’s (also) how you use them – part 1, we discussed how the use of the number of lines of code is a very poor measure of 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 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.
Reusable service, 2 way (synchronous) communication and coupling

Reusable service, 2 way (synchronous) communication and coupling

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 not experience distributed 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:

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

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

Read more

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

We have finally come to the exciting development I hinted at in SOA – Hierarchy or organic growth?
In the blog post SOA : 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?
Read more

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

I read the other day that the new system Proask 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 that other ( private) SOA prestige project from the same period, for which I was an 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.
Read more

Note: This is the english version of Jeppe’s qed.dk blog post

There is an interesting change in the approach to SOA and it comes from an unexpected area.

I have worked with SOA (a great acronym which really says nothing as it has been watered out) for over 10 years and through my time I have seen companies build more and more hierarchy (or rather layers) and structure into their SOA landscape as a way to achieve “business agility through business and IT alignment and increased recycling”. If you tend to get a gag reflex by hearing the phrase, I feel you.

The idea and the intention is good, but the execution many places is to the grade F-. Instead of having achieved agility through loosely coupled services, these companies instead end up with hard-coupled services, an expensive and cumbersome organizational Enterprise Service Bus (ESB), which is placed centrally to coordinate the hundreds to thousands of services we have built. It is a bit like herding sheep with a chest freezer and a rope tied to each sheep.
Let me make it clear, I don’t believe SOA, nor the ESB, is to be blamed for these failures. In my experience it has been the way they were implemented and deployed that cause the majority of problems.

Herding sheep using a chest freezer and rope

Herding sheep using a chest freezer and rope

It’s messy and unstable. Not unstable as in the ESB is unstable, but unstable in that we’re desperately trying to create order out of chaos without understanding the mechanisms of action.
Let me make it clear, I don’t believe SOA, nor the ESB, is to be blamed for these failures. In my experience it has been the way SOA were implemented and deployed that has caused the majority of problems.
Read more