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

41–50 of 130 posts

Re: Meta’s Microservice Architecture [pdf]

#41

Post by Cthulhu_ »

solumunus wrote: post #30
YetAnotherNick wrote: post #19

Earlier quoted context omitted.

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…

It's not "just". The network calls introduces all sorts of added complexity.

Dangerously hidden behind some microservices architectures / frameworks, sometimes, that promise to fix or at least hide all these complexities for you.

Re: Meta’s Microservice Architecture [pdf]

#42

Post by Cthulhu_ »

AndrewPGameDev wrote: post #36

I've had this thought for a long time that if you have a completely functional code base (as in no side-effects), making the decision between a microservice approach and a monolith approach is fundamentally transparent. Any functional code can not only be split onto multiple threads, but multiple servers (at the cost of latency).

This was the Scala / Akka approach, I'm sure there's similar ones in other languages; basically you'd work via communicating, 'pushing' messages to actors instead of calling functions. From a developer's point of view, it then didn't matter if that message went to an actor on the same machine or something halfway across the world. "Don't communicate by sharing memory, share memory by communicating." is the modern adage.

Re: Meta’s Microservice Architecture [pdf]

#43

Post by Cthulhu_ »

gigatexal wrote: post #14

obligatory: you are not Netflix/Meta/Google... so you don't need to do this architecture for your own startup. Just spin up a monolith until you have something that needs breaking down and even then it might not need it or you might pivot to doing something else entirely.

Exactly that. I also think a lot of developer teams are both too big, too unorganized, and not diligent enough so they start to interfere with each other's work, causing them to want to have their own codebase. But no, you need a strong lead developer and development practices. There may be too many cooks in the kitchen as well, at which point you should probably consider downsizing.

Re: Meta’s Microservice Architecture [pdf]

#44

Post by eldenring »

AndrewPGameDev wrote: post #36

I've had this thought for a long time that if you have a completely functional code base (as in no side-effects), making the decision between a microservice approach and a monolith approach is fundamentally transparent. Any functional code can not only be split onto multiple threads, but multiple servers (at the cost of latency).

Multiple servers adds a pretty hefty layer of networking, orchestration, security, failure handling (even in the datacenter), and serialization - even if the business logic stays mostly the same.

Re: Meta’s Microservice Architecture [pdf]

#46

Post by tomthumb »

fvdessen wrote: post #35
DeathArrow wrote: post #33

Earlier quoted context omitted.

Simple, if a service is not answering for a certain amount of time, a new Kubernetes pod is brought up and the old one is killed. :)

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.

The same logic holds true for micro services. Statelessness is the key. But most micro services implementations end up being distributed monoliths

Re: Meta’s Microservice Architecture [pdf]

#47

Post by rkwz »

lijok wrote: post #37
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.

> If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture. Such a strong statement. Might a lack of industry experience be driving such strong convictions of yours? Here are some reasons, off the top of my head, why a company would want to embrace microservice architecture, with all its benefits and complexities, with a developer count in the 10s: 1. You'…

> Your chief compliance officer is intimately familiar with the data protection benefits that microservices bring and is leaning heavily into it in their regulatory submissions as a way to compensate for some other gap in the business

Just curious, how does microservices help here?

Re: Meta’s Microservice Architecture [pdf]

#48

Post by YetAnotherNick »

vilunov wrote: post #27
YetAnotherNick wrote: post #19

Earlier quoted context omitted.

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…

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

There are many ways to solve second problem. Some folks create different API version. I prefer different deployment.

Last is a problem for monolith. I know of big companies where compile time is in order of an hour for monolith, even for small change.

Re: Meta’s Microservice Architecture [pdf]

#49

Post by YetAnotherNick »

spion wrote: post #38
YetAnotherNick wrote: post #19

Earlier quoted context omitted.

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…

A few questions if its the same... - In case of errors, do we get a full backtrace of function calls across service boundaries? - Is the function call as cheap as passing an argument? What if we're passing 1KB? 1MB? 1GB? - Can we use a debugger to step in and out of those functions? - Can we spin up a simple test runner to integration test a few levels of function calls together? Preferably something like Jest that h…

> - In case of errors, do we get a full backtrace of function calls across service boundaries?

Unless you don't discard the error, then yes

> - Is the function call as cheap as passing an argument? What if we're passing 1KB? 1MB? 1GB?

No it is not. In general microservice costs are bit higher.

> Can we use a debugger to step in and out of those functions?

You could trace across services but passing the context. Also attaching debugger is possible afaik.

> Can we spin up a simple test runner to integration test a few levels of function calls together?

I use docker compose and it can be done

> - Can all database modifications run in a single transaction so that we know that either all of them happened or none at all?

Yes. I don't see how this is different than function call.

Re: Meta’s Microservice Architecture [pdf]

#50

Post by lijok »

rkwz wrote: post #47
lijok wrote: post #37

Earlier quoted context omitted.

> If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture. Such a strong statement. Might a lack of industry experience be driving such strong convictions of yours? Here are some reasons, off the top of my head, why a company would want to embrace microservice architecture, with all its benefits and complexities, with a developer count in the 10s: 1. You'…

> Your chief compliance officer is intimately familiar with the data protection benefits that microservices bring and is leaning heavily into it in their regulatory submissions as a way to compensate for some other gap in the business Just curious, how does microservices help here?

Great question. Two things you're aiming for with a regulatory submission: 1) Get it approved. 2) Receive back as few rounds of questions as possible from the case officer, as each round delays approval. You can improve 2) by painting a very clear and concise narrative around key concerns pertaining to the particular application you're submitting. Microservice architecture helps to paint that narrative (for CCOs that understand them) as at the high level, it addresses the key concerns (primarily data protection) with simple to convey concepts such as data segregation, service ownership, etc. The implementation of those controls is not as simple, but for the regulatory application, all that matters is that they are sound in practice and simple to convey.
Post reply on HN