The costs of microservices (2020) • Hacker News Board

Re: The costs of microservices (2020)

#151

Post by jupp0r » Mon, Oct 30, 2023, 4:59 PM UTC

lr4444lr wrote: post #27

Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing 2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment…

To add another to your list:

Being able to easily use different programming languages. Not every language is a good fit for every problem. Being able to write your machine learning deduction services in Python, your server side rendered UI in Rails and your IO and concurrency heavy services in Go might justify the additional overhead of having separate services for these three.

Re: The costs of microservices (2020)

#152

Post by rvrs » Mon, Oct 30, 2023, 4:59 PM UTC

I feel like this article conflates monoliths with monorepos. You can have a more flexible (though not as "flexible" as microservices, perhaps for the better) engineering by just following the "libraries" pattern mentioned in the article and splitting each of the libraries into their own repos, and then having version bumps of these libraries as part of the release process for the main application server.

Doing it this way gets you codebase simplicity, release schedule predictability, and makes boundaries a bit more sane. This should get you a lot farther than the strawmanned "one giant repo with a spaghetti mess of code" model that the author posits.

Re: The costs of microservices (2020)

#153

Post by jethro_tell » Mon, Oct 30, 2023, 5:00 PM UTC

rmbyrro wrote: post #122

voxic11 wrote: post #76

Earlier quoted context omitted.

Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depends on version 2 of Library C then I have a clear problem because most popular programming languages don't support referencing multiple different versions of the same library.

Can't we just isolate these two services in containers, using different library versions? They don't need to be microservices in order to isolate dependencies, do they? In Python, for instance, you don't even need containers. Just different virtual environments running on separate processes.

I suppose if you do that, they will communicate over the network likely via api and have the ability to scale independently.

You just invented microservices, lol.

Re: The costs of microservices (2020)

#154

Post by andorov » Mon, Oct 30, 2023, 5:01 PM UTC

gedy wrote: post #147

eduction wrote: post #89

Earlier quoted context omitted.

Wouldn't this just be "having one or two services"? I don't think that's the same as "microservices". Correct me if I'm wrong, but isn't "microservices" when you make internal components into services by default , instead of defaulting to making a library or class?

For some reason, most of the people I've worked with recently are either fully into monoliths or lots of fine grained, interdependent microservices. They don't seem to understand there's a useful middleground of adding fewer, larger data services, etc. It's like SOA isn't a hot topic so people aren't aware of it.

I've been using the term 'macro-services' to describe this middle ground.

Re: The costs of microservices (2020)

#155

Post by arethuza » Mon, Oct 30, 2023, 5:02 PM UTC

Scarblac wrote: post #25

jeffbee wrote: post #9

Earlier quoted context omitted.

I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. I think everyone recognizes that it makes sense that domain name resolution is performed by an external service, and very few people are out there integrating a recursive DNS resolver and cache into their monolith. And yet, this long-standing division of responsibility never seems to count as an example…

_Services_ are obviously a good idea (nobody is arguing something like PostgreSQL or Redis or DNS or what have you should all run in the same process as the web server). _Microservices_ attract the criticism. It seems to assume something about the optimal size of services ("micro") that probably isn't optimal for all kinds of service you can think of.

You do see people arguing for running SQLite in-process rather than using a separate database server like PostgreSQL?

Re: The costs of microservices (2020)

#156

Post by wongarsu » Mon, Oct 30, 2023, 5:03 PM UTC

lr4444lr wrote: post #142

eduction wrote: post #89

Earlier quoted context omitted.

Wouldn't this just be "having one or two services"? I don't think that's the same as "microservices". Correct me if I'm wrong, but isn't "microservices" when you make internal components into services by default , instead of defaulting to making a library or class?

I don't want to get too tied up in the terminology, but "microservices-first" does not seem to be the problem the post is describing: One way to mitigate the growing pains of a monolithic backend is to split it into a set of independently deployable services that communicate via APIs. The APIs decouple the services from each other by creating boundaries that are hard to violate, unlike the ones between components run…

Without getting tied up in the whole "every language except assembly, Python and possibly JavaScript already solved this problem by forcing people to adhere to module-level APIs" argument, I think the crux of the issue is that the article just defines microservice architecture as any architecture consisting of multiple services, and explicitly states "there doesn’t have to be anything micro about the services". Which imho is watering down the term microservices too much. You don't have microservices as soon as you add a second or third service.

Re: The costs of microservices (2020)

#157

Post by bob1029 » Mon, Oct 30, 2023, 5:04 PM UTC

> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging.

This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g. banks & financial instutitions) who will rake you over hot coals for every single 3rd party dependency you bring.

We currently operate with one monolithic .NET binary distribution which is around 250 megs (gzipped). Not even the slightest hint of cracks forming. So, if you are sitting there with a 10~100 meg SaaS distribution starting to get nervous about pedantic things like "my exe doesnt fit in L2 anymore", then rest assured - Your monolithic software journey hasn't even begun yet.

God forbid you find yourself with a need to rewrite one of these shitpiles. Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent?

Re: The costs of microservices (2020)

#158

Post by 0xbadcafebee » Mon, Oct 30, 2023, 5:06 PM UTC

So where's "the costs of monoliths" post? They don't show up here, because everyone is out there cluelessly implementing microservices and only sees those problems. If everyone were out there cluelessly implementing monoliths, we'd see a lot of "monoliths bad" posts.

People don't understand that these systems lead to the same amount of problems. It's like asking an elephant to do a task, or asking 1000 mice. Guess what? Both are going to have problems performing the task - they're just different problems. But you're not going to get away from having to deal with problems.

You can't just pick one or the other and expect your problems to go away. You will have problems either way. You just need to pick one and provide solutions. If 'what kind of architecture' is your biggest hurdle, please let me work there.

Re: The costs of microservices (2020)

#159

Post by marcosdumay » Mon, Oct 30, 2023, 5:08 PM UTC

wnolens wrote: post #123

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optima…

From the developer POV, the difference is on the interface. And while we have all kinds of tools to help us keeping a monolith in sync and correct, the few tools we have to help with IPC can not do static evaluations and are absolutely not interactive.

From the ops POV, "deploy is more complex" is a large understatement. Each package is one thing that must be managed, with its own specific quirks and issues.

Re: The costs of microservices (2020)

#160

Post by nevinera » Mon, Oct 30, 2023, 5:10 PM UTC

marcosdumay wrote: post #148

nevinera wrote: post #115

Earlier quoted context omitted.

Did you mean to reply to somebody else? I'm a huge believer in automated testing, and if I said something that can be interpreted otherwise I'd like to clarify it.

I guess the GP's issue is because automated tests (and every other kind of validation) imposes architectural constraints on your system, and thus are an exception to your rule. I don't think that rule can be applied as universally as you stated it. But then, I have never seen anybody breaking it in a bad way that did also break it in a good way, so the people that need to hear it will have no problem with the simplif…

Hm. I think maybe you're using "system" to mean a different thing than I am? I thinking of "the system" as the thing that is executing in production - it provides the business behavior we are trying to provide; there is a larger "system" surrounding it, that includes the processes and engineers, and the CI/CD pipelines - it too has an "architecture", and _that_ architecture gets (moderately) more complex when you add CI/CD. Is that where our communication is clashing?

Because the complexity of that outer system is also important, but there are a few very major differences between the two that are probably too obvious to belabor. But in general, architectural complexity in the inner system costs a lot more than it does in the outer system, because it's both higher churn (development practices change much slower than most products) and higher risk (taking production systems offline is much less permissible than freezing deployments)