Live data from Hacker News

You Don't Need Microservices

medium.com

121–130 of 169 posts

Re: You Don't Need Microservices

#121

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

I've seen the degenerate states of both extremes: - a monolith with too many engineers contributing: no continuous deployment but rather "release day," which was a shitshow; said day was an extensive process where hundreds of engineers (anybody who was on git blame) had to be online and sitting by for four hours while it rolled; the release team often had to hand-revert bad patches; bullying of engineers who "broke t…

I have also known both albeit on a lesser scale.

At a company we as a dev team had to maintain a constellation of desktop applications and homemade ETL Airflow-like software that scaled really badly. For the time I'd been there I had managed to automate deployment almost totally on my own. Sadly it had been somewhat controversial as it was done at the expense of other development tasks (my manager agreed but not his nontechnical manager), and probably too late too. Before I had had enough grasp on the complicated context we had to deliver on a big project and needless to say it was a shitshow and we developers took basically all the blame, with pretty much nothing to say back.

The tech stack and code had been in a state of neglect for 8+ years but that was not an acceptable answer at that time, it seemed, and I'd only been there for 6 months when it happened.

On the other end of the spectrum, at the above's parent company, I had to maintain several major versions of an API on several cloud regions. Undocumented peculiarities regarding the object storage that was specific to one region caused a production incident that took the dev and support team 3 days to untangle and solve.

I have similar stories on monorepo vs. multirepo too

Re: You Don't Need Microservices

#122
post #25

Microservices are a great way to promote cloud vendors' offerings and complicate IT life with over-engineered "standards" like Kubernetes. Big corp wins while their customers create DevOps and other buzzword teams and the majority of IT world loses the capability to actually administer systems and becomes users addicted to ever-changing vendor offerings that complicate learning useful stuff outside.

I'm working on an internal service that do not benefit being set up on kubernetes (it is basically a cronjob that runs everyday, collect data from every third party software, consolidate it and send it in a s3). It could be run on a small vm, deployed with ansible. But i understand why, for streamligning purpose, we use kubernetes. It makes the networking "easier", and i feel it integrate better with other CI/CD tool…

Sounds reasonable. Personally, I just try to stay away from k8s until it becomes a requirement. Until then simplest tools are often a good choice for building systems that require less maintenance. That's a per-project decision though.

You do not need Ansible for VMs provisioning - you can bake a VM image that will pull repos and do other preparation stuff. HashiCorp Packer[1] is an good tool for this imo. This applies to bare metal, too, as you can bake ISO or IMG the same way. Stuff that differentiates those systems can be set up with cloud-init or something similar.

Regarding Ansible, it didn't changed much over the years. At least nothing really major like statefulness.

But again, I'm not opposite to using Ansible when a project reasonably calls for it. Proper tool for configuring multiple systems with details generated for/by other systems, say multi-cloud HA provisions, clustering etc.

[1] https://www.packer.io/

Re: You Don't Need Microservices

#123
I’m working in a team right now that went through “CV driven development” with no oversight and has Django + micro services. One of them was written in Go, despite only one person knowing that language. The rest are a mess of unreliability - I found recently one of the services polls the main application’s internal API, and the script cuts off after 10 minutes of runtime and a new ECS container is launched. Why cron wasn’t preferable to this I will never know?!

We have something like 19 different components. Insane.

Re: You Don't Need Microservices

#124

Earlier quoted context omitted.

> I wish these services were a monolith so there was any amount of discoverability at all, Why do you conflate microservices with discoverability? What's wrong with simply calling a web service? > (...) and I don't have to beg for time from busy people on other teams to help me use their undocumented APIs And you believe that the same hypothetical team you claim doesn't document their API would all of a sudden docume…

If it was a monolith I would have access to the same codebase, so I could just go look at stuff in the code? Versus microservices where I might not have permissions to look at their repos.

It's a fascinating set of priories that lead to these policies.

"We trust you enough to run your code in production but we can't let you read another team's code because you might steal it. Yes, the odds that anyone wants to steal the code for this mundane microservice are staggeringly low... and yes you're going to be less productive and more prone to serious bugs by being in the dark, but that's your problem."

Re: You Don't Need Microservices

#125

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

Really? You’ve never seen an over-engineered microservices design that could be a much simpler express app?

Re: You Don't Need Microservices

#126
post #37

I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”

That's true for all ideas. A lot of people, especially smart people, like going "everyone says X, I'm going to try to appear smart by arguing not-X". And that's how you end up with people in the west going "Russia is the victim of the war in Ukraine! Nato encroachment!", or "they haven't tested the vaccines!"

That haven’t tested the vaccines. That’s why there’s emergency use laws.

Re: You Don't Need Microservices

#128

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

When I'm forced to work with a monolith that has 4000+ source files and takes a few minutes to even start up, and has about 20 configuration files that all need to be setup properly for it to even start, I wish for microservices.

When I'm forced to work with microservices that need Skaffold and Helm charts just to run locally, but with the configuration in the monorepo being kind of mismanaged and strewn around a bunch of folders with no documentation, in addition to debugging in the IDE not working because nobody set it all up, I wish for monoliths.

Really, you can have good monolithic systems and you can have good microservices as well, in addition to something in the middle: https://blog.kronis.dev/articles/modulith-because-we-need-to... (actually the first blog post that I wrote, the casual language probably shows its age).

But there can also be plenty of poorly developed projects with either. It just so happens that people hate monoliths more in the mainstream culture because most of the older and worse projects out there were monolithic, much like many hate Java and other languages because of being exposed to bad legacy projects written in them: https://earthly.dev/blog/brown-green-language/

Just wait for 5-10 years and people's disposition towards both monoliths and microservices will even out, the advantages and disadvantages of either will become clearly recognized and the hype will shift towards something like serverless. Much like now we know the advantages and disadvantages of languages with/without GC as well as higher/lower abtraction levels pretty well (consider Python vs Rust, for example).

Maybe things will slow down a bit because Kubernetes will also become a bit easier to use, possibly thanks to projects like K3s, K0s, Portainer and Rancher.

Re: You Don't Need Microservices

#129
post #125

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

Really? You’ve never seen an over-engineered microservices design that could be a much simpler express app?

What is an express app?

Re: You Don't Need Microservices

#130

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

When I'm forced to work with a monolith that has 4000+ source files and takes a few minutes to even start up, and has about 20 configuration files that all need to be setup properly for it to even start, I wish for microservices. When I'm forced to work with microservices that need Skaffold and Helm charts just to run locally, but with the configuration in the monorepo being kind of mismanaged and strewn around a bun…

It turns out the secret is just not writing crappy software and having crappy processes. It turns out the caveat is that the conditional probability of those two things is vanishingly small, so regardless of monolith or microservices, most devs are exposed to crappy stuff and because their sample sizes are tiny they assume well we just did it wrong, when in fact they did it average and average is crappy for any and all architectures.
Post reply on HN