4 ms·

Well designed microservices drastically reduce complexity and mental overhead of working with a system. The problem is companies with poorly designed monoliths

Well designed microservices drastically reduce complexity and mental overhead of working with a system. The problem is companies with poorly designed monoliths hit complexity problems more quickly and often. If software architecture is not a core competency, solutions architecture is probably not either, and poorly designed microservices are a completely different beast. A distributed monolith is inherently more difficult to maintain and operate.

bildung 6y ago
But why would the same people that poorly designed the monolith be able to design the intrinsically more complex microservice architecture better?
- mkoubaa 6y ago
  +1 We have to keep in mind that not all software systems are designed by savants, and even ones that are might be constrained by business needs from rearchitecting them when they need it
- nostrebored 6y ago
  That's what I was trying to articulate in the end. Microservices are generally less complex.They can appear more complicated because companies who are choosing to transition usually do so after a problem. These problems are often due to poor monolith design. Teams that design poor monoliths typically have neither a software or solutions architecture proficiency
- spaetzleesser 6y ago
  My simple rule is: if you can’t write a decent library you won’t be able to write a well designed microservice. Microservices have all the challenges of library design plus quite a few more.
jjav 6y ago
> microservices drastically reduce complexity and mental overhead of working with a system If you only need to understand and maintain one of them, sure. That would be extremely rare though. You have to understand the entire system and all the interaction between all the parts. At which point the 10x complexity of excessive microservices will kill you.
- KptMarchewa 6y ago
  >You have to understand the entire system and all the interaction between all the parts. Maybe if you're CTO. Never seen that in case of individual contributors.
  - throwanem 6y ago
    I've been that IC. You can easily find cases where a feature implementation involves a vertical slice of the whole stack, just like you would in a monorepo. Do that enough times with enough different features and you end up touching most things. If you don't have organizational blockers to velocity, and you treat every task as a chance to learn something new about the architecture (as you should!), you don't need all that long to develop a sense of what's where and how the pieces fit together. You're not likely ever going to be at the same level of detail on everything all at once, and there can still be fuzzy parts - third party partners in particular can be difficult, especially if the org is not good at making known who's the SME for what - but you absolutely can build an understanding of the architecture as a whole, and that makes you able to dive in and work on just about anything without needing much spinup time. (Granted this assumes good technical and architectural leadership early on that has specified standards for interservice communication, intraservice code design, what layers exist and how they interoperate, etc. That said, Wild West microservices might still be less painful to work on than a Wild West monolith - I don't actually know, but I could come up with arguments either way.)
    - emodendroket 6y ago
      Depends where you are. That’s not going to happen at Big N size environments.
      - throwanem 6y ago
        In such environments, I wouldn't expect it to be particularly useful or necessary, either - it's not a good use of effort to deeply understand foo-service if I can just ask somebody on the Foo team, or read their schema and docs, and get what I need much faster that way. I'm thinking more from the perspective of a small team supporting a large operation, because those are the kinds of situations where I've spent a lot of my career. FAANG scale would be a novel experience for me, as I suspect it would for most.

bildung 6y ago

But why would the same people that poorly designed the monolith be able to design the intrinsically more complex microservice architecture better?

mkoubaa 6y ago
+1 We have to keep in mind that not all software systems are designed by savants, and even ones that are might be constrained by business needs from rearchitecting them when they need it
nostrebored 6y ago
That's what I was trying to articulate in the end. Microservices are generally less complex.They can appear more complicated because companies who are choosing to transition usually do so after a problem. These problems are often due to poor monolith design. Teams that design poor monoliths typically have neither a software or solutions architecture proficiency
spaetzleesser 6y ago
My simple rule is: if you can’t write a decent library you won’t be able to write a well designed microservice. Microservices have all the challenges of library design plus quite a few more.

jjav 6y ago

> microservices drastically reduce complexity and mental overhead of working with a system If you only need to understand and maintain one of them, sure. That would be extremely rare though. You have to understand the entire system and all the interaction between all the parts. At which point the 10x complexity of excessive microservices will kill you.

KptMarchewa 6y ago
>You have to understand the entire system and all the interaction between all the parts. Maybe if you're CTO. Never seen that in case of individual contributors.
- throwanem 6y ago
  I've been that IC. You can easily find cases where a feature implementation involves a vertical slice of the whole stack, just like you would in a monorepo. Do that enough times with enough different features and you end up touching most things. If you don't have organizational blockers to velocity, and you treat every task as a chance to learn something new about the architecture (as you should!), you don't need all that long to develop a sense of what's where and how the pieces fit together. You're not likely ever going to be at the same level of detail on everything all at once, and there can still be fuzzy parts - third party partners in particular can be difficult, especially if the org is not good at making known who's the SME for what - but you absolutely can build an understanding of the architecture as a whole, and that makes you able to dive in and work on just about anything without needing much spinup time. (Granted this assumes good technical and architectural leadership early on that has specified standards for interservice communication, intraservice code design, what layers exist and how they interoperate, etc. That said, Wild West microservices might still be less painful to work on than a Wild West monolith - I don't actually know, but I could come up with arguments either way.)
  - emodendroket 6y ago
    Depends where you are. That’s not going to happen at Big N size environments.
    - throwanem 6y ago
      In such environments, I wouldn't expect it to be particularly useful or necessary, either - it's not a good use of effort to deeply understand foo-service if I can just ask somebody on the Foo team, or read their schema and docs, and get what I need much faster that way. I'm thinking more from the perspective of a small team supporting a large operation, because those are the kinds of situations where I've spent a lot of my career. FAANG scale would be a novel experience for me, as I suspect it would for most.