The costs of microservices (2020)

On Kubernetes impact on network performance: well... on one hand, Kubernetes doesn't come with its own networking. So, it's unfair to say that it affects networking, because it simply cannot do it. On the other hand, it requires external networking component to do certain things in certain ways. So, indirectly, it does affect networking.

So, here are some concerns that affect performance, they mostly come from the need of various translations done by either iptables, eBPF analogues, arpatables, DNS server(s). If you read about benchmarks of Calico and Cilius, you'll see that they concentrate on performance of eBPF code necessary to do all these translations. My claim about performance tax is based on the idea that w/o Kubernetes you wouldn't need such translations (but, of course, you could build your own version of Kubernetes networking with a lot of software-defined virtualization, in which case you'd be in the same boat).

> Kafka

Is as horrid as it sounds. It's awful performance-wise on all counts. I'm not sure what point are you trying to make. Can you choose a better example? I mean, Kafka performs very poorly in all configurations, so, to think that it can be a good example of software that wants to achieve good resource utilization is just bound to give you bad results.

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

You either genuinely didn't understand what this is about, or pretend to not understand something really simple. "Micro" in microservices means that your services are small. There aren't any meaningful isolation tools or approaches when it comes to microservices, because isolation at the level of service doesn't matter / is trivial to achieve by many other means / is not a problem in real-world programs.

> Yep, the actor model is very low level.

This is simply a nonsense statement. Low on what scale? Your answer reads as if it was generated by a chatbot. I.e. words from the same general domain strung together, but make no sense.

> Microservice architecture has been far more successful than actor based systems

How did you count? How do you even tell if something is a microservice-based? This is just as absurd of a claim as saying "78% of enterprises use Kubernetes" (I believe I saw this unfettered inanity on cloud-native foundation's Web site). How do you tell if it's successful? What if actor model is a more generic description which beside other things, also captures microservices?

I mean, in more simple language, this is talking out of your rear. It's not a real argument anyone should pay attention to.

> Kubernetes doesn't come with its own networking. So, it's unfair to say that it affects networking, because it simply cannot do it.

You're the one who brought it up?

> My claim about performance tax is based on the idea that w/o Kubernetes you wouldn't need such translations (but, of course, you could build your own version of Kubernetes networking with a lot of software-defined virtualization, in which case you'd be in the same boat).

You don't need any of those and I don't know why you think otherwise. You can just use the host network and do whatever you want, as with any container.

> I'm not sure what point are you trying to make.

That Kafka's architecture allows you to put data into partitions and route it based on that data, which allows for "shared nothing" architectures. But whatever, you're clearly not going to get this point from this example. To be clearer, your point of "you pay a cost here so you're losing performance" ignores that you can get performance elsewhere.

> There aren't any meaningful isolation tools or approaches when it comes to microservices, because isolation at the level of service doesn't matter / is trivial to achieve by many other means / is not a problem in real-world programs.

Not true at all. Services that own a domain of work are a great place to perform isolation and security boundaries.

> Low on what scale?

As in an actor is a foundational primitive for asynchronous computation. You have to build up protocols on top of actors, hence all of OTP.

> I.e. words from the same general domain strung together, but make no sense.

I think that's because I actually know what I'm talking about and you're finding it hard to keep up?

> How did you count?

Because it's obvious? Like it's not even close. Actor based systems are exceedingly rare, microservices are not.

> I mean, in more simple language, this is talking out of your rear. It's not a real argument anyone should pay attention to.

One of us actually knows what they're talking about and I doubt we'll agree who ti is.

Yep. Mentally it's rather like the unpredictable behavior you'd get if an API server was passing code to the client for it to execute.

So many "modern" things in cloud are just relearning Java application servers (and .NET) by people that never used them.

Eh?

Default queue implementations come with co-operating queuing out of the box. I suppose you could use some hand-rolled queue with no internal locking, but this is disingenuous.

> you'll have race conditions or no cooperative queuing between multiple instances of the application.

You're thinking micro-service again here. There's no need to have multiple "instances" at all. Any concurrency is handled internal to the application itself with use of e.g. fibers, threads, etc. A good argument to why monoliths have drawbacks can't be "well its not a microservice". :)

> A good monolith still requires all the same hard decisions about modularity, high-availability etc.

Never said it didn't. What it doesn't require is all the tech stack to support that over many instances, because there's one instance. A large majority of µServices is just re-implementing what your runtime gives you for free.