Join my daily Newsletter

Subscribe to get my latest content by email.

    I respect your privacy. Unsubscribe at any time.

    preloader

    All hail the monolith?

    • Tuesday, Jun 2, 2020
    blog-image

    [reading time: 1 minute 57 seconds]

    I read the following question the other day:

    “Are people still architecting for Microservices in light of some well-known returns to the monolith?”

    So, there we have it. Microservices are officially not cool anymore.

    What does that mean? That we’ve all gone serverless now (hi Paul ;-) )?

    Surely not. It means that the pendulum has started to swing back.

    You see, it doesn’t matter whether what you’re building is a monolith, or a microservice, or a nanoservice, or whatever else.

    What matters is that it gets the job done.

    And some people have perhaps gone too far in the direction of micro-ifying all the things, and overshot the sweet spot of making services as small as required, but no smaller.

    I can totally relate: sometimes you get wrapped up in the how, and before you know it you’ve lost sight of the why.

    Remember, the idea behind microservices is that they should map to business functions. Not to smaller, technical concerns.

    If you cut your product along business lines, you’ll likely end up with relatively few services (unless your product is totally sprawling, which of course is an issue in itself). If you have a reasonably-sized product, you’ll be hard pressed to come up with more than a few handfuls of services, if that many.

    And even if your product is this huge, it can probably be split into large blocks, all comprised of a handful of services.

    That way, whatever the size, complexity should stay manageable.

    And I don’t really mean technical complexity.

    What I mean is organisational complexity, the number and bandwidth of communication lines between people.

    That same complexity would be reached with a monolith (which certainly has internal structure as well) too. It’s just that microservices are an architectural style which tempts one to split things finer than might be warranted. I mean, just look at the name :-)

    But just as always, services should principally be split along human communication lines; the technical communication tends to be the smaller issue.

    Whatever you call your architecture style, make sure the right people talk to each other. I think that’s the lesson behind this apparent change in architecture fads.