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

91–100 of 130 posts

Re: Meta’s Microservice Architecture [pdf]

#91

Post by fvdessen »

nonameiguess wrote: post #84
jcparkyn wrote: post #53

Earlier quoted context omitted.

Your analogy is backwards, nlogn > n.

This comment was grayed out at the time I upvoted and am commenting. Either readers don't appreciate pedantry or don't realize what the point was, but for any n > 2, n * logn is a larger number than n. I believe what the original poster meant to say was microservices grow like O(klogn) and monoliths O(n), i.e. microservices have some upfront constant cost that is large enough that, for small projects, monoliths will…

Indeed that's what I meant, but cannot edit my comment.

Re: Meta’s Microservice Architecture [pdf]

#92

Post by treis »

RicDan wrote: post #87
treis wrote: post #85

Earlier quoted context omitted.

You do spawn a new monolith. You make one group the CPU intensive one and route that traffic there. Same concept as a microservice except that it comes with a bunch of dead code. But the dead code is not that resource expensive these days.

I see, so basically we are applying scaling, but instead of scaling the bottleneck as its own part we scale everything. I somewhat fail to see how that saves much effort; routing setup sounds like a hassle. What we‘re using at my work is just a mono repo with all services in it, which works pretty well, and we‘re like 7 BE devs

You don't have to write an API layer and get type checking among some other benefits. Is it a ton of savings? No, but I'd describe it as a significant amount of effort and lower complexity.

Re: Meta’s Microservice Architecture [pdf]

#93

Post by jerf »

0xbadcafebee wrote: post #63
neon_electro wrote: post #60

Earlier quoted context omitted.

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.

You can't avoid its impact, but you can either work with it or work against it. I assume that was more the point.

Re: Meta’s Microservice Architecture [pdf]

#94

Post by RicDan »

charcircuit wrote: post #83
RicDan wrote: post #78

Earlier quoted context omitted.

Please elaborate on that. Without spawning a new monolith, how do you scale it. Add more resources?

You run another instance of it.

So you have to take care of routing etc.

I see how it works, and I completely agree that to start out, so going from PoC to first business implementation, a monolith is the way to go (unless the goal from the start is 100 million concurrent users I guess).

But after that initial phase, does it really matter if you use one or the other? You can overengineer both and make them a timesink, or you can keep both simple. I do agree on things like network latency adding up, but being able to completely isolate business logic seems like a nice gain. But Im also not talking about real micro level (i.e. auth login and registration being different services), but more macro (i.e. security is one, printing another(pdf,csv,word etc), BI another one

Re: Meta’s Microservice Architecture [pdf]

#95

Post by pjmlp »

scns wrote: post #11
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 may know it but for those that don't: Enjoy https://www.youtube.com/watch?v=y8OnoxKotPQ

I discovered it a couple of weeks ago. It is great.

Re: Meta’s Microservice Architecture [pdf]

#96

Post by gordian-not »

randomdata wrote: post #88
gordian-not wrote: post #75

Earlier quoted context omitted.

Yes, however I am not sure if Dijkstra meant goto in the sense of jump outside of a function. I don't know enough about Algol 60 and languages of the time, but if you allow usage of goto between different functions you will have a corrupt stack in no time, so I'll be surprised if it was implemented. Going back to the original discussion, my point was that the only statements that are real gotos still in usage (except…

Functions do not exist in the context of the "Go to statement considered harmful" paper, so there is no good analog in there. Further, he is specific that it is only about unbridled gotos. continue and break are decidedly bridled. In reality, the paper just doesn't apply to any language created in the last several decades, even those which use the goto keyword. We bought in to structured programming. Except I posit t…

I agree about the somewhat unexpectedness of exceptions, although it is much structured than gotos (you just go up the stack)

virtual polymorphism for example is completely unexpected, as well as function pointers and other constructs that in my opinion are harder to track than exceptions

Re: Meta’s Microservice Architecture [pdf]

#97

Post by mostlysimilar »

jameshart wrote: post #74
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.

When you kill a monolith you kill a random selection of inflight tasks from every part of your application. So a rare bug in your mailing list signup workflow that hangs the process and causes it to be killed causes a random selection of inflight webpage requests, payment transactions, message handlers and business processes to fail. And if those failures aren’t all cleanly handled, your mailing list signup bug could…

The original statement was "service is not answering for a certain amount of time". If the instance of your monolith is not responding you're probably already in a bad state and can reasonably kill it.

Re: Meta’s Microservice Architecture [pdf]

#98

Post by pjmlp »

danwee wrote: post #3
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.

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

Thing is, contrary to GOTO, microservices help selling books, conferences and consulting services.

Re: Meta’s Microservice Architecture [pdf]

#99

Post by belter »

scns wrote: post #11
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 may know it but for those that don't: Enjoy https://www.youtube.com/watch?v=y8OnoxKotPQ

As somebody said in the comments..Not a Comedy but a Documentary....

Re: Meta’s Microservice Architecture [pdf]

#100

Post by fvdessen »

RicDan wrote: post #94
charcircuit wrote: post #83

Earlier quoted context omitted.

You run another instance of it.

So you have to take care of routing etc. I see how it works, and I completely agree that to start out, so going from PoC to first business implementation, a monolith is the way to go (unless the goal from the start is 100 million concurrent users I guess). But after that initial phase, does it really matter if you use one or the other? You can overengineer both and make them a timesink, or you can keep both simple. I…

Interestingly Meta went with a django monolith for their new app and their goal was definitely in the order of 100 million concurrent users.
Post reply on HN