Hacker News new | ask | show | jobs
by sim7c00 618 days ago
its also easier to find devs that have the skills to create and maintain thin services than a large complicated monolith, despite the difficulties found when having to debug a constellation of microservices during a crisis.
2 comments

For the folks who downvoted this - why? I hire developers and this is the absolute truth of the matter.

You can get away with hiring devs able to only debug their little micro empire so long as you can retain some super senior rockstar level folks able to see the big picture when it inevitably breaks down in production under load. These skills are becoming rarer by the day, when they used to be nearly table stakes for a “senior” dev.

Microservices have their place, but many times you can see that it’s simply developers saying “not my problem” to the actual hard business case things.

You need those senior folks who can see the big picture, whether you use monoliths or microservices.

The real benefit of a microservice is that it's easier to see the interactions, because you can't call into some random and unexpected part of the codebase...or at least it's much harder to do something that's not noticeable like that.

At the cost of network boundaries everywhere, and all that entails
If there are network problems everything fails anyway, so it's not really an issue in production.

In the end, it depends on your skillsets. Most developers can't deal with a lot of complexity, and a monolith is the simplest way to program. They also can't really deal with scale, and cost of learning how to build a real distributed system is high...and the chances you'll hit scale are low.

So instead people scale horizontally or vertically, with ridiculously complicated tools like k8. K8 basically exists outside of google because developers can't write scalable apps, whether monolithic or microservice-based.

It's so funny we always use technical solutions to solve social problems, while confusing which parts are what. :)
My interpretation of Conways Law is that social problems) in development organizations) are isomorphic to (gross) technical problems, and that leverage works both directions.
> retain some super senior rockstar level folks able to see the big picture

This is the critical piece that many organisations miss.

Microservices are the bricks; but the customer needs those assembled into a house.

Btw, important factor: you can only see the big picture properly if you co-created the setup. Hiring senior rockstars as a reaction to problems will satisfy some short-term goals but not solve the problems overall
"I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of microservices?"
It's easier to find people who are confident that they understand a microservice, but the fact is that it interacts with the system as a whole and much of that interaction is dark matter. It's unknown unknowns that lead to Dunning-Kruger. People looking at a large system have more known unknowns and are less likely to be overconfident to the same degree.

Also we need to have about 5x as many people graduating with formal classes in distributed computing as are now or have been for the last several decades and it's just ridiculous how many people have to learn this stuff on their own. Distributed debugging is really had when you don't understand the fundamental problems.