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

121–130 of 130 posts

Re: Meta’s Microservice Architecture [pdf]

#121

Post by jamjamjamjamjam »

mostlysimilar wrote: post #97
jameshart wrote: post #74

Earlier quoted context omitted.

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.

What are you monitoring your monolith for? For microservices you can monitor specific metrics related to the exact function, and perform health checks, scaling events accordingly.

For monoliths you cant be as specific. “Is the response a 500” doesn’t really cut it. “Average request latency” for scaling doesn’t cut it when some of your queries are reads and then some are completely unrelated mass joins.

Re: Meta’s Microservice Architecture [pdf]

#122

Post by gjvc »

whstl wrote: post #51
gjvc wrote: post #28

Earlier quoted context omitted.

> Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue. That's like saying all maths is just the application of addition.

Yeah. It’s a useless pedantism that serves no purpose in most discussions. That’s what I have “rebranded goto” in quotes. And that’s what I address in the second paragraph.

it failed to satisfy me

Re: Meta’s Microservice Architecture [pdf]

#123

Post by another2another »

jcparkyn wrote: post #52
YetAnotherNick wrote: post #49

Earlier quoted context omitted.

> - 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…

> Yes. I don't see how this is different than function call. If you need atomicity _across services_ it's very different, hence why everyone resorts to eventual consistency and all the associated extra complexity. If there's a decent way to have true transactions that span multiple services, I've certainly never seen it.

You can get Distributed Transaction Coordinators (e.g. MSDTC on Windows), but it will make everything much slower.

Re: Meta’s Microservice Architecture [pdf]

#124

Post by randomdata »

o1y32 wrote: post #90
patmorgan23 wrote: post #61

Earlier quoted context omitted.

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.

If this were a top level comment I am sure you'll get 20 people disagree with you on this

Even Dijkstra followed up the "Go To Statement Considered Harmful" letter with the "On a Somewhat Disappointing Correspondence" letter because "20" people disagreed with him.

There will always be naysayers. The above is starting to become generally accepted, though, and modern languages are moving away from the practice just as languages moved away from unbridled gotos.

Re: Meta’s Microservice Architecture [pdf]

#125

Post by rewmie »

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?

> Conway's Law

It can be the cause or the consequence. If your team peels a microservice out of a monolith and assign a couple of developers to work on the newly-created service, those guys will be heads down on their work and focusing on their project.

If management does not go out of it's way to rotate people around projects, you'll end up with ad-hoc organizations around their service architecture.

Re: Meta’s Microservice Architecture [pdf]

#126

Post by rewmie »

outworlder wrote: post #70
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…

> The second most common bad reason is because business units don't want to talk to one another.

This sounds like a terribly naive take.

It matters nothing if units talk to one another. Nothing. All it matters is ownership and accountability. What happens if the service managed by team A goes down and takes the whole org with it? Is team B going to take the blame because one of their developers posted a PR to tweak the project's README?

Re: Meta’s Microservice Architecture [pdf]

#127

Post by yuliyp »

MarkSweep wrote: post #86
phyrex wrote: post #25

I find this highly misleading, Facebook is famously a big monolith, and I think so is instagram. There’s plenty of services and a couple micro services as well, but I don’t think anybody would characterize meta as having a micro services architecture. I have no idea what the authors’ agendas are, but something isn’t right there.

The article mentions that www, the monolithic PHP code base, is 4.6% of the service instances. Though the paper does not mention the compute allocation. I do not recall how www is deployed, but it’s easy to imagine it’s allocated a lot more resources than a lot of other services are.

Large, unsharded services are generally going to run one instance per machine alone as that's the most efficient way to run most of them (reduce per-instance overhead as much as possible). Small (true "micro") services or other things which have instances per use case (like the inference platform example given in the paper) may use a small fraction of a machine.

Re: Meta’s Microservice Architecture [pdf]

#128

Post by philjohn »

treis wrote: post #92
RicDan wrote: post #87

Earlier quoted context omitted.

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.

To be fair, with libraries the API layer can be essentially zero code, and with type checking. That's how it worked when I was at my previous gig.

Re: Meta’s Microservice Architecture [pdf]

#129

Post by philjohn »

fvdessen wrote: post #100
RicDan wrote: post #94

Earlier quoted context omitted.

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.

That's just for the interface layer though.

Re: Meta’s Microservice Architecture [pdf]

#130

Post by MBCook »

rewmie wrote: post #126
outworlder wrote: post #70

Earlier quoted context omitted.

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…

> The second most common bad reason is because business units don't want to talk to one another. This sounds like a terribly naive take. It matters nothing if units talk to one another. Nothing. All it matters is ownership and accountability. What happens if the service managed by team A goes down and takes the whole org with it? Is team B going to take the blame because one of their developers posted a PR to tweak t…

It’s real. I’ve seen it.

They can’t get their internal silos to work together on a single project, so they have each silo make services for the others to use in service of the project they’re trying to make that needs multiple teams.

But… all the same problems come up. Teams building to their requirements and not what the consumers need, refusal to cooperate in design/requirements/etc, scheduling issues or project priority issues.

“Microservices are cool and what Google does and will help us avoid our organizational issues” is very loosely paraphrased from what I heard as the exact pitch for why it was being used.

Post reply on HN