Modules, not microservices • Hacker News Board

Re: Modules, not microservices

#411

Post by lamontcg » Tue, Jan 03, 2023, 6:41 PM UTC

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

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 consistent hashing to pin customers to individual webservers.

For stuff like order history or customer data, those services sat in front of their respective databases and provided consistent hashing along with availability (providing a consistent write-through cache in front of the SQL databases used at the time).

I wouldn't call those areas where it makes things more efficient rare, but actually common, and it comes from letting your data dictate your microservices rather than letting your organiation dictate your microservices (although if teams own data, then they should line up).

Re: Modules, not microservices

#412

Post by Xeoncross » Tue, Jan 03, 2023, 6:41 PM UTC

locutous wrote: post #404

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…

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

Re: Modules, not microservices

#413

Post by Sohcahtoa82 » Tue, Jan 03, 2023, 6:41 PM UTC

tail_exchange wrote: post #358

I don't think microservices are the answer to everything, but I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers. Monoliths are way slower to deploy than microservices, and when you have hundreds or thousands of changes going out every day, this means lots of changes being bundled together in the same deployment, and as a consequence, lots of bugs. Havin…

> I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers.

Are those thousands of developers working on a single product? If so, then I'd argue that you have way too many developers. At that point, you'd need so many layers of management that the overall vision of what the product is gets lost.

Re: Modules, not microservices

#414

Post by com2kid » Tue, Jan 03, 2023, 6:44 PM UTC

hbrn wrote: post #370

com2kid wrote: post #340

Earlier quoted context omitted.

Java's original type system, while static, was far from being powerful enough to provide strong guarantees of safety. Saying age is an int is great, but Java doesn't let you say age is an int ranging from 0 to 130. You can of course create an age object, but the constraints on that object cannot be expressed within the type system. So you have to add unit tests instead, the unit tests in effect extend the type system…

> Java doesn't let you say age is an int ranging from 0 to 130 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. You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not reall…

> 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 you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer.

Unit Tests are no different, except with worse syntax than built in language support.

At least with support in the type system you can turn off range checks for production builds. Meanwhile unit tests only run when invoked, giving less confidence than type checks that undergoing simulated usage as part of daily test builds.

There is of course a gradient, JavaScript exists on one side of that gradient (unit tests are needed for everything, starting with what type of object is even being returned), Java exists in the middle, and you have actual type safe languages farther along.

The point I was originally aiming to make is that Java is statically typed, but its type system is not so powerful as to negate the need for unit tests.

Re: Modules, not microservices

#415

Post by 8note » Tue, Jan 03, 2023, 6:45 PM UTC

jcadam wrote: post #391

switch007 wrote: post #365

Earlier quoted context omitted.

They’re likely just trying to pad their resume for the next gig.

Reminds me of the time at a previous job where a poorly supervised engineer developed a complex application using LabVIEW (an utterly inappropriate use of the technology) and then took a new job with National Instruments, leaving a shop full of C and Ada programmers to maintain it.

For the unfamiliar, National Instruments makes LabView

Re: Modules, not microservices

#416

Post by jacobsimon » Tue, Jan 03, 2023, 6:47 PM UTC

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…

That’s a really interesting point - something that could probably be addressed by module-level logging and metrics. That said, even as a pro-monolith advocate, I can see why it’s preferable to not allow any one module/service to consume all the resources for your service in the first place. The service boundaries in microservice architectures can help enforce resource limits that otherwise go unchecked in a larger application.

Re: Modules, not microservices

#417

Post by hannofcart » Tue, Jan 03, 2023, 6:51 PM UTC

tail_exchange wrote: post #358

I don't think microservices are the answer to everything, but I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers. Monoliths are way slower to deploy than microservices, and when you have hundreds or thousands of changes going out every day, this means lots of changes being bundled together in the same deployment, and as a consequence, lots of bugs. Havin…

> but I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers.

You're likely right.

I think what most detractors of microservices are pointing to is that most companies don't reach thousands of devs in size. Or even hundreds.

Re: Modules, not microservices

#418

Post by mk89 » Tue, Jan 03, 2023, 6:52 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…

> A better rule is for one service to own writes for a table, and other services can only read that table,

Been there: how do you handle schema changes?

One of the advantages that having a separate schema per service provides is that services can communicate only via APIs, which decouples them allowing you to deploy them independently, which is at the heart of microservices (and continuous delivery).

The way I see it today: everyone complains about microservices, 12 factor apps, kubernetes, docker, etc., and I agree they are overengineering for small tools, services, etc., but if done right, they offer an agility that monoliths simply can't provide. And today it's really all about moving fast(er) than yesterday.

Re: Modules, not microservices

#419

Post by cogman10 » Tue, Jan 03, 2023, 6:54 PM UTC

jacobsimon wrote: post #416

cogman10 wrote: post #381

Earlier quoted context omitted.

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…

That’s a really interesting point - something that could probably be addressed by module-level logging and metrics. That said, even as a pro-monolith advocate, I can see why it’s preferable to not allow any one module/service to consume all the resources for your service in the first place. The service boundaries in microservice architectures can help enforce resource limits that otherwise go unchecked in a larger ap…

It's one I've ran into a few times in my company (which has a large number of these types of endpoints).

The silly thing is that something like the JVM (which we use) really wants to host monoliths. It's really the most efficient way to use resources if you can swing it. The problem is when you give the JVM 512GB of ram, it hides the fact that you have a module needlessly loading up 64gb of ram for a few seconds. Something that only comes to a head when that module is ran concurrently.

Re: Modules, not microservices

#420

Post by zbobet2012 » Tue, Jan 03, 2023, 6:54 PM UTC

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…

Microservices enable independent scale _domains_. This means they can be more scaleable and dense, but it's not necessarily true.