back

by surprisetalk·3y ago·view on hn ↗
I used to work at Pex, where microservices were done beautifully.

Pex's microservice architecture scaled tremendously. Their product crawls and processes all the audio and video produced on the entire internet in near-real-time.

> Are microservices inherently bad or your criticism might come from a terrible implementation you've had to suffer?

Microservices are not inherently bad.

> In an ideal scenario where said implementation and architecture is well designed and robust, would you enjoy working with them?

I think Pex's microservice architecture was as good as it gets... and I decided that I wanted to avoid distributed systems for the rest of my life haha

> Do you think, honestly, that it is just a trend that comes from the big companies and book sellers and eventually will dissapear and there is no a real need for it for the vast majority of cases?

Microservices seem to be great for giant backbone/infrastructure stuff like Netflix, AWS, Pex, Cloudflare, Squarespace, etc.

Sometime managers shout "conway's law" and decide they need hard network boundaries. I'm unsure what to tell those teams.

Many engineers trick themselves into thinking that their company is special and needs the extra scalability or whatever, when it's simply not true. If your problem can be solved by load balancers or caching or DB indexes, you are not even close to needing microservices.

In my experience, monoliths seem to be the right choice for 99% of cases.

1 comments
>I used to work at Pex, where microservices were done beautifully.

Would love to read about this architecture. Is there a blog post you can link to?

>If your problem can be solved by load balancers or caching or DB indexes, you are not even close to needing microservices.

It's funny, do people not know about this stuff anymore? It's the low hanging fruit for scalability.

> Would love to read about this architecture. Is there a blog post you can link to?

I don't think they have any blog posts about it, but the CEO/architect doggedly pursued simplicity.

There was a single pub-sub messaging bus and a bunch of VMs in autoscaling groups. There were 2 databases optimized for different workloads. That's pretty much it.

> It's funny, do people not know about this stuff anymore? It's the low hanging fruit for scalability.

People tend to diagnose themselves with "special" diseases, whose treatments won't work for "common folk" :) I've done it myself plenty of times haha