Modules, not microservices

Post by JAlexoid » Wed, Jan 04, 2023, 12:32 AM UTC

thayne wrote: post #465

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.

Post by noogle » Wed, Jan 04, 2023, 12:35 AM UTC

jayd16 wrote: post #431

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…

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

Post by mavelikara » Wed, Jan 04, 2023, 12:40 AM UTC

vaughan wrote: post #531

mavelikara wrote: post #508

Earlier quoted context omitted.

The execution model of local calls are quite different from remote calls. Because of these differences, many efforts have been made, but "transparent remoting" is still not achieved [1]. [1] https://scholar.harvard.edu/waldo/publications/note-distribu...

Thanks for the interesting read. I agree with sentiment of the paper in that it can never be fully transparent. When I say "it should just be a process of identifying hot function calls..." this is admittedly a little contrived - there would need to be a more thorough analysis. The main point seems to be that partial failure is too difficult to handle without explicitly declaring some objects as "remote". > Merging t…

Post by JAlexoid » Wed, Jan 04, 2023, 12:46 AM UTC

nlnn wrote: post #269

lightbendover wrote: post #250

Earlier quoted context omitted.

> they force alignment on one language or at least runtime How is this possibly a down-side from an org perspective? You don't want to fracture knowledge and make hiring/training more difficult even if there are some technical optimizations possible otherwise.

The capabilites of the language and the libraries available for it can sometimes be a good reason for dealing with multiple languages. E.g. if you end up having a requirement to add some machine learning to your application, you might be better off using Tensorflow/PyTorch via Python than trying to deal with it in whatever language the core of the app is written in.

Post by ascendantlogic » Wed, Jan 04, 2023, 12:56 AM UTC