Уровни изоляции современного Java приложения

Всем привет!

Уже писал про плюсы Docker - https://t.me/javaKotlinDevOps/165

Но все ли так безоблачно?)

Обычно, когда сравнивают Docker с виртуальной машиной (VM) приводят такую схему

Из нее видно, что Docker - более легковесное решение по сравнению с VM. Ну а чем плоха установка на голое железо (bare metal) думаю понятно, уже писал об этом по ссылке выше.

Но ставить Docker контейнер на голое железо - тоже не самое лучшее решение в плане масштабируемости и отказоустойчивости. Если у вас публичное облако - Yandex CLoud, AWS - там под капотом используется виртуализация. Если свое частное облако - с большой вероятностью тоже.

Поэтому часто схема реального стека с Docker выглядит так

Но не забываем, что у нас же Java, Java работает на Java Virtual Machine, а это еще один слой изоляции

А так как наше приложение не работает само по себе, а с кем-то интегрируется, а самые распространенные протоколы интеграции основаны на HTTP, то скорее всего у нас где-то там находится Tomcat\Jetty или даже Netty в случае "реактивщины" или gRPC.

А так как сейчас правит бал концепция Inverse of Control в паре с Dependency Injection, то у нас появляется Spring Framework или его более легковесный аналог. Т.е. появляется Spring container, который вносит свои накладные расходы. Рисовать очередную картинку не буду)

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

P.S. А еще сверху BPM движок можно прикрутить)

P.P.S. Да и k8s, а он используется сейчас достаточно часто - тоже вполне себе еще один уровнеь

#java #jvm #docker #performance