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

421–430 of 671 posts

Re: Modules, not microservices

#421

Post by dogleash »

0xblinq wrote: post #78
c-fe wrote: post #73

I am working on a project that uses a microservice architecture to make the individual components scalable and separate the concerns. However one of the unexpected consequences is that we are now doing a lot of network calls between these microservices, and this has actually become the main speed bottleneck for our program, especially since some of these services are not even in the same data center. We are now attem…

> However one of the unexpected consequences How the hell... like... who decided to do Microservices in the first place if they didn't know this? This is such a rookie mistake. It's like somebody right out of high school just read on a blog the new way is "microservices" and then went ahead with it.

>How the hell... like... who decided to do Microservices in the first place if they didn't know this?

Microservices can have both design utility and simultaneously been a major fad.

Lurking reddit and HN you can watch development fashions come and go. It's really really profoundly hard to hold a sober conversation on splitting merits from limitations in the middle of the boom.

tl;dr: gartner_hype_cycle.png

Re: Modules, not microservices

#422

Post by locutous »

JamesBarney wrote: post #373
BackBlast wrote: post #134

Earlier quoted context omitted.

Those boundaries also increase the cost of development. If you are institutionally incapable of enforcing coding standards such that you can't prevent juniors from coupling your modules, perhaps it's worth it. But there are more efficient ways to build and run an engineering organization. The best place for such boundaries is at the team/division/org level, not team-internal or single dev-internal like microservices…

Any way you slice it, it's hard to manage/align/coordinate a 100 devs. If done right microservices is a way to transform part of your organization challenge into a technical one, which for many organizations is the right move. The biggest issue is if you aren't large enough to have challenging organizational issues it's much easier to just solve the very solvable organizational issues than implement and use microserv…

> If done right microservices is a way to transform part of your organization challenge into a technical one, which for many organizations is the right move.

Famous last words, if done right... Or you just multiply your organizational issue with a technical one.

Re: Modules, not microservices

#423

Post by zbobet2012 »

esailija wrote: post #349
TimPC wrote: post #239

Earlier quoted context omitted.

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…

Just because the monolith image contains all code doesnt mean each deployment needs to run all that code. Or even same version of the code. A deployment can run only a small portion of the code determined by deployment args. It can even run an older version than other deployments

That's just a microservice enabled by configuration.

Re: Modules, not microservices

#424

Post by osigurdson »

closeparen wrote: post #333
osigurdson wrote: post #167

Earlier quoted context omitted.

>> because they keep people honest around module boundaries Imagine a world where every pip/nuget/cargo package was a k8s service called out-of-process and needed to be independently maintained. We would have potentially hundreds of these things running, independently secured via mTLS, observability and metrics for each, and all calls run out of process. This is the abysmally slow hellscape that some are naively advo…

But of course team scaling is determined this way. Merely releasing a library version has zero business impact. To have impact, library teams must go around to every consumer team and beg them to accept a version bump. This is a) shitty work for which it is impossible to retain people, and b) intractable without an enormous labor force once the number of consumers is big enough. Services can be continuously deployed…

If library teams could force consumers of the library to upgrade the problem is seemingly solved.

Is this correct or are there other aspects that you are considering?

Re: Modules, not microservices

#425

Post by zbobet2012 »

pjmlp wrote: post #209
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…

Strong typed languages with support for binary modules are just as good keeping people honest. Each team gets to distribute libraries over repos (COM, JAR, DLL, whatever), no way around that unless they feel like hacking binaries.

You'll need to support loading two versions of each DLL into memory and invoking both on some percentage of servers to be able to replicate a microservice though.

The important part of microservices isn't just API boundaries, it's lifecycle management. This CAN be done with a DLL or JAR, but it's MUCH harder today.

Re: Modules, not microservices

#426

Post by ElectricalUnion »

catlifeonmars wrote: post #377
dahfizz wrote: post #366

Earlier quoted context omitted.

Microservices are less efficient , but are still more scalable . Servers can only get so big. If your monolith needs more resources than a single server can provide, then you can chop it up into microservices and each microservice can get its own beefy server. Then you can put a load balancer in front of a microservice and run it on N beefy servers. But this only matters at Facebook scale. I think most devs would be…

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.

Re: Modules, not microservices

#427

Post by throwaway894345 »

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…

> There's two technical problems that microservices purport to solve

There's a third technical problem that microservices solve, and it's my favorite: isolation. With monoliths, you provide all of your secrets to the whole monolith, and a vulnerability in one module can access any secret available to any other module. Similarly, a bug that takes down one module takes down the whole process (and probably the whole app when you consider cascading failures). In most mainstream languages, every module (even the most unimportant, leaf node on the dependency tree) needs to be scoured for potential security or reliability issues because any module can bring the whole thing down.

This isn't solved at the language level in most mainstream languages. The Erlang family of languages generally address the reliability issue, but most languages punt on it altogether.

> The real reason that microservices may make sense is because they keep people honest around module boundaries.

Agreed. Microservices, like static type systems, are "rails". Most organizations have people who will take shortcuts in the name of expedience, and systems with rails disincentivize these shortcuts (importantly, they don't preclude them).

Re: Modules, not microservices

#428

Post by highspeedbus »

Zvez wrote: post #387
highspeedbus wrote: post #331

Earlier quoted context omitted.

>they force alignment on one language or at least runtime A sane thing to do. >they force alignment of dependencies and their versions A sane thing to do. Better yet to do it in a global fashion, along with integration tests. >they can require lots of RAM if you have many modules with many classes You can't make the same set of features build in a distributed manner comsume _less_ RAM than the monolith counterpart. G…

> a sane thing to do imaging your application contains of two pieces - somewhat simple crud, that requires to respond _fast_ and huge batch processing infrastructure, that needs to work as efficient as possible, but doesn't care about single element processing time. And suddenly 'the sane thing to do' is not the best thing anymore. You need different technologies, different runtime settings and sometimes different ru…

You're absolutely right. My comment is towards the view that using a single language for a certain Project Backend is a bad thing per se. The online vs batch processing is the golden example of domains that should be separated in different binaries, call it microsservices or services or just Different Projects with Nothing in Common. Going further than that is where the problems arise.

Re: Modules, not microservices

#429

Post by jayd16 »

eklitzke wrote: post #356
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…

I just want to point out that for the second problem (scalability of CPU/memory/io), microservices almost always make things worse. Making an RPC necessarily implies serialization and deserialization of data, and nearly always also means sending data over a socket. Plus the fact that most services have some constant overhead of the footprint to run the RPC code and other things (healthchecking, stats collection, etc.…

So tell me, who is making microservices for calls that could be done wholly in memory? How are you handling rollbacks and such for this in memory logic?

Aren't you still writing out to external data stores? If that's the case then its really not a comparison of in process to a RPC, it just two RPC hops now, no?

Re: Modules, not microservices

#430

Post by yCombLinks »

therealdrag0 wrote: post #342
gunnarmorling wrote: post #169

I really like modular designs, but this article is missing some key limitations of monolithic applications, also if they are really well modularized (this is written mostly from the perspective of a Java developer): * they force alignment on one language or at least runtime * they force alignment of dependencies and their versions (yes, you can have different versions e.g. via Java classloaders, but that's getting tr…

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.
Post reply on HN