Hacker News Reader

Comment by fdgsdfogijq | Hacker News Reader

It took me a while to accept that microservices are better. Not in every case, but in a surprising number of cases. They really shine when combined with serverless computing. Clear seperation of code by a networking call is the next logical step in the encapsulation principle of object oriented programming. We hide the implementation details and only expose an interface, which creates seperation and forces us to stop sphagetti logic. Microservices are the enxt step in that design pattern, and only with the improvement in container technology and cloud computing has this become achievable (in the sense of there not being so much operations and complexity overhead).

View on HN

A size 20 shoe is better for a large foot... But not better for a size 15 or size 10 foot.

Saying Microservices are better is the same as me saying "a size 20 shoe is better than any other shoe"... for everyone.

It's not a viable statement in any use case, except for people with size 20 feet.

The business need is what determines the solution necessary.

I know its not a catch all. But more often than I would like to admit they bring simplicity and reduce complexity. The more I develop software, the less I can stomach monoliths running on some big server. The other day I was considering deploying an MVP I have written on Django, and instead just ripped it apart and pushed the pieces into their own seperate lambdas. Deploying some monolith API like that was nerve wrecking, updates are, the blast radius is higher, and the composability of components is easier with smaller microservices.

I think the catch is that "Services" are typically the scope at which encapsulation should stop.

They don't need to be "Micro".

This is just arguing over the service boundary definition and not the architecture. There are multiple comments here trying to differentiate between a "service" and a "microservice" which seems like a fools errand to me.

> Clear seperation of code by a networking call is the next logical step in the encapsulation principle of object oriented programming.

You can have clear separation at the import/library level though. No need to add that extra latency to every call.

Separating services with network requests doesn’t stop you having “spaghetti logic”. All it does instead is add more spaghetti and put it in different bowls.

I hope you're trolling.

If not, enjoy implementing joins across services.

Doesn't this just mean you picked a bad service boundary? You shouldn't have to join across services, ever.

Seems like a straw man.

"just picked a bad service boundary" -- well that's the thing isn't it. If you always pick the right boundary up front, something that is perfect both now and also anticipates any kind of future crazy feature request -- if you can pull that off I'd say any architecture will work well.

But most people get boundaries wrong some times. Sometimes very badly wrong. Sometimes the boundaries are historical, set by product owners without technical input, set by junior developer, set by superficial attributes, and sometimes even the most experienced developer-architect just does a mistake.

And the whole point of not doing microservices is you don't have a huge investment in your boundaries, it's more feasible to change them once you inevitably now and then realize you got them wrong.

Isn't the point of making services as small as possible so that you can easily shift boundaries? Isn't DDD (a common companion of microservices) all about constantly shifting business domains?

We've gotten boundaries wrong tons of times. We change them, which includes a migration script to move historical data from one service to another, if possible. Yes, it's work, but it's not any more work than having everything crammed into the same monolith and having to deal with all the downsides therein.

Well the parent talked about not joining across services. Then there are hard limits to how small you can make them.

And what need to join with what is something that can change.

So if you make services very small, and no joins across services, you get a lot of copies of the same data everywhere...

And if you make the services too small you have just moved the exact patterns you would have inside a monolith to into your APIs..how can that be easier?

You say "downsides of monoliths" but monoliths isn't a homogenous thing, they come in all shapes and varieties. So does microservices.

Myself I happen to have experienced microservices systems that are a real mess, and pretty clean monolith designs. Consider for instance an event sourced service where every endpoint a) reads events from database, b) if business rules allows (involving possibly external calls) writes an event to the database. No CRUD. This pattern keeps every handler/business rule reasonably isolated from other, and it doesn't matter if it runs in 1 or 10 services...

It will eventually happen even if you manage to create the perfect boundaries, e.g for report & statistics.

You shouldn’t be doing report and statistics on live data, but in a data warehouse.

Reports and statistics, especially on material that crosses service boundaries (but even on single-service information, to keep services single-responsibility) are their own logical services, which operate on copies of data received from (often multiple) upstream services. (In many real world cases, you’ll want this functionality in a data warehouse, but there are some cases where some of it may be in something that looks like normal services, whose data that can change other than by push from other services deals with reporting and report-delivery configuration, not the business data on which reporting is done.)

Reply on news.ycombinator.com