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

Modules, not microservices

blogs.newardassociates.com

Post reply on HN
Print view View original

461–470 of 671 posts

Re: Modules, not microservices

#461

Post by highspeedbus »

MuffinFlavored wrote: post #322
zeroonetwothree wrote: post #317

Earlier quoted context omitted.

The way it usually works, if 1 of your 100 modules needs to be scaled, it probably means the overall monolith only needs a small amount of extra resources, since that module is only using 1% of the total. So it's not like you need to double the instances of the whole thing. The benefit though is you get a bit of 'free' scaling. Most of the modules don't even have to consider scaling at all, as long as they are growin…

> The way it usually works, if 1 of your 100 modules needs to be scaled, it probably means the overall monolith only needs a small amount of extra resources, since that module is only using 1% of the total. So it's not like you need to double the instances of the whole thing. I could be wrong but doesn't monolith usually refer to one really heavy app? As soon as you go from needing 1 instance to 2 (because 1 of the 1…

>doesn't monolith usually refer to one really heavy app?

No. Backend Server clusters are around almost as long as the internet exists.

>I would guess most of the time there's a high expense (lots of memory) in duplicating the entire monolith?

That's right, but there's a gotcha. Everytime you split your monolith into parts, that doesn't mean that each part will consume 1/n of original monolith startup resource. There will be a floor of memory usage. Consider 1 monolith that eats up 1GB to startup vs 4 microservices that uses 512MB each. Right from start you doubled the wasted memory from 1GB to 2GB. That only gets worse the more services are created. Another problem is that microservice/cloud folks loves to create anemic machines. Usually setting up 512MB RAM and half a core cpu to a service that needs 380mb minimum :) Thats 75% overhead and 25% of working memory. It's bonkers.

Re: Modules, not microservices

#462

Post by twblalock »

strictfp wrote: post #154
barrkel wrote: post #72

Microservices, while often sold as solving a technical problem, usually actually solve for a human problem in scaling up an organization. There's two technical problems that microservices purport to solve: modularization (separation of concerns, hiding implementation, document interface and all that good stuff) and scalability (being able to increase the amount of compute, memory and IO to the specific modules that n…

This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components. What happens if you need to redesign the architecture to meet new needs? That's right; it's not going to happen, because people will fight it tooth and nail. You also cannot produce any meaningful end-user value without involving several teams. Microservices is just "back…

> This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components.

That will always happen, and I've seen it happen in a monolith too (expressed as module ownership/ownership over part of the codebase).

It's inevitable in almost all organizations.

Re: Modules, not microservices

#463

Post by Sparkyte »

Answer is no.

It is about where the shoe fits. If you become too heavily dependent on modules you risk module incompatibility due to version changes. If you are not the maintainer of your dependent module you hold a lot of risk. You don't get that with microservices.

If you focus too much on microservices you introduce virtualized bloat that adds too much complexity and complexities are bad.

Modules are like someone saying it is great to be monolithic. Noone should upright justify an overly complicated application or a monolithic one.

The solution is to build common modules that are maintainable. You follow that up with multi-container pods have them talk low level between each other.

Stricking that exact balance is what is needed not striking odd justifications for failed models. It is about, "What does my application do?" and answering with which design benefits it the most.

Re: Modules, not microservices

#464

Post by com2kid »

hbrn wrote: post #444
com2kid wrote: post #414

Earlier quoted context omitted.

> This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. Ada solved this in the 80s, it isn't some unresolved field of comp sci. (Java already does this for array bounds!) > You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures yo…

> Ada solved this in the 80s, it isn't some unresolved field of comp sci Every solution comes at a cost. Where is Ada now? > Unit Tests are no different, except with worse syntax than built in language support. And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes. > At least with support in the type system yo…

> And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes.

So you don't advocate for unit tests, you don't want a powerful type system, what do you want?

> Every solution comes at a cost. Where is Ada now?

A source of features for newer languages, thus is the circle of programming language life.

> Sounds like dynamic typing with extra steps.

Static assertions based on build flags have been around for a very long time, in all sorts of languages. They are a performance/safety trade off.

Re: Modules, not microservices

#465

Post by thayne »

barrkel wrote: post #72

Microservices, while often sold as solving a technical problem, usually actually solve for a human problem in scaling up an organization. There's two technical problems that microservices purport to solve: modularization (separation of concerns, hiding implementation, document interface and all that good stuff) and scalability (being able to increase the amount of compute, memory and IO to the specific modules that n…

Another benefit of microservices is it allows you to have a permission boundary, which can restrict the scope of damage if a single server/service is compromised.

And for that matter it can (but not necessarily) limit how much damage a bad code release can do.

Of course you don't get those benefits for free just by using microservices, but impleminting those kind if boundaries in a monolith is a lot harder.

Re: Modules, not microservices

#466

Post by catlifeonmars »

ElectricalUnion wrote: post #426
catlifeonmars wrote: post #377

Earlier quoted context omitted.

Running a single server often can’t meet availability expectations that users have. This is orthogonal to scalability. You almost always need multiple copies.

You can run most applications on a single server - IBM S/390 big iron has very high reliability, redundancy and I/O bandwidth.

Yes but it’s literally a single point of failure. You probably want at least two servers in separate physical locations. Also how do you do deployments without interruption of service on a single server?

Re: Modules, not microservices

#467

Post by therealdrag0 »

whiplash451 wrote: post #460
therealdrag0 wrote: post #342

Earlier quoted context omitted.

I used to be monolith-curious, but what sold me on micro-services is the distribution of risk. When you work for a company where uptime matters having a regression that takes down everything is not acceptable. Simply using separate services greatly reduces the chances of a full outage and justifies all other overhead.

Why would using microservices reduce the chance of outages? If you break a microservice that is vital for the system, you are as screwed as with a monolyth.

Sure, but not all micro-services are vital. If your "email report" service has a memory leak (or many other noisy-neighbor issues) and is in a crash loop then that wont take down the "search service" or the "auth service", etc. Many other user paths will remain active and usable. It compartmentalizes risk.

Re: Modules, not microservices

#468

Post by Sparkyte »

barrkel wrote: post #72

Microservices, while often sold as solving a technical problem, usually actually solve for a human problem in scaling up an organization. There's two technical problems that microservices purport to solve: modularization (separation of concerns, hiding implementation, document interface and all that good stuff) and scalability (being able to increase the amount of compute, memory and IO to the specific modules that n…

What it is is using the wrong solution for a problem. Vice-versa the number of devs who justify monolithic apps is absurd. The justification of microservices is just as problematic.

It is about striking a balance. No reason should something be overly compounded or overly broken up.

Re: Modules, not microservices

#469

Post by therealdrag0 »

yCombLinks wrote: post #430
therealdrag0 wrote: post #342

Earlier quoted context omitted.

I used to be monolith-curious, but what sold me on micro-services is the distribution of risk. When you work for a company where uptime matters having a regression that takes down everything is not acceptable. Simply using separate services greatly reduces the chances of a full outage and justifies all other overhead.

How do microservices help here? You can deploy a monolith 10 times and have the same risk distribution.

It's not about replication, it's about compartmentalizing code changes / bugs / resource utilization. If you deploy a bug that causes a service crash loop or resource exhaustion isolating that to a small service reduces impact to other services. And if that service isn't core to app then the app can still function.

Re: Modules, not microservices

#470

Post by therealdrag0 »

anthonypasq wrote: post #368
habibur wrote: post #350

Earlier quoted context omitted.

> Simply using separate services greatly reduces the chances of a full outage and justifies all other overhead. or maybe run redundant monolith fail over servers. should work the same as micro services.

then you need to hotfix you need to re build a giant monolith that probably has thousands of tests and a 20-30 minute regression suite easily.

I have seen exactly this. Waiting for a 60+ min CI build during an outage is not a good look.
Post reply on HN