All posts in System Integration

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 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

As I explained in Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 5, to me a service is a logical boundary that is the technical responsible for a given business capability.
This means that the service owns all data, logic and UI for this capability everywhere it is used.

What does it mean that a service is a logical boundary?

As explained in Philippe Kruchten’s 4+1 view of software architecture, we should not automatically force the logical view to be the same as the physical implementation or for that matter the deployment view.
This often means that a service isn’t a single implementation or deployment artifact.

Examples of business capabilities are: Sales, Shipping, Marketing, Billing, Policy Management, etc.
These capabilities are pretty broad in their scope. You’ve probably read that a microservice should follow the Single Responsibility Principle (SRP) – it should do one thing and do it well.
But if a microservice should cover an entire business capability it would most like be fairly big, which goes against many of the qualities we like about microservices, such as:

  • Small (easy to comprehend)
  • Replaceable (discard the old and write a new in 2 weeks)
  • Upgradable (upgrade just the parts you want without interrupting other parts)
  • Fast startup/shutdown
  • Individually deployable

A large service is still individual deployable, but from a scaling point it’s typically all or nothing: either you scale the entire deployable unit or you don’t.
What if it is only certain use-cases that needed scaling? This is often harder with too big a deployable unit (what some people refer to a monolith) due to individual components inside the unit being too tightly coupled, like a tangled ball of yarn.

Read more

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 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 6 – Service vs Components vs Microservices

First of all, sorry to those who’ve been waiting for part 5. My schedule has been too busy to find focused time to write part 5 before now 😳 .

In part 4 we looked at building our services around functional areas or business capabilities/bounded-contexts. We discussed that the business data and logic pertaining to a business capability must be encapsulated inside a service to ensure single source of truth for the data. This also means that other services aren’t allowed to own the same data that another service owns (we want to avoid multi master services). Since we want our service to be autonomous (i.e. be able to make a decision without having to communicate synchronously with other services), we also looked how to avoid 2 way communication (RPC, REST or Request/Response) between services. The options we looked at were Composite UI’s and Data duplication over Events. We also briefly discussed a 3rd option which involves a different view on services, where they’re not autonomous. Instead services expose intentional interfaces and coordinate updates/reads between several System of Records (SoR) that them selves are autonomous. I believe that organizations with many large legacy systems (and most likely multi master systems) should look into the possibilities of the 3rd option as I believe it may create less friction than trying to develop new autonomous services that are well aligned with business capabilities.

In part 5 I will continue discussing SOA and Microservices in the light of  autonomous services.

Business Capabilities and Services

In part 4 I suggested building our services around functional areas or business capabilities/bounded-contexts.
I would like to tighten up that statement and rephrase to: We should align our services with business capabilities.
Read more

Last week we enjoyed the company of several other SOA and microservice interested developers and architects at the µService Conference in London – https://skillsmatter.com/conferences/6312-mucon#program

We did a talk on Thursday called  “Microservices – SOA reminded of what it was supposed to deliver?” – the video and slides are available on line.
If you’re new to SOA, Microservices and/or DDD – we highly recommend watching Udi Dahans keynote before watching the video of our talk.

Enjoy 🙂

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 3 – 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 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 well defined Service Boundaries you (in most cases) shouldn’t need to call other services directly from your service to get data back.

Service boundaries

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 deployed individually (that’s at least one of the major qualities that people talk about in relation to microservices).
Read more

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