1. 12
  1.  

  2. 14

    If we want microservices to improve scalability or use multiple languages, then they may be the right choice. But if we want them primarily for the separation of concerns, I think that’s a bad idea.

    This is the key takeaway here. It’s nice to see someone thinking about microservices the same way I have since I first heard of them.

    1. 3

      That’s been my take too. We’re very good at violating encapsulation. Microservices are our way of imposing discipline on ourselves.

      https://michaelfeathers.silvrback.com/microservices-and-the-failure-of-encapsulaton

      1. 3

        I think the fact that we need microservices to impose discipline on ourselves is a sign that our programming tools kinda suck.

        1. 2

          It’s not our tools, its our culture. How seriously do we take good engineering? Is it really something we value?

          Or are we more excited we used the newest React release?

          For all the (consumeristic) discussions of what ‘stack’ one is using, or “why we used X to build Y,” nobody seems to want to talk about the actual building part. This is akin to furniture makers getting together and arguing at length over the best Ikea parts used to build a dining table. You might respond: “but, what libraries and technologies we use makes a difference in the outcome.” It certainly does! But the undue focus on the what reveals that we’ve let hype and employability displace the whole engineering aspect.

          If you squint enough, it seems like part of this culture just wants to be overpaid technicians.

          1. 3

            It’s not our tools, its our culture. How seriously do we take good engineering? Is it really something we value?

            This is something I’ve been thinking about. How much are “the tools we use” and “what we value” different things? “A goal without a method is nonsense.” We don’t get something by wanting it enough. It might help for a few days, but without process and a dedication to change, systems eventually revert to the mean.

            I absolutely think that constantly reevaluating our tools and pushing them to suit us better is one of those methods where we value quality engineering. Not excitement at using new things, but critical purging of what doesn’t work. But that means planning and analysis. I think there’s enough information that, say, better modularization tools would help.

            That’s part of getting good engineering. There’s a lot more, of course: formalized code review, rigorous postmortems, rigorous premortems, constant tracking of all bugs and how they form a statistical control. Then, reduce the variance away from spec. That’s where better tools come in.

    2. 7

      I’ve seen quotes from Alan Kay where he says that his approach to objects (not classes) was like this. Each object is something you send messages to. Erlang processes are similar.

      This post has the right idea, though. It makes sense to adopt microservices only if you need the specific features you get from sticking network boundaries between things.

      1. 3

        You can try his kind of OOP if you want since it’s still maintained and extended.

        http://squeak.org

        Edit: Also supposedly easy to learn due to minimalist language and designed for kids.

        1. 3

          I think the problem with objects in most languages is with having shared mutable state when you pass around references to them. Erlang avoids this problem entirely.

          1. 3

            I’ve come to believe that state is just as problematic for services as it is for objects, and that, as with data in Clojure, immutability should be the default. The “black box” terminology around both classes and microservices tends to imply that state is an implementation detail and the consumer shouldn’t know or care. I don’t think that’s viable. Stateful services need to be called out as their own category of thing, or the state needs to be moved out of the services altogether.

            1. 3

              Clojure addresses this in a really nice way of ‘Identity’ and ‘state’, you can read about it here .

              https://clojure.org/about/state#_object_oriented_programming_oo

              1. 2

                Yup, very happy with the way this works in Clojure. I find that immutability as the default naturally leads to low coupling. I tend to treat each namespace as a small library that does a specific transformation of the data.