One of the services exposes 11,359 endpoints. Well, one interpretation is that Meta runs predominantly on a monolith but has factored out a few services.
that's exactly what it is
Meta’s Microservice Architecture [pdf]
71–80 of 130 posts
Re: Meta’s Microservice Architecture [pdf]
#72So 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.
For us at my present and former workplaces, the decision of using microservices didn't depend solely on number of developers. We needed something very scalable, something that different teams can work on without stepping on each other's foot, something that survives even if part of it fails temporarily, something that auto-heals. We did it with developers in the tens and we didn't have much issues with this approach.…
> something that different teams can work on without stepping on each other's foot
In other words, different teams don't want to talk to one another. That's not really a good reason for having 'micro' services.
You can also self-heal monoliths. In fact, it's much easier to do that with a monolith.
Re: Meta’s Microservice Architecture [pdf]
#73So 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
Is there some Firefox mod that reads that y8Onox... part and displays something like "galactus" for easiness to reference?
The fact that one has seen the video doesn't make the link recognizable. (And that's a problem with Youtube.)
Re: Meta’s Microservice Architecture [pdf]
#74Earlier 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.
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 propagate into a much wider issue.
Whereas if you have a ‘mailing list service’ that has its own processes that can be killed and respawned, that bug only takes our mailing list processing. Which is good because the bug was probably made by the team who owns mailing list processing. And they can roll back their code and be on their way, with nobody else needing to know or care.
Re: Meta’s Microservice Architecture [pdf]
#75Earlier quoted context omitted.
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.
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 for C cleanup gotos) is break and continue, which even support labels
Re: Meta’s Microservice Architecture [pdf]
#76Earlier quoted context omitted.
For us at my present and former workplaces, the decision of using microservices didn't depend solely on number of developers. We needed something very scalable, something that different teams can work on without stepping on each other's foot, something that survives even if part of it fails temporarily, something that auto-heals. We did it with developers in the tens and we didn't have much issues with this approach.…
> something that different teams can work on without stepping on each other's foot In other words, different teams don't want to talk to one another. That's not really a good reason for having 'micro' services. You can also self-heal monoliths. In fact, it's much easier to do that with a monolith.
Talking and synchronizing dependencies, tools, and releases are different things.
Re: Meta’s Microservice Architecture [pdf]
#77Earlier quoted context omitted.
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.
No, this is not possible always.
- consider case where the task is CPU intensive but not so critical as to eat into other parts of the code
- consider the case where the task needs some data loaded for it to work. I don't think it is a good idea to have that data loaded into the monolith.
Re: Meta’s Microservice Architecture [pdf]
#78Earlier quoted context omitted.
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.
Please elaborate on that. Without spawning a new monolith, how do you scale it. Add more resources?
Re: Meta’s Microservice Architecture [pdf]
#79Earlier quoted context omitted.
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.
They're saying that microservices scale much worse than monoliths at the beginning, and need to reach a certain scale before they're worth the effort. The debate around is usually around where that inflection point is, and to a lesser degree if there are other non-scale advances to microservices that might make it worth adopting sooner.
Re: Meta’s Microservice Architecture [pdf]
#80I'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).
Except in the microservice approach with multiple servers you have introduced the possibility of network partitioning where microservice A can't reach microservice B. Unless your language/runtime model can deal with that you have hidden that error case in your abstraction. I think a lot of microservice architectures are implemented with the YOLO model where there is no thought to network errors and all calls are assumed to succeed.
Language/runtimes like Erlang & Elixir on the BEAM/OTP that were built with this in mind work well. They are completely functional with all state contained with lightweight processes and can send messages with timeout handling transparently across nodes in a cluster. With OTP you get a supervision tree for those processes that can automatically restart nodes and child processes of nodes.