Hacker News Reader

Comment by baz00 | Hacker News Reader

Microservices is mostly an RDD (Resume Driven Development) practice I've found. Really, as the article says correctly and hilariously, unless you're a greenfield or exceptionally large, you end up with a fleet of shitty golf carts.

My personal anecdote is, watching from the sidelines with face cupped in hands, watching a monolith being broken into hundreds of microservices at the cost of decreasing performance, increasing complexity and 90% of the traffic still hitting the monolith. Of course there's no time to do anything for the customers any more because everyone is updating software versions in all the microservices and promoting that "it'll all be fine if we just move one more thing to a microservice". The architectural vision will be complete in 2130 at this rate.

I want out from this demented ego driven fashion show.

View on HN

> Microservices is mostly an RDD (Resume Driven Development) practice I've found

I agree. The worst I've seen is with contractors/consultants, because the incentives are particularly bad.

They often stay with the project only for a limited time and "grokked customer's business/domain logic" is not something you can put on your resume and the typical 6 months are too short for that anyway. But there's enough time to introduce a schema registry or other piece of tech which can look pretty good on your CV. Jump onto a different customer, rinse and repeat. I call this "technology-oriented mindset" vs. "goal oriented mindset".

I have avoided, by luck alone, microservices, except the occasional small service where it makes sense (think AWS Lambda to covert doc to pdf for spikey loads) and I am glad. It means I don’t get far in interviews at small companies that bizarrely want microservices experience (as opposed to problem solving experience!)

> I want out from this demented ego driven fashion show.

The author of TFA kinda hits on this in the first paragraph:

> absurdity of the state of the current tech culture. We laugh, and yet bringing this up in a serious conversation is tantamount to professional heresy, rendering you borderline un-hirable

As soon as I read that, I felt I knew what the rest of the essay would be about, and I was right. It's about culture.

A culture of insecurity, wannabeism, fads, in-groups cliques, so-called "best practices", megalomaniacal levels of scaling, over-reach..... let's all admit shall we (at least privately) , that "tech" has an _ugly_ culture, that we've lost those early joys of solving problems. We've replaced that with a culture of making problems so we can look good by "solving" them. Just realising that would bring enormous economic benefits.

In wider human culture, tech is looked down on, for good reasons. At worst it is a proxy battleground for personal whims and ideologies in which one group of people set out to impose upon another larger group, their particular idea of how the world should 'work'. Code becomes our poor man's mathematics, apparently adding rigour and substance to what is arbitrary and manifold. The helpless dependency of those who must use what we create, makes that a very abusive relationship.

It's a shame that Gerald Weinberg's concept of Egoless programming came at a time before the "boom", and so couldn't address the devastating effects of ego-driven development on the wider culture. It's more about the internal dynamics of the development team.

[1] 1971, The Psychology of Computer Programming

That's exactly it. Construct vast problems to solve simple problems.

Mirrors my experience, except some teams also decided to implement the new services in different languages...

After a downsizing, we are now left with 15 services, 5 different programming languages and complicated kubernetes setup. We have less than 10 developers that has to maintain this. In addition we also have a separate flow for managing data and BI.

Kubernetes is a bit of the new OpenStack. It's like an all-you-can-eat buffet of complexity concealed behind interfaces.

Either some startups go rampage with it and deploy needlessly complex stacks because the tooling makes it easy, hence a headlong rush into more hidden complexity to solve problems. Or they use it for the hype and merely deploy a couple monoliths with it, which Compose / Terraform would do just as well without the maintenance burden.

We broke our monolith ~2015. 8 years later we still have the original monolith plus the original mircoservices are now monoliths too which need splitting. Upgrades were a nightmare for first 5 years, but we solved it with nitpicking code reviews where non-trival changes are blocked forever until everyone's ready.

At least we solved the problem of decreasing performance the old fashioned way: by throwing more RAM and CPU power at the problem.

When proposing a system design - have two. One using a monolith and second using microservices. Put the first in production and the second in your CV and everybody goes home happy.

Microservices was literally invented by a software outsourcing company.

Why make only one service when you can bill more.

And cloud provider

I got out in part because of this. I weathered the EJB craze somehow and microservices plus the JavaScript framework du jour was too much...

EJB?

Enterprise Java Beans, apparently now called Jakarta Enterprise Beans

I have seen managers propose microservices to their own bosses just to show their own bosses that their team will embark on something Netflix does - so we should do too.

> Microservices is mostly an RDD (Resume Driven Development) practice I've found

Microservices was invented nearly 20 years ago.

At what point is this argument that it is some new, risky approach that is going to wow hiring managers going to stop.

It's actually ridiculous now.

Reply on news.ycombinator.com