←back to thread

873 points belter | 1 comments | | HN request time: 0.228s | source
Show context
Sparkyte ◴[] No.42958767[source]
Most to all I agree. I disagree with monoliths and microservices. I am not a fan of microservice per se but I'm not a fan of monoliths either. I certainly prefer a mix depending on their use cases. However both designs deserve equal scrutiny.

My monolith horror started when I was working with Ruby developers. The problem with a monolith is when it becomes too big for itself. Realistically something between microservices and monoliths are where quality of life resides.

If you need a small service that needs to be fast and focused microservice it. If you need a service where it relies heavily on the same logic and shared across many things. As long as it is performant, modular and easy to fix, monolith it.

Either way conforming to one design certainly cripples the potential of services.

replies(1): >>42961537 #
notTooFarGone ◴[] No.42961537[source]
You can build everything the wrong way. In my experience making a monolith modular is organizationally easier than gluing together microservices and step on various toes and getting rid of needless abstractions.
replies(1): >>42967752 #
1. Sparkyte ◴[] No.42967752[source]
Right, that part I agree with.

Microservices if used sparingly in the right way are fantastic as they can offer flexibility in APIs that do not necessarily need a monolith obfuscating certain behaviors away from the monolith making the architecture more secure.

Everything needs to be purposefully built and used with the intention of serving the customer's needs without compromise.