3 ms·

> micro-service architecture imposes a heavy penalty on team co-ordination This is, by far, the hardest scaling problem in SaaS: How do we divide responsibilit

> micro-service architecture imposes a heavy penalty on team co-ordination This is, by far, the hardest scaling problem in SaaS: How do we divide responsibilities amongst our (code|services|teams) efficiently? You can only grow each so much before they become unwieldy to manage. Divide scope too much and communication becomes complex. Divide along the wrong abstraction and you get duplication, overlap, and confusion about what's responsible for what. And as time passes, decisions of the past constrain and complicate your options to redesign/rearchitect/reorg today.

matai_kolila 4y ago
So it's "bad micro-service architecture imposes a heavy penalty on team co-ordination", then. ...which is a fairly obvious observation. "Bad <x> imposes a heavy penalty on team co-ordination" is generalizable.
- vaidhy 4y ago
  There is no bad vs good micro-service architecture. It is just that micro-service architecture imposes a different kind of penalty on co-ordination and debugging. Instead of intra-component dependency, it moves it to inter-service dependency. Each service might look simple, but the complexity is moved to service communications. It is not that obvious, imho.
  - bobthepanda 4y ago
    Also, what is good and bad can change over time with the business. Few judgement calls in software will last forever.
  - deleted 4y ago
    [deleted]
  - matai_kolila 4y ago
    There absolutely are bad microservice architectures, that's a weird claim to make. Good microservice architectures minimize or entirely eliminate the friction around the coordination and debugging. I'm working on splitting out a monorepo as we speak and I'm determining tradeoffs we'll need to make. If I do this wrong, there will be a lot of pain around navigating between the services, but there are choices I can make now that minimize (or eliminate in some cases) that pain. I recommend you find a way to spend time with someone who knows how to design a quality microservices architecture. It will completely change your opinion about how microservices interact and the supposed "pain" therein.
    - vaidhy 4y ago
      If it were so obvious, I am wondering why you need to worry about doing it wrong. You talk about trade-offs as if they are fixed in time. That is not the case at all in anything but toy systems. Maybe you need to find someone who can design a quality micro-service? You have no idea what I do and what my competencies are, yet, you are assuming you know a lot more about system design than I do and I am missing something simple. Here is another take from Bryan Cantrill [https://www.youtube.com/watch?v=30jNsCVLpAE&t=1413s https://www.youtube.com/watch?v=30jNsCVLpAE&t=1413s]. Very likely, he does not know anything about services either, I guess.
      - matai_kolila 4y ago
        Can you show me where I said "building microservices is obvious"? Or if you don't believe I said that, can you describe what you think it is I'm suggesting here? Because my intent was to say, "It is obvious that microservices can be designed well and designed poorly." In fact, if you'll observe, I removed the word "microservices" from my final statement, to demonstrate that such a statement is trivially true for any given thing. Nowhere did I say, "It is obvious how to design a good microservice." but it seems like you're arguing against that statement, not the one I made. And for what it's worth, I don't give a hoot who you are, who Bryan Cantrill is, or what your supposed competencies are; make your argument, don't rely on your pedigree to speak for you. That should be obvious.
0xbadcafebee 4y ago
I think the answer is kind of obvious, but disappointing: the way to scale is to both divide responsibility while simultaneously sharing it. The way to do this well is to work on the basics: communication, training, quality, study, operations, continuous improvement. There is no magical model for this, no buzzword, no single practice, because different businesses and use cases need to be adapted to it. But there's 70+ years of study into methods to do this, and I believe they're taught by all the business schools. It's just nobody wants to do the work. ....On the other hand, nobody teaches MBAs how drastically different tech is than other industries, and thus how you run your "factory floor" has to be different. But the basic principles above should still be applied; they just have to be adapted to the industry and work. What one should not do is just accept things however that industry does it, because they probably aren't doing the above principles either.

matai_kolila 4y ago

So it's "bad micro-service architecture imposes a heavy penalty on team co-ordination", then. ...which is a fairly obvious observation. "Bad <x> imposes a heavy penalty on team co-ordination" is generalizable.

vaidhy 4y ago
There is no bad vs good micro-service architecture. It is just that micro-service architecture imposes a different kind of penalty on co-ordination and debugging. Instead of intra-component dependency, it moves it to inter-service dependency. Each service might look simple, but the complexity is moved to service communications. It is not that obvious, imho.
- bobthepanda 4y ago
  Also, what is good and bad can change over time with the business. Few judgement calls in software will last forever.
- deleted 4y ago
  [deleted]
- matai_kolila 4y ago
  There absolutely are bad microservice architectures, that's a weird claim to make. Good microservice architectures minimize or entirely eliminate the friction around the coordination and debugging. I'm working on splitting out a monorepo as we speak and I'm determining tradeoffs we'll need to make. If I do this wrong, there will be a lot of pain around navigating between the services, but there are choices I can make now that minimize (or eliminate in some cases) that pain. I recommend you find a way to spend time with someone who knows how to design a quality microservices architecture. It will completely change your opinion about how microservices interact and the supposed "pain" therein.
  - vaidhy 4y ago
    If it were so obvious, I am wondering why you need to worry about doing it wrong. You talk about trade-offs as if they are fixed in time. That is not the case at all in anything but toy systems. Maybe you need to find someone who can design a quality micro-service? You have no idea what I do and what my competencies are, yet, you are assuming you know a lot more about system design than I do and I am missing something simple. Here is another take from Bryan Cantrill [https://www.youtube.com/watch?v=30jNsCVLpAE&t=1413s https://www.youtube.com/watch?v=30jNsCVLpAE&t=1413s]. Very likely, he does not know anything about services either, I guess.
    - matai_kolila 4y ago
      Can you show me where I said "building microservices is obvious"? Or if you don't believe I said that, can you describe what you think it is I'm suggesting here? Because my intent was to say, "It is obvious that microservices can be designed well and designed poorly." In fact, if you'll observe, I removed the word "microservices" from my final statement, to demonstrate that such a statement is trivially true for any given thing. Nowhere did I say, "It is obvious how to design a good microservice." but it seems like you're arguing against that statement, not the one I made. And for what it's worth, I don't give a hoot who you are, who Bryan Cantrill is, or what your supposed competencies are; make your argument, don't rely on your pedigree to speak for you. That should be obvious.

0xbadcafebee 4y ago

I think the answer is kind of obvious, but disappointing: the way to scale is to both divide responsibility while simultaneously sharing it. The way to do this well is to work on the basics: communication, training, quality, study, operations, continuous improvement. There is no magical model for this, no buzzword, no single practice, because different businesses and use cases need to be adapted to it. But there's 70+ years of study into methods to do this, and I believe they're taught by all the business schools. It's just nobody wants to do the work. ....On the other hand, nobody teaches MBAs how drastically different tech is than other industries, and thus how you run your "factory floor" has to be different. But the basic principles above should still be applied; they just have to be adapted to the industry and work. What one should not do is just accept things however that industry does it, because they probably aren't doing the above principles either.