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

391–400 of 468 posts

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

#391

Post by staticassertion »

api wrote: post #366
stickfigure wrote: post #365

Earlier quoted context omitted.

My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.

I've wondered if it's not a ploy by cloud vendors and the ecosystem around them to increase peoples' cloud bills. Not only do you end up using many times more CPU but you end up transferring a lot of data between availability zones, and many clouds bill for that. A microservice architecture also tends to lock you into requiring things like Kubernetes, further increasing lock-in to the managed cloud paradigm if not to…

> I've wondered if it's not a ploy by cloud vendors and the ecosystem around them to increase peoples' cloud bills. Not only do you end up using many times more CPU but you end up transferring a lot of data between availability zones, and many clouds bill for that.

Disagree. I'd argue that microservices are inherently more cost effective to scale. By breaking up your services you can deploy them in arbitrary ways, essentially bin packing N microservices onto K instances.

When your data volume is light you reduce K and repack your N services.

Because your services are broken apart they're easier to move around and you have more fine grained scaling.

> further increasing lock-in to the managed cloud paradigm if not to individual clouds.

Also disagree. We use Nomad and it's not hard to imagine how we would move to another cloud.

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

#392

Post by ineedasername »

My impression, which seems to be supported by this article? Is that when you're small, you can actually get up & running with an MVP with a non-serverless monolithic approach and scale for a bit before you hit a wall. And only at that point: 1) Scaling becomes much more complex and 2) Monolithic infrastructure prevents you from easily implementing best-of-breed solutions within segments of your functionality to optimize various functionality. And, from a cloud services $$ POV, it's cheaper and perhaps require less dev time, though I'm guessing that will depend on the project

This seems reasonable? At least at the early & early-mid stages. If you make it that far and see things like scaling issue in your future, it seems like you should also be at a stage of growth where you'll be getting reasonable funding offers and can invest the resources into migrating away from monolithic.

Disclaimer: My opinion here is formed mostly from following a not-completely-dissimilar process even when working with things more on a monolithic side of things: I'll use a high-powered workstation to spin up a vm's on the same host, and then if I need to I can migrate individual vm's to their own better-resourced instances on other hardware to scale things. I did this some years ago with a Hadoop cluster and the process worked out nicely.

Although as it turned out, that example didn't last long: Hadoop was overkill because I overestimated the bigness of my data, which turned out to only be on the bigger side of small. Or smaller side of medium. When I had a rethink on it, I wrote some python code against a the primary sql-based data source & used Keras to do what I needed instead: Iterating each pieceon a nicely-spec'ed workstation took an hour or so, and a full end-to-end run maybe 3-4 hours.

But this is kind of my point: Starting out, it's easy to thing "Oh I need to plan for ever possible eventuality & level of scale." No, you don't.

And a final caveat to this: YMMV since circumstances differ from project to project. But these are things to consider before you automatically go for slicing each piece of functionality into grains of sand with their own microservice.

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

#393

Post by emodendroket »

Of course this advice doesn't always make sense, but it makes sense more often than people want to admit. Not that this is an original claim, if anybody remembers the "majestic monolith."

Simply put, the microservice path makes a lot more sense when your organization is so big that you don't really know what other teams are doing all the time and need a clear delineation of areas of responsibility, or maybe if you have very large volumes you're dealing with. That doesn't describe most orgs, but if it describes you consider microservices.

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

#394

Post by spc476 »

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…

The individual code bases of a microservice might not involve spaghetti code, but the interconnections certain can. I'm looking at a diagram of the service I work on, with seven components (written in three languages), five databases, 25 internal connections, two external interfaces, and three connections to outside databases, all cross-wired (via 6 connections) with a similar setup geographically elsewhere in case we need to cut over. And that's the simplified diagram, not showing the number of individual instances of each component running.

There is clear separation of concerns among all the components, but it's the interconnections between them that take a while to pick up on.

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

#395

Post by abraxas »

emodendroket wrote: post #393

Of course this advice doesn't always make sense, but it makes sense more often than people want to admit. Not that this is an original claim, if anybody remembers the "majestic monolith." Simply put, the microservice path makes a lot more sense when your organization is so big that you don't really know what other teams are doing all the time and need a clear delineation of areas of responsibility, or maybe if you ha…

Oftentimes however with microservices it's the tail wagging the dog. Microservices architectures become such a burden that they strain the capacity of the existing team which leads to more hiring which thanks to Conway's law leads to more microservices being built which leads to more operational and architectural overhead which leads to more hiring...

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

#397

Post by hiram112 »

tabtab wrote: post #368
stickfigure wrote: post #365

Earlier quoted context omitted.

My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.

If you go with static languages you are pretty much stuck with Microsoft or Oracle, both which are ahole companies who cannot be trusted. There is no sufficiently common 3rd static option, at least not tied to Big Tech.

Off the top of my head, there are now JDK open source builds provided by:

* Oracle

* Microsoft

* Redhat

* IBM (yes redundant with Redhat, but I believe IBM has multiple divisions providing JDKs, on top of what they got with RHEL purchase)

* Amazon

* Eclipse Foundation

* Azul

And that's just the USA.

SAP (Germany) has a build.

So does China's biggest company, AliBaba.

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

#398

Post by abraxas »

bspammer wrote: post #140
gwbas1c wrote: post #108

Earlier quoted context omitted.

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.

I doubt you can judge the blast radius.

Say your little service just changed how it parsed backticks. Now that innocuous change may affect none of the immediately connected microservices but another services three hops away relied on the old behavior of your parser through some complex business rules driven logic. Now go test and later troubleshoot that vs standing up a single monolithic jar on your laptop and seeing the exception stack trace tell you exactly what you broke.

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

#399

Post by naasking »

tabtab wrote: post #368
stickfigure wrote: post #365

Earlier quoted context omitted.

My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.

If you go with static languages you are pretty much stuck with Microsoft or Oracle, both which are ahole companies who cannot be trusted. There is no sufficiently common 3rd static option, at least not tied to Big Tech.

What can't they be trusted to do? Certainly you can trust MS to serve their customers, and if you're a customer, well...

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

#400

Post by lostcolony »

spc476 wrote: post #394
lostcolony wrote: post #242

Earlier quoted context omitted.

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…

The individual code bases of a microservice might not involve spaghetti code, but the interconnections certain can. I'm looking at a diagram of the service I work on, with seven components (written in three languages), five databases, 25 internal connections, two external interfaces, and three connections to outside databases, all cross-wired (via 6 connections) with a similar setup geographically elsewhere in case w…

Fair; I should have been more explicit - your code can't fall into spaghetti (since the services are so small). Of course, you're just moving that complexity into the infrastructure, where, yeah, you still have the same complexity and the same pressures.
Post reply on HN