349721 (1) [Avatar] Offline
#1
Interesting take on Microservices that good to see being published. Certainly an interesting approach: "proceed always by additive composition of more micro[nano]services, never rewrite old code". Definitely get the author's take that this avoid rewrites that gradually entangle existing code, that technical debt is the problem, and that monoliths lead to lack of encapsulation, and this entanglement.

Not sure that the "nanoservice" approach doesn't just shift complexity elsewhere tho - that nanoservices is really the right level of granularity to go for. A few key challenges with this approach in the real world that it would be good to see the author address:

Smart routing 'middleware': With functionality always added in new nano-services, how do we avoid falling in to the trap of having to write lots of business logic into routing? - into something which routes each message to the appropriate nano-service to handle? There's a strong argument saying this just shifts the business complexity elsewhere. You end up with business logic written in the routing component (whether a custom message router, enterprise bus, load balancer configuration or whatever). Business logic in two places ... another kind of complexity. See Martin Folwer on "smart endpoints, dumb pipes".

Can the nanoservices approach really scale effectively for an enterprise-scale system?: (not just, eg, a one-main-product consumer-facing website / startup). I don't mean scale technically (clearly it can). I mean scale effectively in terms of a way of maintaining comprehensible software. I'd be desperately worried that a truly enterprise-scale system evolved along the lines Rodger suggests (everything additive, 100-line components) could lead to an incomprehensibly large number of additive microservices. The ability to reason about such a system (with such a large number of moving parts) can be severely impaired.

How transparent and easy to comprehend is it? When something goes wrong, how does the developer debugging that fault know where to start? Which of the myriad of nanoservices involved should the message have been (or not have been) handled by? Something like correlation ids tracing the route of messages through the system might not be enough: the problem might not be which services handled the message, it might be which services (perhaps services unfamiliar to the developer) didn't.

For example (to take one of the author's own examples), managing staff records for an organisation - but say a global organisation. So you start with the general case (local staff). You add some services for rules for regional staff. Then you add some more nanoservices for tax rules. Then some more nanoservices for salary sacrifice. Then some more for payroll giving. ... Quickly you're in to scores, 40, whatever, microservices, just for staff and payroll? Is that what the author genuinely intends? Is this maintainable? How does the author see this playing out for an _enterprise_ system, not a one-product consumer website?



A few other observations:

Emphasis on driving interactions between microservices by asynchronous messages, particularly to achieve that holy grail of decoupling, is excellent. In my experience this - rather than making microservices nano and never extended - is the biggest win from a microservices approach.

Author's advocated approach feels a bit like an 'Actors' model for microservices - is this a comparison worth making?

There's a mix of commands and events in the messages in the Ch1 & 2 examples. Not in itself a problem - sure the author aware - but might be worth drawing out and clarifying somewhere.

Writing style: Just occasionally descends into glibness with a whiff of intellectual arrogance? Ref eg: "We have this thing called refactoring, which is the technical term for getting caught making bad guesses. At least we have a professional sounding term for [...] wasted time [...]". Nothing wrong with challenging a few orthodoxies. But occasional glibness that doesn't really stand up might not be best way of drawing reader in? Just a thought. Well written and comprehensible otherwise.

Interested to see how the book develops and will address these challenges.
danbernier (22) [Avatar] Offline
#2
349721 wrote:Writing style: Just occasionally descends into glibness with a whiff of intellectual arrogance? Ref eg: "We have this thing called refactoring, which is the technical term for getting caught making bad guesses. At least we have a professional sounding term for [...] wasted time [...]". Nothing wrong with challenging a few orthodoxies. But occasional glibness that doesn't really stand up might not be best way of drawing reader in? Just a thought. Well written and comprehensible otherwise.

Agreed. There are a lot of straw-man arguments, as well. I think I like where it's going, and I think I'd like to find out, but I'm getting distracted by the flame-bait.

  • "Modern OO practice is explicit - Inheritance is considered harmful." "No!" I shout back, "it's not harmful, it's just a tool. You have to know how to use it."

  • The sidebar that implies OO is doomed (because of the exponential number of possible connections) ignores the reality that no one develops systems where the object graph is fully-connected.


  • I also agree with OP that there's "nothing wrong with challenging a few orthodoxies," especially since, as they say, "the problems we have can't be solved by the same level of thinking that got us there." But the straw-man arguments don't convince me of OO's weaknesses - they make me suspect the author has limited OO experience. I say this, hoping that you strengthen the argument, because I would love to hear how we can do better.

    Apologies if this is unclear - I'm stealing a moment from work to get my thoughts down here.
    388690 (2) [Avatar] Offline
    #3
    I'd like to share my thoughts on what you were saying,
  • "Modern OO practice is explicit - Inheritance is considered harmful." "No!" I shout back, "it's not harmful, it's just a tool. You have to know how to use it."


  • The also says in the first chapter, something like a "Practice that's been around for long and most of the people get it wrong is not a good practice" - and that sentence seems to strike my mind when I read the last part of your shouting. smilie

  • The sidebar that implies OO is doomed (because of the exponential number of possible connections) ignores the reality that no one develops systems where the object graph is fully-connected.


  • IMHO, I think the author's take on this is right. Encapsulation, Inheritance and all those concepts in OO were meant to contain the complexity so that other objects need not know what is happening inside the object in context they just need use the interface provided by the object and most importantly Reuse. But rarely we see that happen.

    These are just my views which shaped up while I was reading the book and popped back to my mind when I saw the comments you guys made.
    variousred (23) [Avatar] Offline
    #4
    Just noticed some small typos in chapter 1 Brave New World


    “The extreme degree, where microservices *no* nothing of each other, is the goal, as that gives you the full benefits of the architecture.”


    s/no/know



    “Everybody understands the consequences, yet participates in what might be called "quality theater" as to do otherwise is a career-limiting move.”


    “This somewhat arbitrary limit was chosen by the founders as the most the uninteresting number they could think of”

    Excerpt From: Richard Rodger. “The Tao of Microservices MEAP V03.” iBooks.



    “These activities are amenable the same style of analysis.”


    “It assumes that you have an transport system where each microservice can inspect every message, to see if the message is something that it can handle.”


    CHAPTER 2

    “In this spirit, a microservice is an independent software component that takes no more than iteration to build and deploy.”

    should say *one iteration*
    rachelb (6) [Avatar] Offline
    #5
    The author is clearly knowledgable and enthusiastic about his subject. He advocates ideas that I have not heard before, such as deploying additional microservices to capture non-standard use cases, rather than modifying existing microservices to capture additional use cases.

    However, the Chapter 1 comes across as a polemic, rather than a balanced discussion of the benefits and disadvantages of Microservices. Sentences such as (section 1.4 practical implications)

    “The microservice architecture is both a technical and a political strategy. It takes a cannon to intellectual castles, and demands honesty from the business. The pay-off is regular work hours, and accelerated delivery of business goals.”

    are incredibly off putting as they are grand sweeping statements claimed by every new approach to developing software in the last 30 years. I am left wondering whether this book is a parody.

    Also in Section 1.5.4 the author discusses two approaches two construction timelines - dynamically generating them on demand or constructing them incrementally in the background. The arguments he uses include "This doesn't feel right" and "Hardware is cheap". It comes across as very lazy given one approach requires bursts of CPU and the other requires background CPU and possibly more data storage - which he does not explain.

    In summary the author has a lot of interesting ideas, but the style is making the book a hard and painful slog rather than an enjoyable read.
    Richard Rodger (22) [Avatar] Offline
    #6
    Hi All,

    Point taken on the strawmen arguments - they will need more care.

    Object-graph: yup, good point. I need to show the same practical effect even if the number of connections don't that fast in the real world.

    Complexity: you definitely should not start using complex routing - simple pattern matching is more than sufficient, and where it isn't you can tackle special cases using an orchestration service or two.

    Messaging interactions: actor, command, etc, are emergent from pattern matching, not essential design decisions - that's the cool part, you can change the message interactions anytime you like.

    Comprehensibility: consider that the system description comes down to a list of message patterns, perhaps several hundred. These patterns will form families and sub families of related patterns, giving you an implicit hierarchy. Services will organize in the same way, and a single employee "service" is perhaps several tens of special cases.

    Style: I guess that would be the hardest thing to change smilie If you can forgive the glibness, I'm really trying to bring in learning from other disciplines - we have a lot to learn from non-programmers.

    frodik (2) [Avatar] Offline
    #7
    Section 1.5.4 includes a note saying that "This benefit is best expressed by Adrian Cockcroft, author of Microservice Patterns (2017, also by Manning), and a former Director of Engineering at Netflix: "You want cattle, not pets"."

    I think the author of the book is Chris Richardson, not Adrian Cockcroft.
    Richard Rodger (22) [Avatar] Offline
    #8
    Correct - thanks!