new | show | ask | jobs Github

IshKebab 4 hours ago

The only reasons I've seen to use microservices:

* It makes it easier to use multiple different languages.

* You can easily scale different parts of your application independently.

* Organisational convenience.

Usually though you don't need any of that.

▲

teraflop 4 hours ago | parent | next [-]

> You can easily scale different parts of your application independently.

Just to add that I think some people assume this is something they need, even when there's no basis for it.

Do you actually need 1 instance that handles Foo-type requests, and 99 instances that handle Bar-type requests, or would you be fine with 100 instances that are capable of handling either Foo or Bar as necessary?

The distinction only really matters if there is some significant fixed overhead associated with being available to serve Foo requests, such that running an extra 99 of those processes has a cost, regardless of how much traffic they serve. For instance, if every Foo server needs GBs of static data to be held in RAM, or needs to be part of a Paxos group, or something like that.

But if your services are stateless, then you probably don't benefit at all from scaling them independently.

▲

dilyevsky 2 hours ago | parent | next [-]

> But if your services are stateless, then you probably don't benefit at all from scaling them independently.

Quite easy to run into hardware, OS or especially language runtime (looking at you Ruby, Python) limitations when pushing even moderately high traffic even for totally stateless applications

▲

teraflop 2 hours ago | parent [-]

I don't really understand what you mean by this or how it relates to what I said.

I certainly wasn't suggesting that you can vertically scale a service to handle unlimited traffic on a single instance.

The point is that if you have stateless services, where the resources being consumed per request are mainly CPU and network bandwidth, then "scaling independently" is not a useful thing to do. You can just scale everything instead of artificially restricting which instances can handle which kinds of requests.

	▲	dilyevsky 19 minutes ago \| parent [-]
		This is obviously incorrect conclusion because scaling stateful services is considerably harder than stateless and typical design involves heavy caching (which technically is state just not durable state)

▲

weitendorf 2 hours ago | parent | prev [-]

Of course there are plenty of situations where you don't need this and probably a lot of people optimize for "being able to scale independently" without understanding when they would even need that/why those two services don't even make sense to scale independently.

If your services are stateful/are being treated as persistent, IMO even more commonly than your example, you really want to make sure they're only bundled together if they directly interact at the application layer. Disk is unlike ram/cpu in that it generally increases montonically in the absence of explicit handling of its size, so if applications share disks unnecessarily you've basically made it so that each fails due to lack of disk space when any other applciation on the same disk fail, and any cleanup/management of eg pruning old data or wiping out logs or cleaning up some extra noisy/disruptive disk operation now has to be coordinate with each other application sharing those disks. Terrible situation to be in.

For stateless services the big reason you might want separable scaling is for cost-controls and operations. The problem is not necessarily that two stateless services are bundled, it's that giving permission for stateless service VeryImportantFoo to scale up aggressively also requires granting UnimportantBundledBar and all the other bundled services that same permission for aggressive scaling. If these APIs are exposed to the internet in anyway, (or if their usage patterns and availability requirements are completely different, eg one is some webhook plugin or old marketing demo and the other is your PayMeTonsOfMoney api) that's a really bad idea, because you've basically made it possible for someone to send a bunch of api requests and waste a lot of your money, or lowered your availability/scaling of your important stuff to prevent that.

Also, scaling applications independently is roughly synonymous with releasing them independently (eg keeping one truly constant and un-modified rather than rebuilding it and releasing it in the same push) which is again important if you have varying availability/reliability requirements (releasing the slack bot should not require rebuilding the main backend and pushing it again).

Let me be clear though, even though most developers think about microservices in terms of engineering considerations, these are ultimately all business requirements. If you don't need cost controls or to care about availability, or aren't worried that "kyle tried to push the slackbot and now prod is down" will happen, don't think you need to do all this stuff anyway because "it's what you should do". I'm mostly writing this because I think developers who are inexperienced or haven't used microservices before tend to not realize there are almost always business and coordination and operations problems being solved when companies (who know what they're doing) invest significant time and resources into microservices.

▲

marcosdumay 4 hours ago | parent | prev | next [-]

You don't need to split your code over a network to have organizational convenience.

Your first point is valid. There are few ways to get it, and it's not clear if services are harder or easier than the alternatives.

▲

worksonmine 3 hours ago | parent | prev [-]

Sometimes there are reasons to separate projects. I wouldn't put a scraper or pdf generator with the main application.

There are benefits to keeping some things small and isolated. Teams that have problems with micro services are doing it wrong.