This orchestra plays out of tune - microservice reality

By reading this article you'll learn that ... orchestra (like Emperor) is naked, easy problems sometimes get far more sexy solutions than the hard ones (so screw those), SOA is not...

5 months ago

Latest Post Mixing warsaw.ex by Sebastian Gebski

By reading this article you'll learn that ... orchestra (like Emperor) is naked, easy problems sometimes get far more sexy solutions than the hard ones (so screw those), SOA is not dead, microservices in the wild tend to be grotesque & out-scaling can be achieved in several different ways.

First of all, thanks for reading this :) I'm quite sure that at least 3/4 of potential readers have dropped off after seeing the word "microservice". And ... I don't blame them at all, I'm fed up as well. That's one of the reasons why I've written this article.

Hello (microservice) World.

My main problem with microservices is that there are tons of materials on them on the web, but in fact, a vast majority is pretty much worthless - covers only the most basic & common truths, without even touching the actual essence of complexity & real challenges related to using this pattern in your applications.

The usual microservices story is about code & data isolation, open standards-compliant contracts, independent deployment, backward compatible or semantically versioned API, sometimes about DDD basics like bounded context & aggregates. And that's pretty much all.

Shameless over-simplification.

Real world calling

What all these articles miss (intentionally are not) is the hard part, e.g.:

In my case - I had to learn all of these (& many more) the hard way: by trying out ideas & learning from mistakes. I find that amusing as some of the problems depicted by these questions are much harder than e.g. the ones tackled by (wildly popular these days) container orchestrators - "sold" usually as silver bullets in the world of microservices ...

In the mean-time we (IT professionals) have found ourselves yet another distractor - serverless functions (as a deployment unit) - which, however useful, also focus on secondary problems (IMHO).

Oldie but goldie

What's even more amusing - (almost) all attempts to solve the really painful problems in microservice architectures seem to closely follow widely condemned & despised old paths:

  1. asynchronous, decoupled, message-driven communication is deceptively reminiscent of old-fashioned Enterprise Service Bus(es)
  2. cross-microservice spanning sagas are not that far from the criticised concept of SOA orchestrators like Microsoft BizTalk or IBM WebSphere Integration Bus

Microservices (?) in the wild

Having observed all of that, I couldn't resist diving deeper - I've put the detective hat on & started the investigation aimed to find out how do the companies (I have any access to) apply the concept of microservices in their solutions. It wasn't hard to identify some regularities & patterns. Apart from just a few cases of companies that had managed to properly implement the idea of microservices (which was itself a tremendous effort & cost), there are basically 3 separate, much more numerous groups:

Let's get real

OK, so many are failing, other ones pay a high price for a potentially high benefit. But what's my point here? Is it just about emphasizing that there are much more challenges in microservice adoption than it may seem at the first glance?

No, my point is that in our chase for over-hyped half-truths, we recklessly tend to ignore alternative solutions to the very same problem (of the desired out-scalability) that do not get as much attention as they deserve.

Which ones? Here are few examples (that also can be combined):

  1. horizontal sharding - distribute OLTP processing by some key business entity (client, contract, agreement, area, industry - whatever makes sense in your domain)
  2. CQRS - write & read operations have separate transaction scopes (aggregates) - the only challenge is to have a reliable, event-driven change propagation mechanism (between write & read models), but this seems like a significantly simpler problem
  3. modularized monolith - yes, it's really not that stupid - if you enforce aggregate boundaries within monolith, you can gain significant performance improvements thanks to as simple techniques as basic DB partitioning, while at the same time minimizing latencies & minimizing negative effects of synchronous operations; using "microservice lingo" - isolating chunk of the bounded context to separate library may not be significantly worse than to separate process

Don't fall into the trap of blindly applying everything you've read in a random blog post on the web. Think for yourself. Focus on your case/domain. Evaluate the real cost against potential, feasible benefit.

That's how the engineers are supposed to act.

Sebastian Gebski

Published 5 months ago

Comments?

Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.