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

21–30 of 130 posts

Re: Meta’s Microservice Architecture [pdf]

#21

Post by onion-soup »

YetAnotherNick wrote: post #19
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.

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…

We all appreciate your contribution to micro services. But let us now choose simplicity and move on with our lives. You do you with your zoo of dockerized babel towers

Re: Meta’s Microservice Architecture [pdf]

#22

Post by onion-soup »

FragrantRiver wrote: post #17
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.

Microservices are great, even for small companies. Change my mind.

You can safely continue your professionnal jjourney elsewhere but not in IT. Thank you!

Re: Meta’s Microservice Architecture [pdf]

#23

Post by YetAnotherNick »

onion-soup wrote: post #21
YetAnotherNick wrote: post #19

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

We all appreciate your contribution to micro services. But let us now choose simplicity and move on with our lives. You do you with your zoo of dockerized babel towers

I use monolith 90% of the time. I think you missed my point. I just said that I could be similar level of productive in well thought of microservices division.

Re: Meta’s Microservice Architecture [pdf]

#24

Post by fvdessen »

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

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.

Re: Meta’s Microservice Architecture [pdf]

#25

Post by phyrex »

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.

Re: Meta’s Microservice Architecture [pdf]

#26

Post by fvdessen »

YetAnotherNick wrote: post #19
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.

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…

The fact some people think there's little difference between function calls and RPCs is exactly why microservices is such a dangerous idea.

Re: Meta’s Microservice Architecture [pdf]

#27

Post by vilunov »

YetAnotherNick wrote: post #19
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.

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

Re: Meta’s Microservice Architecture [pdf]

#28

Post by gjvc »

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.

That's like saying all maths is just the application of addition.

Re: Meta’s Microservice Architecture [pdf]

#29

Post by DeathArrow »

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.

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. In fact, at one of my workplaces we had much more issues with a monolithic app than with the microservice based app we replaced it with.

Re: Meta’s Microservice Architecture [pdf]

#30

Post by solumunus »

YetAnotherNick wrote: post #19
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.

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…

It's not "just". The network calls introduces all sorts of added complexity.
Post reply on HN