Don't start with microservices – monoliths are your friend • Hacker News Board

Re: Don't start with microservices – monoliths are your friend

#351

Post by baash05 » Thu, Dec 16, 2021, 9:12 PM UTC

Cthulhu_ wrote: post #23

adflux wrote: post #10

Microservices aren't implemented to solve technical problems, rather they are used to solve organizational problems. Having 10 developers working on a single monolith? Probably fine. 100? Good luck managing that. Yes they add technical complexity. But they reduce organizational complexity.

I feel like microservices are a solution for magpie developers. It's hard to keep a hundred engineers excited about working in an aging Java stack when there's all these shiny new tools out there. But maybe that's just my perspective, coming from a consultancy firm whose devs wanted to stay on the cutting edge.

I think this leads to silos. MicroServices written in different lang's mean Java Dev X can't maintain Python service Y.. Not in an efficient way. What's worse, Java Dev can't move to Team Y without upskilling not only on the service, but also the lang, so they get pidgin holed. She also can't move because she's the only Java dev left.

Re: Don't start with microservices – monoliths are your friend

#352

Post by jameshart » Thu, Dec 16, 2021, 9:24 PM UTC

zemo wrote: post #332

jameshart wrote: post #288

Earlier quoted context omitted.

The interesting thing about microservices is not that it lets you split up your code on module boundaries. Obviously you can (and should!) do that inside any codebase. The thing about microservices is that it breaks up your data and deployment on module boundaries. Monoliths are monoliths not because they lack separation of concerns in code (something which lacks that is not a ‘monolith’, it is what’s called a ‘big b…

that's not at all accurate of any of the monoliths I've worked on. This in particular describes exactly zero of them: - one shared database Usually there's one data access interface, but behind that interface there are multiple databases. This characterization doesn't even cover the most common of upgrades to data storage in monoliths: adding a caching layer to an existing database layer.

Okay, great. But you get that ten shared databases behind a shared caching layer isn't any better right? It's still all shared dependencies.

Re: Don't start with microservices – monoliths are your friend

#353

Post by one2three4 » Thu, Dec 16, 2021, 9:24 PM UTC

outworlder wrote: post #333

ozim wrote: post #229

Earlier quoted context omitted.

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…

> Micro services were not an answer to monolith being bad Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart.

You do that anyway as per Conway's law.

Re: Don't start with microservices – monoliths are your friend

#354

Post by jameshart » Thu, Dec 16, 2021, 9:27 PM UTC

KronisLV wrote: post #311

jameshart wrote: post #301

Earlier quoted context omitted.

But all those data sources are connected to from the same runtime, right? And to run it locally you need access to dev versions of all of them. And when there’s a security vulnerability in your comment system your tape library gets wiped.

This actually feels like a good example of the modularity that i talked about and feature flags. Of course, in some projects, it's not what one would call a new architecture (like in my blog post), but rather just careful usage of feature flags. > But all those data sources are connected to from the same runtime, right? Surely you could have multiple instances of your monolithic app: # Runs internally app_instance_1_…

You're talking about something very odd here... a monorepo, with a monolithic build output, but that... transforms into any of a number of different services at runtime based on configuration?

Is this meant to be simpler than straight separate codebase microservices?

Re: Don't start with microservices – monoliths are your friend

#355

Post by strzibny » Thu, Dec 16, 2021, 9:28 PM UTC

KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

I think most people do modularize monoliths. There are Phoenix contexts and Rails engines that provide a good starting point, for example.

After working with Phoenix I am actually thinking of bringing the idea of contexts to Rails applications (to some extend):

https://nts.strzibny.name/business-logic-in-rails-with-conte...

Re: Don't start with microservices – monoliths are your friend

#356

Post by Lhiw » Thu, Dec 16, 2021, 9:30 PM UTC

lostcolony wrote: post #242

ravenstine wrote: post #238

Earlier quoted context omitted.

> monolith was always supposed to be MODULAR from the start Well, that certainly is sensible, but I wasn't aware that someone had to invent the monolith and define how far it should go. Alas, my impression is that the term "monolith" doesn't really refer to a pattern or format someone is deliberately aiming for in most cases, but instead refers to one big execution of a lot of code that is doing far more than it shou…

No one had to invent the monolith or define how far it should go; it was the default. Microservices came about because companies kept falling into the same trap - that because the code base was shared, and because organizational pressures mean features > tech debt, always, there was always pressure to write spaghetti code rather than to refactor and properly encapsulate. That doesn't mean it couldn't be done, it just…

> organizational pressures mean features > tech debt, always

I wish.

Our organisation focuses on building libraries and frameworks. Literally every solution is a new library.

Products take months to ship because you have to either make a new version of a library because the old version wasnt really expecting to work with your needs, or you need to refactor your existing libraries to work with new needs, that takes months of refactoring all the usage points.

It's nuts. I tried to build a completely new thing recently, got told to build a library. My thing is pretty specific, doesn't need a library, and will just be single use. It will consume lots of libraries.

Would have taken about a week to ship. Instead, here we are week 4 still figuring out how to make this pile of shit work.

Sometimes I wish people would just build abstractions on top of what we have. Not everything needs to be a library, sometimes, your new product code is all you need to solve a problem.

Re: Don't start with microservices – monoliths are your friend

#357

Post by winddude » Thu, Dec 16, 2021, 9:33 PM UTC

wow, just wow, I don't know where to begin. I think something written by gpt-3 would have less errors on parts of a software stack.

Re: Don't start with microservices – monoliths are your friend

#358

Post by Retric » Thu, Dec 16, 2021, 9:40 PM UTC

jameshart wrote: post #354

KronisLV wrote: post #311

Earlier quoted context omitted.

This actually feels like a good example of the modularity that i talked about and feature flags. Of course, in some projects, it's not what one would call a new architecture (like in my blog post), but rather just careful usage of feature flags. > But all those data sources are connected to from the same runtime, right? Surely you could have multiple instances of your monolithic app: # Runs internally app_instance_1_…

You're talking about something very odd here... a monorepo, with a monolithic build output, but that... transforms into any of a number of different services at runtime based on configuration? Is this meant to be simpler than straight separate codebase microservices?

It’s not that odd. Databases, print servers, or web servers for example do something similar with multiple copies of the same software running on a network with different settings. Using a single build for almost identical services running on classified and unclassified networks is what jumps to mind.

Re: Don't start with microservices – monoliths are your friend

#359

Post by alkonaut » Thu, Dec 16, 2021, 9:55 PM UTC

bayesian_horse wrote: post #118

gmueckl wrote: post #52

Earlier quoted context omitted.

In some languages, you can enforce boundaries within a monolith nicely using the build system. The key is to break the build up into a hierarchically structured set of libraries somehow where each library only gets to use those libraries it is allowed to depend on architecturally. Independent bits of business logic would need to go into libraries that cannot "see" each other when they are compiled. Everything would s…

I think you didn't quite get the point of engineers of different levels of quality, talent and opinions working on the same monoliths. Eventually they tear down any boundary, even those in the build system. Developer discipline is something that eludes many companies for lack of enough high quality engineers and awareness for the problem in upper management. It's easier to quibble over formatting guidelines.

I know. Which is why I have architectural tests that scream if someone uses the wrong module from the wrong place (adds a dependency that isn't what we want).

Of course, any dev could just remove the test, and by that tear down that boundary too. But that test being removed is much more obvious to the code reviewer who would not have noticed the dependency being snuck in. The architectural tests can also contain comments that form a high level documentation of the architecture. Unlike "architectural documents" in the form of some up front word document, this type tends to stay up to date.

Re: Don't start with microservices – monoliths are your friend

#360

Post by 2-718-281-828 » Thu, Dec 16, 2021, 10:01 PM UTC

The idea of microservices sometimes reminds me of visual programming looking at infrastructure diagrams. Like instead of writing the code and executing it. You implement variables (databases), conditions (lambda), loops (pubsub/sqs) etc as separate entities and then put them together.