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

431–440 of 671 posts

Re: Modules, not microservices

#431

Post by jayd16 »

cogman10 wrote: post #381
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…

You know, I don't really think microservices are fundamentally more scalable. Rather, they expose scaling issues more readily. When you have a giant monolith with the "load the world" endpoint, it can be tricky to pinpoint the the "load the world" endpoint (or, as is often the case, endpoint*s*) is what's causing issues. Instead, everyone just tends to think of it as "the x app having problems." When you bust the mon…

Another way to look at this is microservices reduce the blast radius of problems.

Re: Modules, not microservices

#432

Post by throwaway894345 »

dahfizz wrote: post #366
eklitzke wrote: post #356

Earlier quoted context omitted.

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.…

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…

Yeah, it's bin packing, not straight efficiency. Also, people seem to exaggerate latency for RPC calls. I often get the feeling that people who make these latency criticisms have been burned by some nominal "microservices" architecture in which an API call is made in a hot loop or something.

Network latency is real, and some systems really do run on a tight latency budget, but most sane architectures will just do a couple of calls to a database (same performance as monolith) and maybe a transitive service call or something.

Re: Modules, not microservices

#433

Post by gillh »

While we are on the topic, I would like to point out that the decoupled nature of microservices is governed by queuing theory. Microservices are especially susceptible to positive feedback loops and cascading failures.

Going back to systems thinking, flow control (concurrency and rate limiting) and API scheduling (weighted fair queuing) are needed to make these architectures work at any scale. Open source projects such as Aperture[0] can help tackle some these issues.

[0] https://github.com/fluxninja/aperture

Re: Modules, not microservices

#434

Post by pjmlp »

zbobet2012 wrote: post #425
pjmlp wrote: post #209

Earlier quoted context omitted.

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.

Not at all.

Sure if one likes to make things harder than they are supposed to be, there are lots of paths down that road.

Re: Modules, not microservices

#435

Post by TillE »

kerblang wrote: post #407
mbork_pl wrote: post #13

Earlier quoted context omitted.

> It's okay to have files with 10,000 lines. Ever since my time as a mathematician (I worked at a university) and using LaTeX extensively, I never understood the "divide your documents/code into many small files" mantra. With tools like grep (and its editor equivalents), jumping to definition, ripgrep et al., I have little problem working with files spanning thousands of lines. And yet I keep hearing that I should di…

At the risk of getting lost in a swamp of not particularly good answers, it's most useful if you have scope control : If you have language keywords that allow you to designate a function as "The context/scope of this function never escapes this file," then multiple files suddenly become very useful, because as a reader you get strong guarantees enforced by a compiler, and a much easier time understanding context . Th…

This is one of alarmingly few sane, articulate comments amid an extremely weird conversation about how maybe a giant mess of spaghetti is good, actually.

Yeah sure overengineering is a thing, but you're way off the path if you're brushing aside basic modularization.

Re: Modules, not microservices

#436

Post by rglover »

The easiest approach I've found to this whole debate: start with a monolith, making notes about where you think a server is most likely to have bottlenecks.

Push the monolith to production, monitoring performance, and if and when performance spikes in an unpleasant way, "offload" the performance intensive work to a separate job server that's vertically scaled (or a series of vertically scaled job servers that reference a synced work queue).

It's simple, predictable, and insanely easy to maintain. Zero dependency on third party nightmare stacks, crazy configs, etc. Works well for 1 developer or several developers.

A quote I heard recently that I absolutely love (from a DIY construction guy, Jeff Thorman): "everybody wants to solve a $100 problem with a $1000 solution."

Re: Modules, not microservices

#437

Post by fruit2020 »

worldsayshi wrote: post #124
kubb wrote: post #40

Earlier quoted context omitted.

Respectfully, rants by niche celebrities are not something we should base our opinions on. If you're a single dev making a game, by all means, do what you want. If you work with me in a team, I expect a certain level of quality in the code you write that will get shipped as a part of the project I'm responsible for. It should be structured, tested, malleable, navigable and understandable.

I feel like this is a knee jerk reaction to the hyperbole of the parent comment rather than the contents of the actual linked talks. I'm watching Jonathan Blow's talk linked above and your comment does not seem relevant to that. Jonathan's points so far seem very reasonable. Rather than arguing for 10000 lines of code it's arguing that there is such a thing as premature code split. Moving code into a separate method…

So you think it’s easier to keep in your head lambdas in a 10k line file vs methods split by functionality across a number of smaller files?

Re: Modules, not microservices

#438

Post by grogenaut »

Xeoncross wrote: post #412
locutous wrote: post #404

Earlier quoted context omitted.

> 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 200 threads, 12TB of RAM, with a pipe upwards of 200GB/s. This isn't even as big as you can go, this is a reasonable off the shelf item. If your service doesn't need more than this, maybe don't break it up. :) I believe that this level of service can no longer accurately be…

Helps to have a language that natively uses more CPU cores and/or training for the devs. Ruby, Python, PHP and Node.js startups have to figure out how to use the cores while C++, Rust, Erlang and Go have no issues running a single process that maxes out all 64 CPU cores.

we have all sorts of problems maxing out all the cores on a c6.24xl if youre memory or network conatrained. Even if CPU constrained it can be hard.

Re: Modules, not microservices

#439

Post by locutous »

jacobr1 wrote: post #266
BackBlast wrote: post #203

Earlier quoted context omitted.

If you can't admit the problem. Can't stare it down. Can't comprehend it. Then I don't know how you can ever solve it. I try to avoid these places, not easy though.

Are there any examples of large organizations that don't have this problem? I can imagine places with small teams that are basically isolated that can operate efficiently, but once you scale to point where dozens to hundreds of teams needing to cooperate, it seems like all you have is tradeoffs and fundamental coordination and scaling issues. I've never heard of a big org that didn't have some flavor of disfunction r…

Jim Keller mentioned this problem in the hardware space. Basically when people breach the interface design and couple things and how that coupling limits your ability to grow the design.

When he helped set the tone for the Zen architecture he took AMDs existing people, set them on a more aggressive path and one of the cardinal tenants was you could not cheat on the interfaces. This is one of the nuggets you can pull from his interviews.

It's possible. It happens. And the end results can be industry changing.

Re: Modules, not microservices

#440

Post by jayde2767 »

lamontcg wrote: post #411
eklitzke wrote: post #356

Earlier quoted context omitted.

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.…

I was working at Amazon when they started transitioning from monolith to microservices, and the big win there was locality of data and caching. All of the catalog data was moved to a service which only served catalog data so its cache was optimized for catalog data and the load balancers in front of it could optimize across that cache with consistent hashing. This was different from the front end web tier which used…

Thank you for pointing out caching. I was going to reply, at some point, that architecture in a well-designed distributed system considers both locality of data and the ability to cache data as a means of improving both latency and throughput and often does appreciably.

But I don't have to now.

Post reply on HN