5 ms·

Microservices is mostly an RDD (Resume Driven Development) practice I've found. Really, as the article says correctly and hilariously, unless you're a greenfiel

by baz00 3y ago

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.

readthenotes1 3y ago
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...
- jack_riminton 3y ago
  EJB?
  - m0llusk 3y ago
    Enterprise Java Beans, apparently now called Jakarta Enterprise Beans
est 3y ago
Microservices was literally invented by a software outsourcing company. Why make only one service when you can bill more.
- wiradikusuma 3y ago
  And cloud provider
- deleted 3y ago
  [deleted]
nine_zeros 3y ago
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.
throwawaayy948 3y ago
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.
- rahen 3y ago
  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.
quickthrower2 3y ago
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!)
The_Colonel 3y ago
> 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".
cosmicradiance 3y ago
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.
virgoerns 3y ago
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.
deleted 3y ago
[deleted]
threeseed 3y ago
> 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.
nonrandomstring 3y ago
> 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
- baz00 3y ago
  That's exactly it. Construct vast problems to solve simple problems.

by baz00 3y ago

readthenotes1 3y ago

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

jack_riminton 3y ago
EJB?
- m0llusk 3y ago
  Enterprise Java Beans, apparently now called Jakarta Enterprise Beans

est 3y ago

Microservices was literally invented by a software outsourcing company. Why make only one service when you can bill more.

wiradikusuma 3y ago
And cloud provider
deleted 3y ago
[deleted]

nine_zeros 3y ago

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.

throwawaayy948 3y ago

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.

rahen 3y ago
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.

quickthrower2 3y ago

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!)

The_Colonel 3y ago

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

cosmicradiance 3y ago

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.

virgoerns 3y ago

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.

deleted 3y ago

[deleted]

threeseed 3y ago

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

nonrandomstring 3y ago

> 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

baz00 3y ago
That's exactly it. Construct vast problems to solve simple problems.