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

51–60 of 130 posts

Re: Meta’s Microservice Architecture [pdf]

#51

Post by whstl »

gjvc wrote: post #28
whstl wrote: post #20

Earlier quoted context omitted.

Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue. Doesn't mean that Dijkstra was wrong, or that they are the same as goto. Also, throw/catch do quite more than a goto, though. It's not only about stack unwinding, it's about the ergonomics of not needing code that uses throw to have any information about where catch is located. Sure you can simulate some use cases of try/catch…

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

Re: Meta’s Microservice Architecture [pdf]

#52

Post by jcparkyn »

YetAnotherNick wrote: post #49
spion wrote: post #38

Earlier quoted context omitted.

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…

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

Re: Meta’s Microservice Architecture [pdf]

#53

Post by jcparkyn »

fvdessen wrote: post #24
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".

The thing is they are not harmful, they are valuable above a certain scale. To caricature, monoliths scale with O(n) and microservices O(nlogn). At some point the lines cross and microservices start to get better. The problem is there's no clear answer to where is that point as it also depends on the product being built and other company specifics. But I wouldn't see it being usually worthwhile below a hundred devs.

Your analogy is backwards, nlogn > n.

Re: Meta’s Microservice Architecture [pdf]

#54

Post by jcparkyn »

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

Any purely functional app still needs a mutable data store _somewhere_. And if that's all owned by one service (the "root" of your functional app, since everything else is pure by definition), then you're hardly doing microservices.

Re: Meta’s Microservice Architecture [pdf]

#55

Post by randomdata »

whstl wrote: post #20
randomdata wrote: post #5

Earlier quoted context omitted.

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

Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue. Doesn't mean that Dijkstra was wrong, or that they are the same as goto. Also, throw/catch do quite more than a goto, though. It's not only about stack unwinding, it's about the ergonomics of not needing code that uses throw to have any information about where catch is located. Sure you can simulate some use cases of try/catch…

> Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue.

Not within the context of discussion, where goto refers to the harmful kind. Throw/catch exhibits the very problem Dijkstra was talking about, with execution jumping all over the place haphazardly. Functions, conditions, iteration, break/continue, even (C-style) goto does not exhibit the same problem. They are strictly bridled in the execution scope.

There is good reason why modern languages are moving away from throw/catch. However, there is little question that it is still widely used at this time.

Re: Meta’s Microservice Architecture [pdf]

#56

Post by randomdata »

gordian-not wrote: post #16
randomdata wrote: post #5

Earlier quoted context omitted.

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

Aren't you talking about break and continue? throw and catch unwind the stack and goto doesn't

break, continue, and even goto in any language created in the last several decades cannot leave the current function. These are not what Dijkstra was talking about. Dijkstra wrote the piece when structured programming was just starting to become a thing and was urging people towards it. Think more like goto in BASIC, where there is no bridling of the operator.

Re: Meta’s Microservice Architecture [pdf]

#57

Post by mrits »

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

You don't need microservices to address any of that.

I would argue that microservices make it harder for different outsourced teams to work together.

I tend to agree with OP in that microservices really slow down a smaller team and more aligned with helping giant teams function.

Re: Meta’s Microservice Architecture [pdf]

#58

Post by RansomStark »

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

1. You're building a product that touches multiple deep domains and the business has modelled a very aggressive headcount growth

That feels like premature optimization; split when you need to and not before

2. You've outsourced a large portion of your development to a number of agencies

Then your developer count is likely not in the 10s (you need to could the agency developers), plus if you've already outsourced your development in that manner, it suggests you already chose a micro-services architecture and tendered accordingly, this feels like a post hoc justification.

3. You have a team of individuals who know nothing but microservices

If a team can build a set of microservices, they can build a monolith, the skill sets are not that different, a microservice is after all just a really small monolith.

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

That's an interesting one, you're trading technical complexity for compliance, and it may well be a use case, there is not enough data to comment here. But there are many ways to be compliant with , micro-services might be one, but is it the optimal solution for all involved, well that depends...

5. You're building anything to do with image processing at scale

This doesn't require micro-services, it probably requires horizontal scalability, if its offline processing you might want a batch process you can turn on and off as required, but that doesn't have to mean microservices, at this point it becomes a semantic argument of what constitutes a microservice, but I would argue the idea of batch processes predates the idea of microservices. Also just because you might need to use microservices in a small part of your application stack, the rest of the solution can still be a monolith: a hybrid architecture if you will.

6. You are a subsidiary owned by a parent company with tons of experience and tooling for microservices

Again, if you have tons of experience with microservices that can be easily translated to monoliths, just build a microservice but bigger

7. One of your VCs has offered up a dev team they own to speedboat your MVP, who specialize in microservices

It its 10 devs or less, does it matter, build a monolith and optimize when it makes sense to do so

8. You've received a buyout offer by a party interested in specific IP within your product, with the condition that the IP is isolated from other parts of the system

Unless that is your goal from day 0, I'm not sure how you could anticipate this, again this feels like a post hoc justification. If, in the unlikely event that that situation occurs, that might be a good time to consider splitting out that functionality.

Re: Meta’s Microservice Architecture [pdf]

#59

Post by philjohn »

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.

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.

Re: Meta’s Microservice Architecture [pdf]

#60

Post by neon_electro »

SanderNL wrote: post #6
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.

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?
Post reply on HN