Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't start with microservices – monoliths are your friend

arnoldgalovics.com

Post reply on HN
Print view View original

131–140 of 468 posts

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

#131

Post by vgchh »

While it is easy to start with monolith, it's not easy to just go from monolith to Microservices in case it is determined that's the best path forward. Often organizations don't have the luxury to "learn" by doing a monolith first and then determining the boundaries. In most cases, market pressures, limited budgets keep monoliths monoliths. OTOH, my experience is that it is easier to combine overly granular Microservices into just right size Microservices on an ongoing basis. And yes, infra requirements are bigger for Microservices, but often it is highly automate-able.

I think, one of the reasons, besides all the usual reasons, that keeps Microservices in vogue is the ability to align with organizational structure and enabling independent-ish teams.

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

#132

Post by gmueckl »

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.

Code review processes should catch the worst of that. If you don't have those and don't have incredibly disciplined developers, well, good luck...

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

#133

Post by arthur_sav »

jhoelzel wrote: post #9

There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either. maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code. Developing a montolith for years but now you have written a 15 line golang ht…

Exactly, it doesn't have to be one or the other. So far, i've been using a monolith for core functionality and microservices for independent processing tasks.

That way, i can attach as much functionality as i want without bloating the main app and processing scales with demand.

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

#134

Post by jhoelzel »

Pamar wrote: post #112
barrkel wrote: post #87

Earlier quoted context omitted.

Single writer multiple readers, ideally with permissions to enforce, is a useful hybrid. Enforce going through the front door if you want side-effects. Reporting and ad-hoc data enrichment can be painful to materialize otherwise. When you have multiple bits of code responsible for writing the same columns, maintaining global invariants becomes much harder. I can still see rationale for exceptions to the rule, e.g. st…

Caveat: I am really not qualified to discuss the nuances (because I have never used microservices so the little I know is based on reading a bit on those here and on other online forums). "Single writer multiple readers", yes, this is what I would probably use, but yet again, wasn't the "promise" of Microservices being able to work in total isolation? If I have one table (e.g. "Customer") which is written by one spec…

actually you would only have to change the one reader and the one writer.

The services themselves do not differ, but are fanned out. E.G. so 100 workers watch your pdf queue to generate pdfs.

If your zip code is really used by many services, the question is how you want to communicate those objects and there are really a lot of choices out there. GRPC / Soap / Shared model package / and the list goes one.

On the other hand i have obsverved that people push full blown models around just to end up reading one field of it in their monolith. I believe the PHP frameworks of the past where the biggest offenders like that.

When i was working with sugarcrm for instance, it was not uncommon to pass huuuuge objects between functions because you needed 1 field. It's PHP so by default, function arguments are passed by value, so you can already see where the fun begins.

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

#135

Post by dlisboa »

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…

Have you seen this done well more than a few times? Honest question because it’s something I think everyone agrees with as being a good idea but it never gets actually done. It’s definitely not an industry practice that big monoliths eventually get split up in modules and quality increases. It’s something you have to fight for and actively pursue.

I’ve been on projects with very good developers, who were very bought into the idea of separating modules in the monolith, yet for one reason or another it never got done to an extent where you could see the quality improving. This leads me to believe this technique just isn’t practical for most teams, for reasons that are more psychological than technical.

It’s just something about how people approach a single codebase that leads to that, it’s harder to think about contracts and communication when everything is in the same language.

But if you force them to communicate over the wire to something in a different stack then all of a sudden the contracts become clear and boundaries well defined.

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

#136

Post by goodoldneon »

bspammer wrote: post #93
deniska wrote: post #26

Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results. Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an…

> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “d…

Distributed monolith can mean different things. I worked at a place with ~10 services sharing the same DB. It was awful

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

#137

Post by Jenk »

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…

IME it's the drive for microservices that encourage the modular monolith. That is to say, the monolith is typically loosely modular (but still with many rule-breakages) until the push for microservices starts _then_ the big refactor to modularity begins.

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

#138

Post by goodoldneon »

solididiot wrote: post #107
kkjjkgjjgg wrote: post #22

Maybe I'm too old, but I don't even want to have to worry about all that. I think in terms of functions and I don't care if they are being called remotely or local. That was the promise back in the day of J2EE, and it seems to me Microservices are just a rehash of that same promise. Which never really worked out with J2EE - it was mostly invented to sell big servers and expensive consultants, which is how Sun made mo…

DevOps is a sad story both for devs and for ops. It was supposed to treat operations as a SW problem thus take away the toll and draw devs in. In reality for most places it either means that devs also do pipelines and operations or that operations were rebranded and are using "DevOps" tooling to do operations.

To me, DevOps means SDEs can troubleshoot, diagnose, and fix app-related prod issues. SREs don’t have the app-level knowledge for that, so it’s wasteful for them to be involved. SREs should be paving paths for SDEs and responding to infrastructure ops issues.

I also think silos are unhealthy. SDEs need to have some overlapping responsibilities with SREs. Otherwise, you’ll likely have a “throw it over the fence” culture

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

#139

Post by MrBuddyCasino »

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…

> hexagonal architecture

Tried it twice, never pulled its weight. It introduces abstraction layers everywhere, as a premature optimisation, even though they might never be needed, and its a bad fit for more verbose and statically typed languages due to all the ceremony thats required. Anyone made similar experiences?

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

#140

Post by bspammer »

gwbas1c wrote: post #108
bspammer wrote: post #93

Earlier quoted context omitted.

> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “d…

That's a fallicy. You've optimized for one use case, but you've made everything else more complicated as a consequence. Deploying a single monolith is faster than deploying 10 microservices, especially if you find yourself in the model where your microservices share code, you've ended up with a distributed monolith instead of microservices.

> You've optimized for one use case, but you've made everything else more complicated as a consequence.

Yes, but that use case happens to be something that I need to do 5 times a day - make a small (This also means that if something goes wrong, I can rollback those changes immediately without rolling back the work of any of the other 50 engineers in the company.

Very little signoff required, very small blast radius.

Post reply on HN