Hacker News Reader

Comment by ejholmes | Hacker News Reader

I know this was probably well intentioned, but I can't shake the irony of how overly complex and over-engineered this is. If you're just starting out, please, please, please don't do this.

View on HN

Man, this is a frustrating and shallow criticism. Obviously this is over-engineered. It's a demonstration of how these patterns would fit together in an application that required them.

Agree it's not the best criticism, but there's at least some validity to it. I think the main issue is that this is an extremely heavyweight architecture that will incur a disproportionate level of administrative overhead - you would need an ample team of competent full-time devs to build and maintain this system properly. It's like an advertisement for a giant excavator where the excavator is featured crushing a soda can. It's an impressive piece of machinery, but the task being used to demonstrate it is comically mismatched with its true capabilities.

True, true. That's a fairer way to formulate it. But like, it's supposed to be an extremely heavyweight architecture. The benefits of microservices are arguably only apparent when you have an ample team (or teams!) of competent full-time devs.

You're right they could have... beefed up the soda can, so to speak, but I don't blame the (presumably) DevRel folks who put this together for hand-waving it, "now imagine a mountain here".

> The benefits of microservices are arguably only apparent when you have an ample team (or teams!) of competent full-time devs.

I would very much agree with that. Although I'm not against microservices, they are by no means a quick or efficient way to get things done. Hedging against future theoretical scaling concerns comes at a high cost - a cost that's very much worth it if true scale is achieved, but a high cost nonetheless.

Depends on the scale of this online store, if it saw 0.1% the amount of traffic as Amazon then it is justified.

Microservices solve a number of engineers scale problem, not a traffic scale problem. Tech scale is drastically more simple in a single application, because you don’t introduce an unreliable network and related complexity into all of your problems

Interesting, in my experience we've never had major issues with our service mesh or internal networking. It definitely introduces a lot more complexities. I suppose we've always had a dedicated devops team so I'm probably unaware of a lot of these issues.

I'd be interested in some resources around this topic if you know of any.

I'll be honest - pretty hard to find objective literature on it, because most of the literature is just trying to tell you microservices will solve all of your problems. I think ultimately the best link between the two is Amazon's move to microservices and their focus on "2 pizza teams".

https://www.slideshare.net/TriNimbus/chris-munns-devops-amaz...

Reply on news.ycombinator.com