All posts in Agile

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

I have often wondered why big programs tend to end up in big failures and I think I have finally understood the dynamics behind it. Having taken part in several big programs myself, that all failed one way or the other, I have felt it on my own body and it is not a nice feeling. Recently I was involved with a program that had tried and failed 3 times using the same approach.

By the way, by big programs I do not mean, say a Java program with tons of lines of code, but a collection of projects intending to make major changes to an organization.
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

The slides from our AANUG talk on “Agile, Architecture, DDD and CQRS” is available here

As always, feel free to leave comments 🙂

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