Live data from Hacker News

Meta’s Microservice Architecture [pdf]

usenix.org

1–10 of 130 posts

Re: Meta’s Microservice Architecture [pdf]

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

Re: Meta’s Microservice Architecture [pdf]

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

It often ends up as a micro/monolith, a hybrid architecture with few benefits and many costs especially around deployment and distributed tracing, with many resumes polished on the way, but at least the return to a sensible monolith isn't quite as far.

Re: Meta’s Microservice Architecture [pdf]

#5
post #3
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".

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

Re: Meta’s Microservice Architecture [pdf]

#6
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 isolated islands of functional specialists with as little communication between them as possible.

I will refrain from commenting on the virtue of communicating as little as possible, but sometimes you just got to make the best of a situation.

Re: Meta’s Microservice Architecture [pdf]

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

Why is that? Can you point me to some material that explains this in detail?

Re: Meta’s Microservice Architecture [pdf]

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

but... but we'll need this so we can cope with webscale request volumes when our product (that has zero customers currently) launches and immediately goes viral!

(/s, obviously, but I've heard variations on this plenty of times)

Post reply on HN