3 ms·

Engineer induced complexity is also common. I've never heard about management pushing for a scalable, event-driven, microservice based architecture when a simpl

by lytefm 4y ago

Engineer induced complexity is also common. I've never heard about management pushing for a scalable, event-driven, microservice based architecture when a simple monolith serving a few thousand daily users would be just fine.

miscaccount 4y ago
Well probably you have never met management that is keyword drive. We need 100 percent scalable system with zero downtime upgrade and support thousand customers update. Current number of customers : 0 Number of customers in pipeline: 0
throwaway894345 4y ago
Maybe. I've never worked in an organization where engineers were driving the complexity, nor have I worked in an organization where microservices introduced complexity (I've heard people complain in vague terms about microservices, but I don't relate to their experiences). However, I have worked in an organization that transitioned from monoliths to microservices, and the overall complexity was reduced because (I didn't mean for this to turn into a monolith/microservices thread, but oh well): 1. an engineer under management pressure couldn't easily take an expedient dependency on the private internals of another system 2. teams could deploy their changes on their own cadence, so they didn't feel additional pressure to squeeze poorly-conceived things into one less-frequent release (many frequent releases are theoretically possible for monoliths, but much rarer for pretty understandable reasons) Moreover, reliability improves because of the aforementioned reduced complexity but also because the blast radius for a reliability issue is scoped to the service, and security improves for the same "blast radius" reason (an attacker who compromises a component can only access that component's secrets and can only talk to that component's collaborators). My suspicion is that microservices work very well when an organization has a strong architecture/SRE capability irrespective of management or product development capabilities, whereas a monolith depends on all capabilities firing on all cylinders.
- dasil003 4y ago
  "Microservices" (ie. SOA) absolutely adds complexity, the question is whether the benefits are worth the overhead. The answer varies according to domain, but is largely a function of team size.
  - throwaway894345 4y ago
    There’s definitely some complexity inherent in microservices which isn’t inherent in monoliths, but that doesn’t mean a net increase in a given microservice relative to an equivalent monolith because microservices disincentivize other kinds of complexity (which monoliths don’t disincentivize) as mentioned above. The net complexity may well be (and often is IME) less for a microservice than for an otherwise similar monolith. In addition to this net complexity discussion, microservices also have security, scalability, and reliability benefits.
  - lytefm 4y ago
    > The answer varies according to domain, but is largely a function of team size. I agree. If both team size and code base are small, the scalability is not needed and the domain logic isn't too complicated, microservices add an overhead with very limited benefits. If you have different teams for each service - great. If you the same person is working on multiple services - probably a premature move to a more complicated architecture.

by lytefm 4y ago

miscaccount 4y ago

Well probably you have never met management that is keyword drive. We need 100 percent scalable system with zero downtime upgrade and support thousand customers update. Current number of customers : 0 Number of customers in pipeline: 0

throwaway894345 4y ago

Maybe. I've never worked in an organization where engineers were driving the complexity, nor have I worked in an organization where microservices introduced complexity (I've heard people complain in vague terms about microservices, but I don't relate to their experiences). However, I have worked in an organization that transitioned from monoliths to microservices, and the overall complexity was reduced because (I didn't mean for this to turn into a monolith/microservices thread, but oh well): 1. an engineer under management pressure couldn't easily take an expedient dependency on the private internals of another system 2. teams could deploy their changes on their own cadence, so they didn't feel additional pressure to squeeze poorly-conceived things into one less-frequent release (many frequent releases are theoretically possible for monoliths, but much rarer for pretty understandable reasons) Moreover, reliability improves because of the aforementioned reduced complexity but also because the blast radius for a reliability issue is scoped to the service, and security improves for the same "blast radius" reason (an attacker who compromises a component can only access that component's secrets and can only talk to that component's collaborators). My suspicion is that microservices work very well when an organization has a strong architecture/SRE capability irrespective of management or product development capabilities, whereas a monolith depends on all capabilities firing on all cylinders.

dasil003 4y ago
"Microservices" (ie. SOA) absolutely adds complexity, the question is whether the benefits are worth the overhead. The answer varies according to domain, but is largely a function of team size.
- throwaway894345 4y ago
  There’s definitely some complexity inherent in microservices which isn’t inherent in monoliths, but that doesn’t mean a net increase in a given microservice relative to an equivalent monolith because microservices disincentivize other kinds of complexity (which monoliths don’t disincentivize) as mentioned above. The net complexity may well be (and often is IME) less for a microservice than for an otherwise similar monolith. In addition to this net complexity discussion, microservices also have security, scalability, and reliability benefits.
- lytefm 4y ago
  > The answer varies according to domain, but is largely a function of team size. I agree. If both team size and code base are small, the scalability is not needed and the domain logic isn't too complicated, microservices add an overhead with very limited benefits. If you have different teams for each service - great. If you the same person is working on multiple services - probably a premature move to a more complicated architecture.