[krimeo]

> How is that related?

I thought we were talking about running applications reliably. Why is complete linux userspace bundled separately in each container?

> Environments and languages change. Yes.

> That's entirely different to running programs with zero-downtime deployments, load-balancing and traffic management, health monitoring, logging and observability, secret and config management, storage volumes, security roles, and much more.

That's a lot of new requirements in addition to "running applications reliably". Most applications simply do not need that. And I believe this is the point of the original comment you replied to.

- zero-downtime deployments -> not needed for most applications (for example, twitter outages are not a big deal either). Btw how do you do zero-downtime of (websocket) streams with kubernetes? ;)

- load-balancing and traffic management -> in standard k8s you are pushing all traffic through one active LB (nginx) anyway => strip most of the extra layers and you dont even need that LB

- health monitoring, logging etc. -> you can use an existing solution that provides only the functionality you need, most of the work will be in your app anyway (every application needs different metrics ..)

The argument is that most applications do not need to scale at this level (until you need anycast DNS returning per-node IPs or at least geodns, you are not scaling that much anyway) and can be implemented in simpler manner hence easier and cheaper to maintain, audit and secure.

I do not want security roles, storage volumes and config management or observability I want my application to reliably and quickly serve my customers and be easy to maintain and debug.

If you want to discuss how to design architecture for scalable applications which keep all state in distributed databases but based on a platform with stable ABI that would surely be an interesting debate as well.

[manigandham]

It's a container and can be as thin or fat as you want with it's contents. You don't need to include linux inside if you don't want to. I've built containers with nothing more than a few native executables. It's just a packaging format, but easier to build and deploy than other formats like tarballs.

If you don't need K8S then don't use it. What's the problem? Run your app on your server and ignore everything else.

But most of these features have nothing to do with scale and are more about usability, reliability and consistency. Sure you can do it yourself but that's less efficient than just letting K8S do it all in one standardized way and interface.

> "I want my application to reliably and quickly serve my customers and be easy to maintain and debug."

That's what K8S helps with. I've spent 10 years running large distributed applications handling billions of requests per day in multiple regions. I don't care about the ABI and don't see why that's relevant, but I do know that K8S has made many things easier in actually running these apps.

[krimeo]

> If you don't need K8S then don't use it. What's the problem? Run your app on your server and ignore everything else.

See the original comment you replied to, he is clearly complaining about the whole infrastructure and solutions getting too complex for very little benefit, I just elaborated on that point because there is some truth to it. It is not the case for your scenario handling billions of requests per day in multiple regions - that's where it makes a lot of sense to use k8s! But very few applications need that.

> It's a container and can be as thin or fat as you want with it's contents.

But you can't rely on the platform, except for the kernel because linux kernel ABI is stable hence why the containers are done in this way. I am not complaining about it, I am exaplning the reasoning. Now imagine if you could rely on and share more services provided by the platform that just the kernel ;).

> I don't care about the ABI and don't see why that's relevant

Fair enough but then I don't understand why you replied to my comment saying the containers are designed in this way because of unstable userpace ABI if you don't care about this.

> "I want my application to reliably and quickly serve my customers and be easy to maintain and debug." >> That's what K8S helps with

For certain solutions, absolutely! For other solutions a simple stateful applications is simpler and easier to maintain and debug (again, that's how I read the first comment in this thread).