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.
Microservices are hard
281–290 of 356 posts
Re: Microservices are hard
#282Use 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.
Re: Microservices are hard
#283Earlier 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.
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
#284Re: Microservices are hard
#285The 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
#286I 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…
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
#287I 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…
Re: Microservices are hard
#288We 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
#289Earlier 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.
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
#290I 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…
Everyone ran with it and now we're stuck with thousands of fragile and unmaintainable systems which will ruin companies in the coming decades.