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

481–490 of 671 posts

Re: Modules, not microservices

#481

Post by hbrn »

com2kid wrote: post #464
hbrn wrote: post #444

Earlier quoted context omitted.

> Ada solved this in the 80s, it isn't some unresolved field of comp sci Every solution comes at a cost. Where is Ada now? > Unit Tests are no different, except with worse syntax than built in language support. And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes. > At least with support in the type system yo…

> And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes. So you don't advocate for unit tests, you don't want a powerful type system, what do you want? > Every solution comes at a cost. Where is Ada now? A source of features for newer languages, thus is the circle of programming language life. > Sounds like dy…

> So you don't advocate for unit tests, you don't want a powerful type system, what do you want?

"Write tests. Not too many. Mostly integration."

Leave static typing for performance-critical sections.

> They are a performance/safety trade off.

So is dynamic typing. Only performance in this case means developer performance. Turns out most of our software is not landing airplanes, and developer performance is way more important than occasional non-critical bug that affects 5 users and gets fixed within a day.

Re: Modules, not microservices

#482

Post by em500 »

anthonypasq wrote: post #375
em500 wrote: post #116

Earlier quoted context omitted.

But is it generally easier to read and understand, say 10 files of 1000 lines or 100 files of 100 lines or 1000 files of 10 lines, compared to one 10,000 lines file? (I don't know the answer, and don't have any strong opinion on this.)

navigating between files is trivial in most real IDE's. i can just click through a method and then go back in 1 click

But navigating between functions / classes / paragraphs / sections is also trivial in most real editors.

Re: Modules, not microservices

#483

Post by ignite »

highspeedbus wrote: post #331
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…

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

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

But brutally difficult at scale. If you have hundreds of dependencies, a normal case, what do you do when one part of the monolith needs to update a dependency, but that requires you update it for all consumers of the dependency's API, and another consumer is not compatible with the new version?

On a large project, dependency updates happen daily. Trying to do every dependency update is a non-starter. No one has that bandwidth. The larger your module is, the more dependencies you have to update, and the more different ways they are used, so you are more likely to get update conflicts.

This doesn't say you need microservices, but the larger your module is, the further into dependency hell you will likely end up.

Re: Modules, not microservices

#484

Post by brunoborges »

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…

> scalability (being able to increase the amount of compute, memory and IO to the specific modules that need it).

I gave a talk [1] about scalability of Java systems on Kubernetes, and one of my recommendations is that Java-based systems - or any system on a runtime similar to the JVM, like CLR or even Go - should be scaled diagonally. Efficiency is the word.

While horizontal scaling can easily address most performance issues and load demand, in most cases it is the least efficient way for Java (and again, I risk saying .NET and Go), as these systems struggle with CPU throttling and garbage collectors.

In short, and exemplifying: one container with 2 CPUs and 2GB of RAM will allow the JVM to perform better, in general, than 2 containers with 1 CPU/1GB RAM each. That said, customers shouldn't be scaling horizontally to any amount more than what is adequately reasonable for resiliency, or unless the bottleneck is somewhere like disk access. For performance on the other hand, customers should be scaling vertically.

And Kubernetes VPA is already available. People just need to use it properly and smartly. If a Kubernetes admin believes a particular pod should double in number of replicas, the admin should consider: "would this microservice benefit even more from 1.5x more CPU/Memory than 2x more replicas?" and I bet to say that, in general, yes.

[1] https://www.youtube.com/watch?v=wApqCjHWF8Q

Re: Modules, not microservices

#485

Post by brundolf »

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…

One other thing they give you at a large organization is flexibility in your stack

If a team wants to try out a different language, or hosting model, or even just framework/tooling, those things can be really hard to do within the same codebase; much easier when your only contract is handling JSON requests. And if your whole organization is totally locked into a single stack, it's hard to keep evolving on some axes

(I'm generally against microservices, but this is one of the more compelling arguments I've heard for them, though it still wouldn't mean you need to eagerly break things up without a specific reason)

Re: Modules, not microservices

#486

Post by lemmsjid »

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.

If you have a truly modularized monolith, you can have a directed graph of dependent libraries, the leaves of which are different services that can start up. You can individually deploy leaf services and only their dependent code will go out. You can then rationalize which services can go down based on their dependency tree. If email is close to a root library, then yes a regression in it could bring everything down. If email is a leaf service, its code won’t even be deployed to most of the parallel services.

You can then have a pretty flexible trade off between the convenience of having email be a rooted library against the trade off of keeping it a lead service (the implication being that leaf services can talk to one another over the network via service stubs, rest, what have you).

This is SOA (Service Oriented Architecture), which should be considered in the midst of the microservice / monolith conversation.

Re: Modules, not microservices

#487

Post by kevincox »

brunoborges wrote: post #484
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…

> scalability (being able to increase the amount of compute, memory and IO to the specific modules that need it). I gave a talk [1] about scalability of Java systems on Kubernetes, and one of my recommendations is that Java-based systems - or any system on a runtime similar to the JVM, like CLR or even Go - should be scaled diagonally. Efficiency is the word. While horizontal scaling can easily address most performan…

Basically any software, even something in C or C++ with manual memory management will scale more efficiently vertically than horizontally. Basically it would be better to run one twice as big as it would be to run two instances on the same machine. There is almost always some overhead or cache that will make the performance of fewer instances better. The only exception is resource contention but it is generally not too hard to fix the important cases.

My default recommendation has always been to make instances "as big as possible, but no bigger". You may need 3 instances for redundancy, fault tolerance and graceful updates but past that you should probably scale up to near the size of your machine. There are obviously lots of complications and exceptions (for example maybe using most 3 instances uses 90% of your machines so you can't bin pack other processes there so it is better to use 4 instances at 70% as the machines will be used more efficiently) but bigger by default is generally a good option.

Re: Modules, not microservices

#488

Post by brunoborges »

kevincox wrote: post #487
brunoborges wrote: post #484

Earlier quoted context omitted.

> scalability (being able to increase the amount of compute, memory and IO to the specific modules that need it). I gave a talk [1] about scalability of Java systems on Kubernetes, and one of my recommendations is that Java-based systems - or any system on a runtime similar to the JVM, like CLR or even Go - should be scaled diagonally. Efficiency is the word. While horizontal scaling can easily address most performan…

Basically any software, even something in C or C++ with manual memory management will scale more efficiently vertically than horizontally. Basically it would be better to run one twice as big as it would be to run two instances on the same machine. There is almost always some overhead or cache that will make the performance of fewer instances better. The only exception is resource contention but it is generally not t…

> make instances "as big as possible, but no bigger"

Exactly.

But I am seeing more and more of the opposite: make instances as small as possible, and scale out (not up) if/when needed.

Re: Modules, not microservices

#489

Post by hbrn »

rglover wrote: post #436

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

This is something folks have been doing long before the microservices hype.

That said, server bottlenecks are not the only thing (micro)services are trying to address.

Re: Modules, not microservices

#490

Post by Existenceblinks »

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…

How about 2 erlang OTP nodes (homogenous)? I don't have a real world use case of that load but I often imagine I would have 1:2 RAM ratio to be able to vertical scale each time. For example, start with 1TB(A):2TB(B), if that's not enough, scale A to 4TB. When load climbs start to exceeds, scale B to 8TB .. so on alternately.
Post reply on HN