Live data from Hacker News

Microservices are hard

code-held.com

281–290 of 356 posts

Re: Microservices are hard

#281

Earlier quoted context omitted.

Two is one and one is none. This is not hard. But it's costly. The main problem with security and reliability is that they are expensive. Those operating in high margins, highly specced spaces need to do it right or they lose. Everyone else is cargo culting, box-checking for stakeholders or selling snake oil. There is a fundamental tension between optimizing for cost and doing things right, and short term gains will…

“mounting operational risks” is my main complaint with the “there is no maintenance” thread that was here the other day. Maintenance is looking at all of the probability < 10^-4 issues that are just waiting for you to roll the dice enough times to eventually lose to the birthday problem. Every day you’re lowering the odds that tomorrow will be the day everything burns, because doing nothing is just a waiting game.

Yeah that was such a 'social media hot take' kinda thing I didn't even feel like getting into that conversation. Misaligned interests make it a good idea to get into a project, slash things to the bone, cut a fat bonus check due to savings achieve, cut and run. That's how we got the supply chain mess of 2021...

Re: Microservices are hard

#282
post #198

Use the best tool for the job. It's stupid to think of monoliths vs microservices. You can use both if the problem requires it. For example I'm currently working on an audio hosting service. The main app is a monolith where 90% of the code resides but there are a couple of ancillary services. Audio encoding (which is heavily CPU bound) is a serverless microservice that can scale up and down as needed. Users don't upl…

This argument is brought forth a lot, but it misses the point. Often people think microservices are the right tool for the job , but they vastly underestimate the complexity that it entails.

If you can solve a problem without a microservice then probably it's not the right tool for the job.

Re: Microservices are hard

#283

Earlier quoted context omitted.

We had a major cockup at work a few years ago caused by bad organizational choices and Conway’s Law. We had a disk array go sideways, which is when we learned that some dumb motherfucker had put our wiki on the same SAN with production traffic. You know, the wiki where you keep all your run books for solving production issues? Everyone was furious and that team lost some prestige that day. How dumb do you have to be?

Seems a little harsh. We all overlook things like this. Things like storage are so reliable we expect them to always be available. When you lay it out like you did, it does sound silly.

Our operations team didn’t have visibility because some other operations team told us not to worry our pretty little heads about it. You know how you can tell when someone is so mad that they stop talking? Two of our people hit that level. That was not a comfortable room to be in.

This experience ended up being the beginning of the end for the anti-cloud element at the company. Which is too bad because I like having people who understand the physics of our architecture. Saves me from doing all sorts of stupid things myself.

Re: Microservices are hard

#285
Microservices are analogous to classes from OOP: an attempt at modularization by bundling function, internal state and side-effects together. So it suffers from the same challenges. It’s worse in fact, as the message passing now involves unreliable I/O, and the internal state is also shared global state.

The main reason it exists is because of the availability of cheap commodity hardware for servers (and later cloud), which breaks the model of programming for vertical scaling afforded by the mainframe model. It’s out of necessity to scale cheaply that this architecture is followed - the rationalizations that this is a superior way for teams to work together or that it improves reliability can be argued.

Re: Microservices are hard

#286
post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

When discussing turning our monolith into microservices at a previous job:

My Boss: "I'm convinced this is the right architecture."

Also my boss: "Now how do we break this app up?"

He was certain we needed to shatter our monolith into lots of little pieces, but had no clear vision as to what those pieces would be. From my point of view, the "architecture" he was certain of wasn't an architecture at all. It was just a general notion of doing what he thought everyone else was doing without considering anything about our app. Total cargo cult mentality.

Re: Microservices are hard

#287

I keep reading these microservice essays where the author is lost and I really feel their pain. In that spirit, let me try to make things as simple as possible. (True) Microservices have no dependencies on anything but unstructured text data. They do not couple to a database, the business understanding of what it's doing, a domain model, or anything else. They perform a simple, idempotent, business task that can neve…

This doesn't make much sense. "Interesting business conversations" should map 1-to-1 with microservices but also each microservice must perform a "simple, idempotent business task" but also microservices can't be coupled to a database? Okay, enjoy developing your business with no data persistence whatsoever and where your architectural principles forbid you from ever so much as sending an email.

Re: Microservices are hard

#288
Microservices suck and I hate the IT world for hyping it and jumping on the bandwagon to nowhere.

We never should've gone with this. It makes things ridiculously difficult with almost no benefit.

Just stay with the trusty old Monolith!

Re: Microservices are hard

#289
post #162

Earlier quoted context omitted.

I worked for a company that did microservices well, and this was the norm, too. The term in my head is "golden path" or "sandbox". The languages were Go and Python, speaking protobufs over gRPC. Developing software outside that sandbox was not disallowed, but you were "on your own" in terms of infra support if you chose to do so. FWIW, the main "tricks" we found were (1) using a good build tool (2) use a good ci/cd t…

Just curious, why is using a monorepo a useful trick? I would think it'd be better to have internal libraries that provide common functionality across services, and have a repo for each service. Otherwise, you're deploying code changes for one service that could, in theory, mess with another service that you don't maintain.

In a phrase, it's having a single "bleeding edge" for the entire company, vs 1 bleeding edge per service. Some benefits of this include:

You have one commit hash in one repo that tells you what version service/consumer X is expecting / providing.

If you want to understand why a service isn't working as expected, it's trivial to grep its implementation and contribute solutions.

As a service owner, you can grep for all places where your service's client is initialized, and update them in one PR (vs 12 PRs in 12 repos, that you have to manage independently).

Basically, it reduces the coordination cost of breaking changes.

---

You can get these benefits in a multi-repo setup only if you have adequate tooling around multi-repo PRs, code search, etc. It's not impossible, but the barrier to highly effective work is higher, imo.

Re: Microservices are hard

#290
post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

Microservices are merely just another hype in the IT world.

Everyone ran with it and now we're stuck with thousands of fragile and unmaintainable systems which will ruin companies in the coming decades.

Post reply on HN