The concept of Microservices, even if a bit ephemeral, gets a lot of love nowadays. Reasons are quite straightforward, so I'm not going through that once again - what bothers me is some kind of misconception / overinterpretation I've already encountered few times.

Microservices (MS):

  • YES, encapsulate service business logic for coherent & compact slice of (sub-)domain
  • YES, encapsulate persistent data that business logic works on (MS that share the same data aren't really MS!)
  • NO, they aren't supposed to correspond directly (1:1) to slice(s) of actual high-level (for instance: user-facing) applications

Why not?

MS are NOT a way to horizontally slice whole (top-to-bottom) applications into atomic, independent parts. That wouldn't just be very hard to achieve, actually it'd be harmful for the services. There's a very clear distinction between MS & applications that utilize them.

  1. MS are meant to be re-usable, complete (all operations on the slice of data contained are to be kept within this particular MS), simple & useful for any kind of MS "consumer" ...
  2. ... whilst applications are much more complex - one particular action may require interaction with several atomic MS & it doesn't mean that they are designed badly - some of these may be core domain-related, some may come from auxiliary sub-domains (like security, audit, monitoring, etc.)
  3. Applications are not supposed to be generic - quite the contrary - they are expected to fulfil some very particular user needs: in least-fuss, ergonomic, customized way
  4. Applications are the subject for very frequent changes, but adjustments in presentation logic, user experience, etc. should NOT cause a revolution (large scale revamp) need in MS layer

So, if you, by any chance, think that MS may be your silver bullet in a quest to break a monolithic, user-facing end-to-end big ball of mud into series of tiny top-to-bottom spikish micro-apps: that's not gonna work. 1:1 or even 1:n relationship between apps & MS are not achievable in a healthy way.

Aren't we building walls?

Does it mean that app & MS development should be fully separated (different code owners, disjunctive work streams, separate product management)? Not really. A key to high development agility & short delivery cycle are cross-functional, independent teams who are capable of creating fully operational increment of functionality within a short period of time. How to achieve that in a world of separate applications & MS that map m:n to each other?

  1. If you have a comfort of a short development cycle for both services & apps, problem is practically non-existent, delays are much shorter & as long as you have properly defined products (& their owners), friction between separate prioritization shouldn't be noticeable

  2. If there are several teams, but the communication is smooth, people are co-located, capable of highly efficient co-operation, understand their common goal & share the same (or at least congruent) vision - you can try shared code ownership (I've already written whole blog post about that here)

  3. If your org opts for clear code ownership BUT you have decent tooling (CI + short feedback loop, DVCS, static code analysis, etc.) & mature processes (peer code review, mature continuous improvement loop: experiments + validated learning), you can try internal Open Source model (here's a great reference to get the idea)

  4. Obviously, the easiest way is to go with the closest approximation method - try to group apps & MS in domain-based silos as well as possible: TBH if you manage the applications right, each of them should have a clear business purpose (the best test: for each new functionality it should be perfectly clear which application it should be added to), so it should in a natural way be "closer" (more calls) to some of MS. Of course there will be some MS that belong nowhere (or rather - everywhere): mainly infrastructure ones, but that's unavoidable.

Conceptual independence of MS

To be honest, the actual split of responsibility is NOT that important (all of them may work), it's keeping the MS "tidy & clean" (& Microservicish) that's far more important:

  • application logic belongs to application, MS logic belongs to MS!
  • MS is "as complete" as it needs to be for its declared purpose - if there's a validation that doesn't involve other sub-domain logic, incorporate it in, but otherwise don't mix sub-domains within MS
  • DDD principles apply both in apps & in MS, but contexts may differ a lot (context mapping may be necessary)
  • MS does not have UI, but it still is a "product" - not just a list of operations dedicated for particular app screens! If UX in a given app is driving your MS design, you're pretty much screwed ...

Pic: © hywards - Fotolia.com

Share this post