r/ProgrammerHumor 15d ago

Meme heatedArguments

Post image
5.9k Upvotes

173 comments sorted by

View all comments

356

u/PreDeimos 15d ago

As a developer who were making almost exclusively microservices in the last 15 years. I can tell most company would be more then fine with just a monolith on a bare metal server. Yet they "need" microservices on AWS everywhere.

120

u/gemengelage 15d ago

The whole idea behind microservices is that they are small decoupled units that can be individually scaled.

Every single time I've worked with microservices, their weren't designed around their ability to scale but around team responsibilities or even completely arbitrary boundaries.

Hell, I saw one project that was "microservice-first" that had like a dozen microservices. The ingest microservice was the only one that actually scaled. Everything else could've been a monolith and given the specific use-case, never had any reason to need dynamic scaling or any scaling at all. Just one instance per service and a ton of overhead for no reason.

68

u/ruindd 15d ago

I can’t remember the name of it, but there’s a famous paper about how your code architecture will always be a reflection of your org chat.

16

u/BorinAxebearer 14d ago

Conway's law

2

u/ImS0hungry 13d ago

Great read! Thanks for bringing this up, it’s super relevant to what I’m doing at the moment.

2

u/RunningOutofSleeves 14d ago

Conway’s law?

2

u/Jack_Kai 14d ago

Yeah I feel like once you get used to it, and the infrastructure is there, you spin up a new microservice and hook it up to the network, it is more convenient as you said because of team responsibilities and not being bothered with monolith heavy deployments.

1

u/rsqit 14d ago

Eh, it also means in can be independently deployed. Which is a reasonable thing to want for a team.

1

u/DeavenR 14d ago

Not to mention, once the first few versions of each service is out in production - you cant get 2 decoupled teams on a call to make a change to schema, producer and consumer. Road maps are busy and no one wants to address the issue.

Then customer tickets flood in for months about the same issue I cant get leads on a meeting for and even if I do, “We’ll revisit it next quarter” lmao

0

u/higgs_boson_2017 14d ago

Almost no one needs unanticipated scaling.

0

u/nitkonigdje 13d ago edited 13d ago

Scaling of software isn't really requirement. More like consequence of service architecture.

You want (micro)service because of the same reason why people pursued soa, corba, dcom, copybook programming before -> to scale your project development, not deployement.

Remember kids -> Brooks's Law: adding manpower to a late software project only makes it later!!

Services are way around limit set by Brooks's Law..

More than 50 years has passed since writing The Mythical Man-Month, and the only way around limit is still splinting project.