А еще давай я помогу разобраться с той кашей, которая у тебя в голове про веб приложения.
Обычное веб приложение требует:
- сервера приложений, который управляет рабочими процессами, пайплайнами обработки запросов и возможно маршалингом (тогда оно ни разу не микросервисное), если там один модуль подтягивает другой в общую память.
- само приложение, которое либо выполняется внутри инегрированного интерпретатора с JIT, вроде JVM (для java), CLR (.NET Framework) либо локальном интерпретаторе, вроде .net 5+, python, php, perl, ruby, либо выполняется нативно через API сервера приложений CGI

Популярные сервера приложений:
1) Apache Tomcat, JBoss/Wildfly и прочие сервера приложений полностью или частично реализующие Java EE.
Они запускают JVM, внутри которой поднимают приложения-сервлеты. Java EE стандартизирует логику взаимодействия этих веб-приложений друг с другом и логику написания своего сервера приложений для Java.
Java полностью изолирована от работы с железом и рулит своими ресурсами на уровне JVM. Рабочие процессы на стороне ОС отсутствуют, но есть сервлеты, их классы и их потоки исполнения.

2) Internet Inforamtion Services (IIS) и другие сервера приложений повторяющие архитектуру UNIX Internet Daemon
Этот сервер приложений приложений ровным слоем размазан по ОС. Каждый тип запроса реализует своя подсистема. За HTTP отвечает соответсвующий модуль, отдельный модуль для аутентификации и авторизации, отдельный для шифрования TLS. В случае с Windows - это драйверы ядра. Информация передаётся через сокеты и в общем случае вы можете привязками сделать всё что угодно и сцепить с любым интерпретатором. Странно что inetd не популярен в UNIX-подобных ОС для той самой блин задачи, для которой он был спроектирован... но это лирика. Главное то, что супер-серверы на стороне ОС. Внутри IIS, например, запускаются экземпляры службы публикации, которая кроме обслуживания статики может:
- прицепить к себе модуль ISAPI
- прицепиться к другому вебсерверу, вроде kestrel ( встроен .NET 5+), Node.JS
- использовать интегрированный пайпалайн .NET Framework 2.0/4.0 и .NET 5+ (но там всё равно внутрипроцессный kestrel)
- прицепиться к службам ОС, если они написаны по стандарту WCF
- прицепиться к отдельному серверу реализации рабочих процессов через CGI и работать как обычный вебсервер, вроде nginx.

Из-за того что Windows имеет драйверы ядра под это всё - IIS сейчас это единственный из живых серверов приложений, который реально способен работать с железом напрямую. Он управляем утилизацией процесса и памяти. Фиксирует приложения на разных ядрах если надо. Работает с топологией NUMA и умеет распределять ресурсы между теми рабочими процессами, которыми управляет.

3) Apache HTTPD и другие аналогичные ему с особенным API
Это максимально урезанная реализации inetd, чтобы не размазывать из по ОС. Apache HTTPD вообще сейчас не используется почти что как сервер приложений, только разве что в энтерпрайзе для обслуживания старых APR-модулей. Его пайплайны мало соотносятся с нынешним железом, поэтому он почти всегда виртуален и почти всегда веб-сервер (ради например SSI, который хорошо работает, но это не про сервера приложений).

Вот тут мы вспомним про Passenger и про то что Ruby on Rails рекомендовано использовать с ним. Логика там +/- такая же.

4) Юзерспейсные сервера приложений такие работающие через FastCGI
Есть реализации серверов приложений специально сделанных под интерпретатор, которые отдаются на вебсервер по через CGI. Те же известные php-fpm, uwsgi и прочие PSGI

Вообще большая часть интерпретаторов имеет свою логику работы с рабочими процессами и потоками. ASP.NET Core (не Framework), Node.JS, Java. Для доставки приложения перед ними ставят реверспрокси вроде HAproxy или nginx (в роли прокси).

Другие же используют отдельно стоящий сервер приложений обычно на базе FastCGI и имеют внутри интерфейсы *GI. Так работают php, python, perl.
Перед ними ставят любой вебсервер поддерживающий CGI/FastCGI.
nginx или HAproxy (в роли вебсервера) и потом доставлять наружу через реверспрокси.

А третьим нужен специальный модуль к специальному вебсерверу. ASP.NET Framework (через IIS), Ruby on Rails (через passenger) и можно пользоваться php, perl, python через Apache mod_*, но лучше не надо.

5) Kubernetes
Оно пожрало и уничтожило своих предшественников docker swarm и openstack magnum (для задачи). У этого логика в том, что всё вышесказанное упрощается и мы работаем с воркерами кубернетиса, которые работают с контейнерами. Внутри контейнера находится та самая инфраструктура специяичная для приложения и его интерпретатора/бинарника. Единственное, что кубернетис делает хорошего - позволяет хоть как-то управлять и обслуживать микросервисный проект, который писали мартышки на 5 разных языках в разное время. В остальном он скорее привносит проблемы, нежели их решает.

> Сейчас ещё модно стало тащить виртуальную машину, к ней сервер приложений, а в нём уже запускать программы, привет нода и всякие АСП.нет руби на рельсах и прочее.

Вот теперь после всего вышесказанного я могу объяснить, как мы до этого докатились.

ОС и её ядро умеют работать с железом. ОС умеет работать с сетевой подсистемой сервера. ОС имеет реализацию сервисов, в ядре есть планировщик процессов и много чего еще. ОС пишут для того, чтобы приложения работали на железе. Есть архитектура UNIX Internet Daemon, которая очень успешная и проверенная временем. Ирония в том, что всё это активно применяется только в Windows и это позор. То есть как сервер приложений IIS работает.

Java никогда в своей жизни не хотела работать на железе. Она максимально абстрагирует приложение от железа, и JVM выступает в роли ОС. Это тоже работает и Java делает это вполне успешно.

Apache HTTPD как сервер приложений скорее мертв, чем жив. Вся его оптимизация под железо и оптимизация его модулей под железо в далёком прошлом. Интегрироваться с ОС он при этом никогда не мог. Это юзерспейсный сервер не способный рулить железом и разделением ресурсов. NGINX Unit и Passenger такие же. Равно как и проекты, которые реализуют на коленке сервера приложений имени одного интепретатора, который потом отдаётся по FastCGI.

И вот у нас есть 4-х процессорный сервер с террабайтом RAM. И что по вашему произойдет если одно приложение разорвется по разным процессорам и разным блокам памяти? Правильно, оно будет тупить нищадно. А ничего что на современных процессорах по нескольку контроллеров памяти, которые по разному могут примапится к разным ядрам. А что такое Xeon Scalable? Весь этот зоопарк железа нативно поддерживает сейчас только IIS. Для всех остальных случаев - виртуализация. Сервера приложений имени интерпретатора слишком глупы, чтобы это понять и с этим работать, поэтому мы поставим гипервизор, который часть ОС. Он умный, он нарежет нам виртуальный сервак так, как надо. Пофигу что мы потеряли от 15-50% производительности приложения. А что с SMT/HyperThreading? Там вообще мрак! Вот окажется ваш воркер на псевдо ядре и что дальше?

И если вы думаете что Kubernetes и его контейнеры вас спасут от этой проблемы - то вы горько ошибаетесь. Поддержка железа в кубике всё еще в зачаточном состоянии. Ну то есть теоретически если вы:
- поставите однопроцессорные блейды на compute
- поставить отдельный от них сторадж в отдельной сети
- поднимите CLOS eBGP Undelay в топологии Spine Leaf
- начнете роутить Overlay-сети кубика через ECMP
- поставите сетевки, которые поддерживают Hardware SDN Offloading
- внутрь запихаете микросервисные приложения, которые:
-- строго-настрого стейтлесс
-- либо все однопоточные с одним рабочим процессом, либо вы отключите SMT/HyperThreading на железе
То вы получите вменяемую производительность. И если вас мучает вопрос, причем тут сеть, не удивляйтесь. Сами себе контейнеры придумали, будьте любезны правильно сеть настраивать и оффлоадить. Много видели barebone-кубиков? То-то же!

Реальность такова, что чтобы пользоваться даже кубиком вам нужно его воркеры виртуализовать и правильно назначить ресурсы через тот же KVM или другой гипервизор. То есть и там виртуалки. Кроме того безопасность ванильного кубика - это такая несмешная шутка, особенно когда нет виртуализации.

Сейчас контейнеры на железе массово не используются, потому что со стороны контейнерной оркестрации нет поддержки работы на разномастном железе. Безопасность изоляции не выдерживает никакой критики. При этом внутри контейнеров сервера приложений юзерспейсные и слишком глупые, чтобы реализовать это самим. Любой кто говорит о приросте производительности от использовании докерообразных контейнеров по сравнению с виртуализацией - теоретик, фантазёр и админ локалхоста.

Есть попытка у Red Hat сделать OpenShift (OKD) как barebone решение. Они там и kubevirt прикручивают и root запрещают и SELinux вменяют. Даже RHEV (oVirt) выкинули на мороз. Вон cgroups2 развивается тоже. Ну посмотрим как им это поможет, рано пока. Может лет через 10. В общем, что только не придумают, чтобы не юзать inetd-архитектуру.

P.S. Кстати LXD сабж из новости старается работать именно на железе в отличии от остальных контейнерных систем. И у него получается сильно лучше. Вот только у него с безопасностью еще большие проблемы, потому что Ubuntu c Apparmor и её тягой запускать всякую бяку от root.