[dead]
Meta’s Microservice Architecture [pdf]
31–40 of 130 posts
Re: Meta’s Microservice Architecture [pdf]
#32So 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.…
How the hell does microservices 'auto-heals' ? Do they autogenerate bug fixes and patch themselves ?
Re: Meta’s Microservice Architecture [pdf]
#33Earlier 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.…
How the hell does microservices 'auto-heals' ? Do they autogenerate bug fixes and patch themselves ?
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. :)
Re: Meta’s Microservice Architecture [pdf]
#34Earlier 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.
I think that's the point -- it's nearly as useless to call throw/catch a rebranded goto as it is anything else.
Re: Meta’s Microservice Architecture [pdf]
#35Earlier quoted context omitted.
How the hell does microservices 'auto-heals' ? Do they autogenerate bug fixes and patch themselves ?
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.
Re: Meta’s Microservice Architecture [pdf]
#36I'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).
Re: Meta’s Microservice Architecture [pdf]
#37So 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're building a product that touches multiple deep domains and the business has modelled a very aggressive headcount growth
2. You've outsourced a large portion of your development to a number of agencies
3. You have a team of individuals who know nothing but microservices
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
5. You're building anything to do with image processing at scale
6. You are a subsidiary owned by a parent company with tons of experience and tooling for microservices
7. One of your VCs has offered up a dev team they own to speedboat your MVP, who specialize in microservices
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
Re: Meta’s Microservice Architecture [pdf]
#38So 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.
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 has a watch mode so we can quickly run dozens of tests?
- Can all database modifications run in a single transaction so that we know that either all of them happened or none at all?
Re: Meta’s Microservice Architecture [pdf]
#39Earlier 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
If it's a network RPC style microservices architecture, you've built a distributed monolith; every service in a proper microservices architecture should be developed, maintained and deployed 100% independently from any other service. If two services are closely tied, they should be merged together.
Yes this causes overhead; every microservice will have a public API of sorts that will need to be documented and communicated, and any other service consuming it will need to eventually be updated to keep up with changes. If this overhead is not something your organization can afford, you should not be doing a microservices architecture.
Re: Meta’s Microservice Architecture [pdf]
#40One 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.