Modules, not microservices • Hacker News Board

Re: Modules, not microservices

#321

Post by michaelsalim » Tue, Jan 03, 2023, 4:52 PM UTC

TimPC wrote: post #239

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…

Modules aren't an alternative to microservices in a reasonable way though. And for all modules solve the modularization problem at the code level, they don't really solve modularization at the service level. The main alternative to microservices is monoliths and for many applications I far prefer microservices to monoliths. I want modularization in how I scale my app, I don't want to spin up a whole bunch of servers…

That's exactly what the comment you're replying is saying though. You're talking about scalability which they say modules doesn't exactly solve.

And I do agree that most people need less of those than they think.

Re: Modules, not microservices

#322

Post by MuffinFlavored » Tue, Jan 03, 2023, 4:54 PM UTC

zeroonetwothree wrote: post #317

MuffinFlavored wrote: post #271

Earlier quoted context omitted.

devil's advocate: > A few ways, the easiest being to scale up the whole monolith with more instance as far as I know, there's no way to granularly scale up a monolith. if the monolith has 20 or 50 or 100 modules and you need 1 or 2 of them scaled, you have to scale up the entire thing which is huge, expensive, etc. > Another way is run multiple "services" using the same codebase, so you have workload segmentation, ei…

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 100 inner "modules" needs to be scaled), I would guess most of the time there's a high expense (lots of memory) in duplicating the entire monolith? Unless you can scale threads or something instead of the entire process... Or if the entire process doesn't initiate 100 modules as soon as it is started (although I imagine it would in most cases)

Re: Modules, not microservices

#323

Post by jacobr1 » Tue, Jan 03, 2023, 4:54 PM UTC

esailija wrote: post #302

jacobr1 wrote: post #268

Earlier quoted context omitted.

That is harder when each service and team has their own repo and review process. Doesn't mean they won't just get merged, but there is increased friction and less-trust about random PRs from engineers that aren't actively working on the same team, so those PRs might get more scrutiny.

Then why cannot you have separate repos and review processes for modules? This has nothing to do with microservices vs modules.

Agreed - ther is no reason for that not to be the case. It just is that in practice (and not as some essentialism of how organizations needs to structure things) that miroservices tend proliferate git-repos and modules tend to be part of monorepos. But, sure, there is no need for that to be the case. So given a world like that, the repo seperation is what enforces the friction for junior devs to submit changes across repos. With monorepos it is easier.

Re: Modules, not microservices

#324

Post by MuffinFlavored » Tue, Jan 03, 2023, 4:55 PM UTC

jacobr1 wrote: post #313

MuffinFlavored wrote: post #271

Earlier quoted context omitted.

devil's advocate: > A few ways, the easiest being to scale up the whole monolith with more instance as far as I know, there's no way to granularly scale up a monolith. if the monolith has 20 or 50 or 100 modules and you need 1 or 2 of them scaled, you have to scale up the entire thing which is huge, expensive, etc. > Another way is run multiple "services" using the same codebase, so you have workload segmentation, ei…

> you have to scale up the entire thing which is huge, expensive, etc. Yes, yet people still do it that way. This is tradeoff against the costs of microservices. I'm not saying it is worth it, but yes, sometimes you can just inefficiently throw hardware resources at scaling problems. > this is interesting. a monolith with some form of IPC? why not do microservices at that point? that sounds like microservices-ish? Be…

is this a common nomenclature/design? how does a monolith that makes IPC/RPC calls to submodules not basically microservices?

Re: Modules, not microservices

#325

Post by lifeisstillgood » Tue, Jan 03, 2023, 4:55 PM UTC

zbobet2012 wrote: post #281

lifeisstillgood wrote: post #267

Earlier quoted context omitted.

I think it runs a bit deeper than that. Microservices are how the business views its self. Look, once upon a time managers designed the system that workers implemented. The factory assembly line, or the policy manual. But now the workers are CPUs and servers. The managers designing the system the workers follow are coders . I say coders are the new managers. Now this leaves two problems. The first is that there are a…

> there is no need to have the microservices built along Conways Law This is a misunderstanding of Conway's Law. Your code _will_ reflect the structure of your organization. If you use microservices so will their architecture. If you use modules, so will the modules. If you want a specific architecture, have your organization reflect the modules/microservices defined in that architecture.

But, I am trying to feel my way towards the idea that that was true when managers arranged systems for workers to follow, and then we came along to automate the current process. But if we have a system where the workers are the CPUs, then the people doing the managing are the coders.

The point ebing is that if workers are CPUs and coders are managers, then why worry about how the managers of the coders are arranged. Get rid of that management layer. Conway is not implying the financiers of the organisation affect the architecture.

This basically means that the microservices a company is built out of should more readily align to the realities of the business model. And instead of shuffling organisations around it would behove executives to look at the microservices.

One can more easily measure orders transferred, etc, if the boundaries are clearer.

Plus conway is just a ... neat idea, not a bound fate.

There is a caveat with the architecture reflecting the organisation of the software teams, but that usually follows the other to-be-automated structure as well.

Re: Modules, not microservices

#326

Post by EdSharkey » Tue, Jan 03, 2023, 4:56 PM UTC

It's easy to crap on EJB, lots to disagree with, but vendors like WebLogic were trying to do interesting things with them when they were ascending. I recall they had a nifty feature where if you were trying to call a remote EJB and the container knew it was deployed locally, it would automatically do a cheaper local call instead of RMI. It was awkward as hell, but it did do that, and it was faster. J2EE also had the concept of people _roles_ as part of its prescribed SDLC, something we could benefit from exploring, especially the _deployer_ role.

Ideally we could flexibly deploy services/components in the same way as WebLogic EJB. Discovery of where components live could be handled by the container and if services/components were deployed locally to one another, calls would be done locally without hitting the TCP/IP stack. I gather that systems like Kubernetes offer a lot of this kind of deployment flexibility/discovery, but I'd like to see it driven down into the languages/frameworks for maximum payoff.

Also, the right way to do microservices is for services to "own" all their own data and not call downstream services to get what they need. No n+1 problem allowed! This requires "inverting the arrows"/"don't call me, I'll call you" and few organizations have architectures that work that way - hence the fallacies of networked computing reference. Again, the services language/framework needs to prescribe ways of working that seamlessly establish (*and* can periodically/on-demand rebroadcast) data feeds that our upstreams need so they don't need to call us n+1-style.

Microservices are great to see, even with all the problems, they DO solve organizational scaling problems and let teams that hate each other work together productively. But, we have an industry immaturity problem with the architectures and software that is not in any big players' interest in solving because they like renting moar computers on the internet.

I have no actual solutions to offer, and there is no money in tools unless you are lucky and hellbent on succeeding like JetBrains.

Re: Modules, not microservices

#327

Post by HardlyCurious » Tue, Jan 03, 2023, 4:59 PM UTC

Perhaps we should coin the phase 'embedded microservices'.

Re: Modules, not microservices

#328

Post by surprisetalk » Tue, Jan 03, 2023, 4:59 PM UTC

mr90210 wrote: post #299

jameshart wrote: post #45

Earlier quoted context omitted.

I’ve said this before about applying Carmack’s architectural input on this topic: Games are highly stateful , with a game loop that iterates over the same global in-memory data structure as fast as it can. You have (especially in Carmack era games) a single thread performing all the game state updates in sequence. So shared global state makes a ton of sense and simplifies things. Most web applications are highly stat…

I felt suspicious as soon as I saw Jon Carmack’s website being mentioned in a conversation about Microservices.

I hope this quote from the Carmack essay shows that his argument isn't necessarily restricted to game development:

    ---------- style C:
     
    void MajorFunction( void ) {
            // MinorFunction1
     
            // MinorFunction2
     
            // MinorFunction3
     
    }

> I have historically used "style A" to allow for not prototyping in all cases, although some people prefer "style B". The difference between the two isn't of any consequence. Michael Abrash used to write code in "style C", and I remember actually taking his code and converting it to "style A" in the interest of perceived readability improvements.

> At this point, I think there are some definite advantages to "style C", but they are development process oriented, rather than discrete, quantifiable things, and they run counter to a fair amount of accepted conventional wisdom, so I am going to try and make a clear case for it. There isn't any dogma here, but considering exactly where it is and isn't appropriate is worthwhile.

> In no way, shape, or form am I making a case that avoiding function calls alone directly helps performance.

Re: Modules, not microservices

#329

Post by NicoJuicy » Tue, Jan 03, 2023, 5:01 PM UTC

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…

It's called "Conway's law"

https://ardalis.com/conways-law-ddd-and-microservices/#:~:te....

Re: Modules, not microservices

#330

Post by __jem » Tue, Jan 03, 2023, 5:04 PM UTC

MuffinFlavored wrote: post #324

jacobr1 wrote: post #313

Earlier quoted context omitted.

> you have to scale up the entire thing which is huge, expensive, etc. Yes, yet people still do it that way. This is tradeoff against the costs of microservices. I'm not saying it is worth it, but yes, sometimes you can just inefficiently throw hardware resources at scaling problems. > this is interesting. a monolith with some form of IPC? why not do microservices at that point? that sounds like microservices-ish? Be…

is this a common nomenclature/design? how does a monolith that makes IPC/RPC calls to submodules not basically microservices?

yes, it's very common design. sometimes called a "distirbuted monolith." it's not microservices because the number of additional services is usually small, and the codebase is still tightly coupled to itself (even if well factored in terms of modules). i.e., everything is still tested together, and there's still a single monolithic build and deployment process, and no team can go off and decide to write a service in a different language.