Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You want microservices, but do you need them?

docker.com

Post reply on HN
Print view View original

131–140 of 151 posts

Re: You want microservices, but do you need them?

#131

Post by dragonwriter »

soco wrote: post #55
echelon wrote: post #41

Earlier quoted context omitted.

If you have workloads with different shapes, microservices make sense. If not, do the monolith thing as long as you can. But if you're processing jobs that need hand off to a GPU, just carve out a service for it. Stop lamenting over microservices. If you've got 100+ engineers and different teams own different things, try microservices. Otherwise, maybe keep doing the monolith. If your microservice is as thin as leftp…

I wonder, at which point is a service getting called microservice? The team-sized service advocated by the usual argument does not sound that "micro" to me - but is most of the times the right size.

"Microservices" were called "microservices" because "service-oriented architecture" had devolved in practice, and even moreso in the general consciousness which had largely rejected it for this reason, into near-monoliths that supported SOAP and the WS-* series of standards for integration.

Then, after they became popular, people got carried away with the "micro" bit, and "microservices" started getting rejected because the associated practice had skewed in the opposite direction that had caused "SOA" to be rejected.

I guess the next iteration needs to be "goldilocks services".

Re: You want microservices, but do you need them?

#132

Post by SatvikBeri »

cogman10 wrote: post #69
SatvikBeri wrote: post #62

Earlier quoted context omitted.

Yeah, but building a docker image tends to be a lot heavier weight and slower, in my experience, than uploading a single jar

Heavier weight? Yes. Slower? Should be the same performance. Unless you are on a non-linux host, then there is no docker penalty. The only time I can think where a JVM might be faster is if you have a multi-tenant setup. In that case, the JVM can be more effective with the GC vs having multiple JVMs running.

I didn't mean the application is less performant (indeed, it might be even more performant since there are more things we can tweak), but that the overall build + upload process is noticeably slower. I remember it taking <1 minute to rebuild + deploy an uberjar in 2016, and on an application of similar complexity today it takes somewhere between 3-15 minutes. Admittedly, this is a different company, language, and setup, so there are a lot of other potential differences.

Re: You want microservices, but do you need them?

#133

Post by awesome_dude »

com wrote: post #117
awesome_dude wrote: post #110

Earlier quoted context omitted.

This is kind of why I've never bothered to look at it - everyone /says/ it's a wonderful thing, but... nobody uses it in production, or hobbies (apart from the diehard fans) It might see the light of day at some point in the future, but if the past is anything to go by...

Well the canonical example is WhatsApp, but there are loads of other success stories if you care to look. Small teams, big results is a characteristic that I’m very interested in, in our post-ZIRP reality.

I'm familiar with Whatsapp and its relationship with erlang (there's RabbitMQ as well, which I always forget when asked..)

But they're the only real case studies

If I were to say "Go", people can point to big projects like Docker, Kubernetes, etcd, Googles internal use, and a few others (Uber?)

Erlang just doesn't have that sort of buy in, which is concerning because it's been around longer than Go (as a FOSS language), heck it's been around longer than Python (but it was proprietary back then)

Speaking as someone that's never used it, that's got "don't bother unless you've got an academic interest in it" written all over it

Re: You want microservices, but do you need them?

#134

Post by cogman10 »

SatvikBeri wrote: post #132
cogman10 wrote: post #69

Earlier quoted context omitted.

Heavier weight? Yes. Slower? Should be the same performance. Unless you are on a non-linux host, then there is no docker penalty. The only time I can think where a JVM might be faster is if you have a multi-tenant setup. In that case, the JVM can be more effective with the GC vs having multiple JVMs running.

I didn't mean the application is less performant (indeed, it might be even more performant since there are more things we can tweak), but that the overall build + upload process is noticeably slower. I remember it taking <1 minute to rebuild + deploy an uberjar in 2016, and on an application of similar complexity today it takes somewhere between 3-15 minutes. Admittedly, this is a different company, language, and set…

Yeah, it'll be unrelated to docker.

Uberjars are (typically) extracting all the classes from jar dependencies and combining them into a single jar. That's all gzip compression work.

Container layers are simply saved off filesystem modifications. If you use something like Jib to build your image, then the actual deployable should actually be a lot smaller than what you could do with an uber jar. That's because Jib will put your dependencies in one layer and your application jar in another. Assuming you work like most everyone, then that means the only thing that usually gets transferred is your application code. Dependencies only get sent if you change them or the base image.

Re: You want microservices, but do you need them?

#135

Post by rockemsockem »

roncesvalles wrote: post #74
rockemsockem wrote: post #27

You need multiple services whenever the scaling requirements of two components of your system are significantly different. That's pretty much it. These are often called micro services, but they don't have to actually be "micro"

That's the most nonsensical reason to adopt microservices imo. Consider this: every API call (or function call) in your application has different scaling requirements. Every LOC in your application has different scaling requirements. What difference does it make whether you scale it all "together" as a monolith or separately? One step further, I'd argue it's better to scale everything together because the total breat…

What are you talking about.

When people talk about scaling requirements they are not referring to minutiae like "this function needs X CPU per request and this other function needs Y CPU per request", they are talking about whether particular endpoints are primarily constrained by different things (i.e. CPU vs memory vs disk). This is important because if I need to scale up machines for one endpoint that requires X CPU but the same service has another endpoint requiring Y memory whereas my original service only needs Z memory and Y is significantly larger than Z then suddenly you have to pay a bunch of extra money to scale up your CPU-bound endpoint because you are co-hosting it with a memory-bound endpoint.

If all your endpoints just do some different logic and all hit a few redis endpoints, run a few postgres queries, and assemble results then keep them all together!!!

EDIT: my original post even included the phrase "significantly different" to describe when you should split a service!!! It's like you decided to have an argument with someone else you've met in your life, but directed it at me

Re: You want microservices, but do you need them?

#136

Post by rockemsockem »

venturecruelty wrote: post #78
roncesvalles wrote: post #74

Earlier quoted context omitted.

That's the most nonsensical reason to adopt microservices imo. Consider this: every API call (or function call) in your application has different scaling requirements. Every LOC in your application has different scaling requirements. What difference does it make whether you scale it all "together" as a monolith or separately? One step further, I'd argue it's better to scale everything together because the total breat…

At this point, I'm convinced that too many people simply haven't built software in a way that isn't super Kubernetes-ified, so they don't know that it's possible. This is the field where developers think 32 GB of RAM isn't enough in their laptop, when we went to the moon with like... 4K. There is no historical or cultural memory in software anymore, so people graduate not understanding that you can actually handle 10…

There is in fact software that consumes large amounts of resources for fundamental reasons that saves real dollars when it is split into different units for the purpose of scaling those units independently. Most of that software is not primarily dealing with the number of connections it has.

Re: You want microservices, but do you need them?

#137

Post by rockemsockem »

Nextgrid wrote: post #93
venturecruelty wrote: post #78

Earlier quoted context omitted.

At this point, I'm convinced that too many people simply haven't built software in a way that isn't super Kubernetes-ified, so they don't know that it's possible. This is the field where developers think 32 GB of RAM isn't enough in their laptop, when we went to the moon with like... 4K. There is no historical or cultural memory in software anymore, so people graduate not understanding that you can actually handle 10…

Many developers started their career during the ZIRP era where none of the typical constraints of "engineering" (cost control, etc) actually applied and complexity & high cloud bills were seen as a good thing, so no wonder.

Splitting up responsibilities into separate services should in fact primarily be done to reduce costs.

Re: You want microservices, but do you need them?

#138

Post by rockemsockem »

siliconwrath wrote: post #83
rockemsockem wrote: post #27

You need multiple services whenever the scaling requirements of two components of your system are significantly different. That's pretty much it. These are often called micro services, but they don't have to actually be "micro"

Another case I’ve seen is to separate a specific part of the system which has regulatory or compliance requirements that might be challenging to support for the rest of the larger system, eg HIPAA compliance, PCI compliance, etc. (To clarify, I’m not disagreeing with you!)

Good point, I was primarily thinking of engineering reasons, but alas there are indeed other concerns.

Re: You want microservices, but do you need them?

#139

Post by rockemsockem »

Nextgrid wrote: post #95
twodave wrote: post #36

Earlier quoted context omitted.

I came here to say the same. If you’re arguing either for or against microservices you’re probably not thinking about the problem correctly. Running one big service may make sense if your resource needs are pretty uniform. Even if they’re not you need to weight the cost of adding complexity vs the cost of scaling some things prematurely or unnecessarily. Often this is an acceptable precursor to splitting up a process…

You can still horizontally scale a monolith and distribute requests equally or route certain requests to certain instances; the only downside is that those instances would technically waste a few hundred MBs of RAM holding code for endpoints they will never serve; however RAM is cheap compared to the labor cost of a microservices environment.

For those numbers, yeah you should absolutely do that. But you might want to host your database on different machines than your application because the numbers will likely differ by much more than a few hundred MBs.

Re: You want microservices, but do you need them?

#140

Post by rockemsockem »

zmmmmm wrote: post #79
rockemsockem wrote: post #27

You need multiple services whenever the scaling requirements of two components of your system are significantly different. That's pretty much it. These are often called micro services, but they don't have to actually be "micro"

It has other advantages. Operationally, it is very nice to be able to update one discrete function on its own in a patch cycle. You can try to persuade yourself you will pull it off with a modular monolith but the physical isolation of separate services provides guarantees that no amount of testing / review / good intentions can. However, it's equally an argument for SOA as it is for microservices.

There are some other benefits like having different release cycles for core infrastructure that must never go down vs a service that greatly benefits from a fast pace of iteration.

Literally one function per service though is certainly overkill though unless you're pretty small and trying to avoid managing any servers for your application.

Post reply on HN