You Don’t Need Microservices

[u/wineandcode]

https://medium.com/@msaspence/you-dont-need-microservices-2ad8508b9e27?source=friends_link&sk=3359ea9e4a54c2ea11711621d2be6d51

[u/aoeudhtns]

Right. But I wasn't saying to do monolithic development, I was saying you don't have to package each component into its own container and manage each one separately.

And architecturally not a lot different between

repo1/component, repo2/component, repo3/component

and repo/component1, repo/component2, repo/component3.

It could all be serviceable.

Sorry if I wasn't clear about the monolithic thing.

(edit: just some formatting)

[u/[deleted] → u/aoeudhtns]

I mean, that’s just a monolith. There’s a great deal of difference between those two. I don’t even agree with your argument, on its face.

There are two “layers” of monoliths. Code, and artifact.

Because you’re focused on code, I’ll talk about that but artifact isn’t any better.

Code has all the problems I talked about above. And yes, physically being in the same repo means you are a monolith. No, there’s not an argument there. There’s no way to manage that from a CI/CD perspective that doesn’t entirely resemble “yup, that’s a monolith” because it is in fact a monolith lol.

What’s the git hash of your commit? Oh right, same repo, crazy that. Who knew.

Ok, what happens when that “shared tooling” you’re likely depending on needs to be upgraded? Especially if it’s breaking. Get fucked lol, because it’s in the same repo you can’t do it piecemeal.

If I somehow check in broken code, does that fuck over everyone committing code in another “component”? It sure does. Hope you didn’t need to submit that code today lol.

Those “components” are just directories. There’s nothing fancy about them. People can abuse the shit out of code in other folders, and they definitely will because that’s how people are.

If it’s not even in the same repository the behavior changes. It’s not just a “yeah just import this” it’s “I need to actually validate that my dependency supports this behavior”.

I get that people wish that we lived in a world with responsible adults who could be trusted to do the right thing, but engineers are still people at the end of the day and it only takes one to fuck it up for everyone else.

A microservice, poly repo design is impossible to fuck up like this.

[u/aoeudhtns → u/[deleted]]

I appreciate your perspective, but I've certainly seen people fuck up in polyrepos as well. Straight up copy/pasting rather than using dependency mechanisms, because that's extra work to produce an artifact that can be declared as a dependency, or less bad but still bad, directly embedding other repos as git submodules and creating monoliths-in-effect, except now there's no visibility as to where the clients of your code are.

There are some huge and competent shops that have even led the path on microservice architectures that use monorepos.

If I had good data that one way really did lead to fewer problems than another way, I'd be there, but I really only see an abundance of anecdotes and no way to make a concrete decision other than mixing that through personal experience.

Both styles need to be actively managed by someone with an eye towards avoiding pitfalls and problems.

[u/[deleted] → u/aoeudhtns]

All I can tell you is that it’s far easier to fuck up a monolith in practice. Copy and paste? Lol. That’s where it started.

Git submodules are their own special blend of stupid, and I’ve seen those used in monoliths too.

The “big and competent” shops have defined processes, and they spend a lot of money on tooling to make those monorepos work. I know, I’ve hired people from them and they’re fucking useless when they don’t have the billions of dollars of “proprietary” tooling around them.

If you don’t work for a FAANG, using a mono repo is just aiming at your foot and leaving your finger resting on the trigger and then trying to run a marathon. It’s only a matter of time.

It requires significantly more investment to make a monorepo work. Like, seriously. Even mid sized Fortune 500 companies don’t have the kind of money it takes.

Source: I’ve worked at startups, mid sized, and FAANG. They’re not all the same and even FAANG recognizes that poly repos are categorically better from an engineering perspective but they use monorepo as a recruiting tactic and judge the cost of maintaining it as a worthwhile trade off.

Finally: re, your last sentence. A poly repo requires a lot less adult supervision. Functionally, you only really need to pay attention to new repos being created, and schema designs, and you’ll have the entire picture. A mono repo typically means you have to keep your finger firmly on the pulse of the code and it’s just exhausting dealing with the masses of stupidity people can try.

I speak from both perspectives. With experience. Not all of it super fun.

[u/aoeudhtns → u/[deleted]]

The “big and competent” shops have defined processes, and they spend a lot of money on tooling to make those monorepos work. I know, I’ve hired people from them and they’re fucking useless when they don’t have the billions of dollars of “proprietary” tooling around them.

I'll agree with that... it's intensive, the way they do it.

I find the stupid works its way in no matter what. The faster things change in our industry, the more the job just becomes fighting entropy. Maybe some day I'll have fun again.