Серверы приложений в эру микросервисов и облаков

WildFly

Лет десять назад, когда я начинал заниматься разработкой на Java, подавляющее большинство корпоративных проектов разворачивалось в сервлет-контейнерах, серверах приложений и OSGi-контейнерах. Справедливости ради стоит отметить, что микросервисная архитектура уже тогда будоражила умы разработчиков, а Java EE, Spring и другие фреймворки предоставляли хороший инструментарий для разработки проектов с микросервисной архитектурой. И такие проекты точно так же разворачивались в серверах приложений.

Серьёзные изменения в 2014 году принёс фреймворк Spring Boot, который позволил запускать сервисы самостоятельно, не разворачивая их в серверах приложений. На деле это решалось использованием встроенного сервлет-контейнера. Чего-то сверхъестественного в этом не было, встроить тот же Apache Tomcat в своё приложение для обработки HTTP-запросов мог любой желающий, просто разработчики Spring Boot дали сообществу универсальный набор инструментов для разработки микросервисов.

Следом за Spring Boot начали появляться и другие фреймворки, ориентированные на разработку проектов с микросервисной архитектурой: Micronaut, Helidon, Quarkus и прочие. Вместе с этим набирали популярность инструменты контейнеризации: Docker, Kubernetes, Cloud Foundry, Openshift, которые позволяют развёртывать сервисы в изолированном окружении.

И вот недавно в мой голове возник вопрос: «А актуальны ли нынче на фоне инструментов контейнеризации серверы приложений?». Как оказалось, вполне актуальны. Проекты GlassFish (ныне Eclipse GlassFish), WildFly, Payara Server, Apache TomEE и прочие существуют и развиваются до сих пор, следовательно, они всё ещё актуальны.

Развёртывание сервисов отдельными процессами имеет как плюсы, так и минусы. К плюсам можно отнести, например разделение ресурсов между сервисами, если один из сервисов «упадёт» по памяти, то это может никак не сказаться на работоспособности других сервисов (хотя всякое бывает). Серверы приложений в свою очередь позволяют здорово экономить ресурсы: оперативную память, соединения с СУБД или брокерами очередей сообщений и т.д.

Приложения, развёрнутые в одном сервере приложений, могут работать с общим пулом соединений с СУБД, кешем и даже ресурсами JVM: стандартными библиотеками, библиотеками приложения (привет OSGi-бандлам и модулям в JBoss Modules), серьёзно экономя ресурсы серверов. Конечно, это порождает задачи мониторинга и анализа состояния самого сервера приложений, а так же его тонкой настройки, но в то же время может принести достаточно пользы.

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

Для себя я сделал вывод, что серверы приложений актуальны и по сей день. Да, они под влиянием тенденций претерпели некоторые изменения, ровно как и способы их применения, но они могут быть всё так же полезны.