Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meta’s Microservice Architecture [pdf]

usenix.org

Post reply on HN
Print view View original

61–70 of 130 posts

Re: Meta’s Microservice Architecture [pdf]

#61

Post by patmorgan23 »

randomdata wrote: post #5
danwee wrote: post #3

Earlier quoted context omitted.

Indeed, but I think we are too late for that. It's not like the usage of GOTO: someone who mattered wrote that its usage should be considered harmful, and hence nowadays GOTO has practically a niche usage. If only someone that mattered would have written on time an essay titled "Microservices Architecture Considered Harmful".

> hence nowadays GOTO has practically a niche usage. Except where it was rebranded as throw/catch. There, goto remains quite popular. All while bridled (C-style) gotos were considered acceptable by Dijstrka, but are now looked upon with disdain. Amazing what a little marketing can do.

Throw is much worse than GOTO. GOTO is explicit you always know where it goes. Throw has no idea where catch is and catch has no idea where throw is. It's hidden control flow.

Go/Rust/Zig Errors as values is a much better system forcing you to explicitly deal with the error, crash or pass it on. Rather than hoping you handled all the correct exceptions/someone else will handle all of them.

Re: Meta’s Microservice Architecture [pdf]

#62

Post by collyw »

rapsey wrote: post #2

So many companies shoot themselves in the foot chasing Google/Meta/Netflix backend architectures. If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture.

Agreed. In my last company we had everything running in Kubernetes, despite having less than 300 active users. It did have some benefits, but scaling wasn't one that we needed and did cost lot of developer time. Debugging is painful.

Re: Meta’s Microservice Architecture [pdf]

#63

Post by 0xbadcafebee »

neon_electro wrote: post #60
SanderNL wrote: post #6

Earlier quoted context omitted.

I count myself among those who are almost irrationally opposed to microservice anything. However, in my quest for the holy monolith I came across small teams who against all odds were adequately functional despite this heretical paradigm. They were definitely building a distributed monolith which was a monster to run locally. But, it worked. They were shipping and most importantly it matched their culture of small is…

Did it seem like that team was aware of Conway's Law and was actively considering it in their architectural/system design decisions?

They can consider it all they want, that won't change the outcome. It is inevitable.

Re: Meta’s Microservice Architecture [pdf]

#64

Post by collyw »

YetAnotherNick wrote: post #19
rapsey wrote: post #2

So many companies shoot themselves in the foot chasing Google/Meta/Netflix backend architectures. If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture.

This is hn so obviously your comment has to be the top voted comment. I am really tired of this trend here. No. microservice vs monolith is not the deciding factor of the developer speed or bugs. It wouldn't even be top 5 factor for good developers. Difference between microservices and monolith technically is just network rpc rather than function call. In itself, it doesn't make much of a difference. If a developer f…

The more services you have, the more of a nightmare your development environment takes to set up. Network calls are a lot less reliable than function calls.

Re: Meta’s Microservice Architecture [pdf]

#65

Post by treis »

philjohn wrote: post #59
fvdessen wrote: post #35

Earlier quoted context omitted.

That also works with monoliths ... Usually you would make your monolith stateless and distribute the incoming requests / events across many instances that can be spawned / killed depending on volume of requests and health status of instances.

In a past job, the benefit of microservices was that some of the operations performed by the system were fare more CPU intensive than others - by having them in their own service that could be scaled independently led to lower overall hardware requirements, and made keeping latency of the other services sensible much easier.

You can scale monoliths independently too. Depending on the language that means paying some additional memory overhead for unused code but practically it's small compared to the typical amount of ram on a server these days.

Re: Meta’s Microservice Architecture [pdf]

#66

Post by 0xbadcafebee »

YetAnotherNick wrote: post #48
vilunov wrote: post #27

Earlier quoted context omitted.

Placing a network call in your system also introduces: - distributed systems problems - think consistency and ACID - increased refactoring complexity - you now have to change the api three times instead of 1 to deploy the change with 0 downtime - requirements for more generic CI/CD pipelines - you will develop many microservices, it's important to do it fast it's not "just" a network rpc, even technically

> it's not "just" a network rpc, even technically Except is is. Microservice doesn't mean distributed setup. For the first problem, yes service running in multiple pods causes issues, but even monolith could face the same issue. Statefulset based microservices not only exists, but is a pretty common setup. Also I would even call multiple container on the same pod as microservice, which basically solves all of the pro…

Except it isn't, because a microservice requires an isolated dataset, API abstraction, documentation, versioning, consumer contract, dependency chain, complex release management. It's a radically different design because it forces you to develop the entire system differently to deal with very different abstractions, ways of working, expectations.

A distributed monolith is simpler, but simultaneously more buggy than a centralized monolith.

Re: Meta’s Microservice Architecture [pdf]

#70

Post by outworlder »

rapsey wrote: post #2

So many companies shoot themselves in the foot chasing Google/Meta/Netflix backend architectures. If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture.

Many companies implement microservices for the wrong reasons. The most common reason is because other companies are doing it. The second most common bad reason is because business units don't want to talk to one another. AKA they are shipping their org chart.

It's great for cloud providers too. It's often cheaper to just run entire copies of monoliths than it is to run microservices. All that synchronization and API calls has a huge cost, even more so when you add support infrastructure (RMQ? Kubernetes?)

Most companies would work just fine with a monolith, with the occasional service split off from that when it makes sense.

Post reply on HN