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

The costs of microservices (2020)

robertovitillo.com

Post reply on HN
Print view View original

211–220 of 410 posts

Re: The costs of microservices (2020)

#211

Post by insanitybit »

crabbone wrote: post #207
insanitybit wrote: post #38

Earlier quoted context omitted.

Network calls are a powerful thing to introduce. It means that you have an impassable boundary, one that is actually physically enforced - your two services have to treat each other as if they are isolated. Isolation is not anything to scoff at, it's one of the most powerful features you can encode into your software. Isolation can improve performance, it can create fault boundaries, it can provide security boundarie…

The reality of this situation is that the tool everyone is using to build microservices is Kubernetes. It imposes a huge tax on communication between services. So your aspiration as to improving performance fly out of the window. On top of this, you need to consider that most of the software you are going to write will be based on existing components. Many of these have no desire to communicate over network, and your…

Microservices definitely predate k8s, but sure, lots of people use k8s. I don't know what penalty you're referring to. There is a minor impact on network performance for containers measured in microseconds under some configurations. Maybe Kubernetes makes that worse somehow? I think it does some proxying stuff so you probably pay for a local hop to something like Envoy. If Envoy is on your system and you're not double-wrapping your TLS the communication with it should stay entirely in the kernel, afaik.

http://domino.research.ibm.com/library/cyberdig.nsf/papers/0...

In no way is this throwing out performance. It's sort of like saying that Kafka is in Java so you're throwing away performance when you use it, when there are massive performance benefits if you leverage partition isolation.

> Many of these have no desire to communicate over network, and your micro- or w/e size services will have to cave in to their demands. Simple example: want to use Docker? -- say hello to UNIX sockets. Other components may require communication through shared memory, filesystem, and so on.

I'm not sure what you're referring to. Why would that matter at all? I mean, ignoring the fact that you can easily talk to Docker over a network.

> Finally, isolation is not a feature of microservices,

Isolation is a feature of any process based architecture, whether it's SoA, actors, or microservices.

> well, you might have function-level isolation, but you won't have class- or module- or program-level isolation,

You get isolation at the service layer. I don't see why that would be contentious, it's obvious. If you're saying you want more isolation, ok, you can write your code to do that if you'd like.

> first doesn't prescribe the size.

Yep, the actor model is very low level. Microservice architecture is far more prescriptive. It's one of the reasons why I think Microservice architecture has been far more successful than actor based systems.

Re: The costs of microservices (2020)

#212

Post by wg0 »

ahoka wrote: post #190
wg0 wrote: post #165

Earlier quoted context omitted.

How the whole open source ecosystem is working fine and delivering software while depending upon each other for almost decades all the while not ever being in the same room and yet having no microservices? I mean take your pick, anything open source be it desktop or web has a huge and deep dependency tree all the way down to libc. Just wondering. EDIT: Typos and desktop.

Someone does the integration work for you, that’s why it works. Try running some distro that just grabs the latest upstream versions and see how often things break.

And that's my point.

Re: The costs of microservices (2020)

#213

Post by wg0 »

mardifoufs wrote: post #209
wg0 wrote: post #165

Earlier quoted context omitted.

How the whole open source ecosystem is working fine and delivering software while depending upon each other for almost decades all the while not ever being in the same room and yet having no microservices? I mean take your pick, anything open source be it desktop or web has a huge and deep dependency tree all the way down to libc. Just wondering. EDIT: Typos and desktop.

Open source projects rarely involve live services, or providing SaaS. In those situations I think microservices are much more helpful

But Microservices have nothing to do with scaling or deployment. The main selling point is that it scales across teams etc?

Re: The costs of microservices (2020)

#214

Post by nevinera »

manicennui wrote: post #77
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…

I rarely see anyone claiming that microservices are never justified. I think the general attitude toward them is due to the amount of Resume Driven Development that happens in the real world.

Eh, I think a lot more of it is caused by optimism than RDD - people who haven't _tried to do it_ look at the mess they've got, and they can see that if it were divided into domain-based services it would be less of a mess.

And the process seems almost straightforward until you _actually try to do it_, and find out that it's actually fractally difficult - by that point you've committed your organization and your reputation to the task, and "hey, that was a mistake, oops" _after_ you've sunk that kind of organizational resources into such a project is a kind of professional suicide.

Re: The costs of microservices (2020)

#215

Post by highspeedbus »

Monoliths are like heavy trucks.

Microservices are like motorcycles.

Surely you can delivery 15 metric tons of wood with either of them. You will just need a lot of motorcycles to match capacity.

Somehow a big part of industry became convinced that of course that approach is better, since motorcycles are cheaper*, easier to scale*, and solve some managerial problems*.

* They don't, IMHO.

>its components become increasingly coupled over time

>The codebase becomes complex enough that nobody fully understands every part of it

>if a change introduces a bug - like a memory leak - the entire service can potentially be affected by it.

I believe the only real solution to those challenges is Competency, or Programmer Professionalism. Uncle Bob had some great points on this topic.

https://www.youtube.com/watch?v=BSaAMQVq01E

Re: The costs of microservices (2020)

#216

Post by kgeist »

>As each team dictates its own release schedule and has complete control over its codebase, less cross-team communication is required, and therefore decisions can be taken in less time.

In my experience, it's the opposite. When a feature spans several microservices (and most of them do), there's much more communication to coordinate the effort between several isolated teams.

Re: The costs of microservices (2020)

#217

Post by mardifoufs »

wg0 wrote: post #213
mardifoufs wrote: post #209

Earlier quoted context omitted.

Open source projects rarely involve live services, or providing SaaS. In those situations I think microservices are much more helpful

But Microservices have nothing to do with scaling or deployment. The main selling point is that it scales across teams etc?

I think it's a bit of both IME. It helps a lot with deployment across teams.

Re: The costs of microservices (2020)

#218

Post by orochimaaru »

superfrank wrote: post #203
bob1029 wrote: post #157

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

I think this is a false dichotomy. Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options. Microservices doesn't need to mean it's the wild west and every team can act without considering the larger org. There can and should be rules to keep a certain level of consistency across tea…

Not sure why you’re downvoted - but you’re right. We heavily use microservices but we have a well defined stack. Python/gunicorn/flask/mongodb with k8s. We run these on Kafka or rest api. We even runs jobs and corn jobs in k8s.

Functional decomp is left to different teams. But the libraries for logging, a&a, various utilities etc are common.

No microservices that don’t meet the stack unless they’re already developed/open source - eg open telemetry collectors.

Edit: I think the article is a path to a book written by the author. It’s more of an advertisement than an actual assessment. At least that’s my take on it.

Re: The costs of microservices (2020)

#219

Post by 998244353 »

manicennui wrote: post #121
jihadjihad wrote: post #2

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices

I just wanted to note that static typing isn't required for autocomplete. JetBrains has IDEs for languages like Ruby and Python that can do it. If you open the REPL in a recent version of Ruby you get much of what you expect from an IDE with a statically typed language (with regards to autocomplete and syntax checking).

You are correct, but static typing does make it a lot easier. Working with Rider feels like working with an IDE that fully understands the code, at least structurally. Working with PyCharm feels like working with an IDE that makes intelligent guesses.

Re: The costs of microservices (2020)

#220

Post by mike_ivanov »

nevinera wrote: post #3

The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going…

I want this printed and neatly framed. Where to order?
Post reply on HN