Category: CQRS

Service vs Components vs Microservices – part 6

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.

Continue reading “Service vs Components vs Microservices – part 6”

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

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.
Continue reading “Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 5”

Video and slides from our “Microservices – SOA reminded of what it was supposed to deliver?” talk

Last week we enjoyed the company of several other SOA and microservice interested developers and architects at the µService Conference in London –

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 🙂

SOA/Microservices: synchronous communication, data ownership and coupling

Danish version:

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.
Continue reading “SOA/Microservices: synchronous communication, data ownership and coupling”

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 🙂