Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

> It mostly comes from businesses throwing a bunch of under-skilled labor at the problem, and demanding more and more too quickly.

Even if you have plenty of skilled engineers, it doesn't mean that the business won't impose unrealistic timelines (and insist the timelines be met even if it means taking on loads of tech debt which never gets paid down) or change the requirements abruptly or even demand things that are inherently complex (without understanding the complexity).

In other words, there are plenty of ways that management can create complexity, and in my experience management-induced complexity is the most common kind (note that I'm faulting "management" for things that include "communication between engineers and management" because management ultimately owns the software development process).

View on HN

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.

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

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.

"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.

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.

> 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.

Reply on news.ycombinator.com