Рождение, взлет и вымирание серверов приложений

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

Рассвет живых серверов

Сейчас уже мало кто помнит бурный рост ИТ-индустрии в 90е и историю появления компаний вроде Sun Microsystems, Oracle или Bea Systems.

Компании эти появились и росли взрывными темпами из-за интереса крупного бизнеса к ИТ и завышенных ожиданий — разработчиков ПО (не в РФ конечно) тогда натурально закидывали деньгами, ожидая манны небесной.

Концепция «сервера приложений» и продукты ее реализующие, играли ключевую роль в корпоративной разработке тех лет и оставались таковыми очень долго — до начала 2010х, когда начала активно развиваться концепция «микросервисов». Вместе с виртуализацией и контейнерами, микросервисы вытеснили и заменили сервера приложений.

В наши дни страшный как вьетнамская проститутка, корпоративный говнокод аккуратно распихивают по отдельным приложениям «микросервисам», каждое из которых разворачивается в отдельном контейнере.

Затем это все обвязывают оркестратором и проксями, думая что теперь-то все будет надежно работать.

Другой мир

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

На петоне был и есть Zope — тоже позиционируемый как «сервер приложений», но какой-то массовой популярности за ним замечено не было.

Microsoft в своей платформе .NET также с самого начала использовала термин «сервер приложений», в качестве которого у них выступал IIS.

Но технически это было и есть куда ближе к подключаемым модулям старого доброго Apache2, чем к среде выполнения и разделяемым ресурсам предоставляемым JEE сервером.

Поэтому рассказ ниже будет именно про серверы приложений J2EE/JEE/JakartaEE (за#бали переименовывать), работающие на Java.

Сам я познакомился с серверами приложений довольно поздно — в 2005 м году и это был JBoss (который теперь Wildfly).

И сразу же погрузился по самые ноздри в адское месиво большого J2EE проекта — это был портал для обмена снимками с электронных микроскопов (!) от NT-MDT. Написанный аутсорсерами откуда-то из Новосибирска, без единой строчки описания, руководства или тестов.

Большой, грязный и вонючий кусок электронного говна, который нужно было еще запустить и затем как-то поддерживать — все как мы любим.

Впрочем, все последующие энтерпрайз-проекты на серверах приложений мало чем отличались, говенность почему-то у них всех на уровне ДНК.

Но я немного увлекся, давайте все же вернемся к теме.

Благо на уровне голой концепции «сервер приложений» — класивая и логичная штука.

Приложениенесущий крейсер

Внутренние корпоративные приложения — просты и однотипны по своей сути, при этом их нужно много.

«Наклепать и настрогать» — любимые термины именно из корпоративной разработки а не из какой-то другой сказки про Буратино.

Еще все они используют одни и те же ресурсы компании, причем часто одновременно:

базы данных, хранилища файлов, почтовые шлюзы, сервисы авторизации типа LDAP и так далее.

Запускать по 150 сервисов на Java в виде отдельных приложений — дорого и сильно неоптимально. А если в каждом сервисе еще открыть пул подключений к одной и той же базе — эта база скорее всего помрет.

Или помрете уже вы — от рук DBA, им почему-то не нравится когда их базы сильно нагружают.

Вообщем это расточительно даже по нынешним меркам (каждое такое приложение — 1-2Гб памяти), а на 1998й год выглядело бы полным безумием.

Тогда и  появилась концепция «сервера приложений» — своего рода авианосца для однотипных коропративных приложений.

Собираешь себе эти 100-200 EAR файлов, размером по 500кб каждый (все библиотеки ведь обычно общие — на уровне самого сервера приложений), устанавливаешь на этот самый сервер приложений и все.

Все вообщем-то работало, пока из-за частых обновлений приложений сервер не зависал — технически все запускалось на одной и той же виртуальной машине, а сборщик мусора успевал не всегда.

Ну и конечно скорость холодного старта для всех серверов приложений тех лет оставляла желать лучшего — пару минут на запуск для какой-нибудь IBM Websphere считалось нормой.

Унылые корпоративные будни

Был период в ИТ-индустрии (примерно 2005-2014), когда практически вся коммерческая разработка на Java подразумевала использование сервера приложений.

Обычно это был все тот же JBoss, реже — IBM WebSphere, еще реже — Oracle Weblogic.

Конечно Apache Tomcat, Jetty и «штуки» вроде Spring тоже были, но всерьез не воспринимались, по крайней мере в банковской сфере.

В телекоме было попроще — там как раз любили простоту и гоняли Tomcat со Spring.

Чаще всего было так, что в банке была куплен и развернут «большой» сервер приложений вроде IBM Websphere или Oracle Weblogic.

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

Это все тогда гордо называлось «ИТ-ланшафтом».

Внедрение такого «ИТ-ланшафта» сильно напоминало сцену из Х\Ф Буратино, с закапыванием золотого ключика в землю. А Алиса и кот Базилио были вылитыми тогдашними «внедренцами-интеграторами».

Минутка WebSphere

С этим сервером приложений я познакомился в 2007м году, это был проект банк-клиента для юрлиц в одном крупном банке.

И на 2007й год проекту было уже 10 лет. Как вы наверное догадались это тоже был полный п#здец харкдор:

сильно устаревший код, сам клиент на Swing, подгружаемый через технологию Java-апплетов (ныне забытую), серверная сторона на EJB в этой самой вебсфере и взаимодействие через SOAP, поскольку RESTа тогда еще не существовало. В качестве базы конечно же Oracle, без какого-либо ORM, даже практически без прямых выборок - одни сплошные процедуры.

Еще там была криптография, в первую очередь для электронной подписи документов.

Как запихивали отечественный JCP-криптопровайдер в вебсферу, где даже сама JVM была от IBM и отличалась от оригинальной (тогда еще сановской) — отдельная история, как-нибудь расскажу.

Техподдержка IBM конечно тогда знатно ох#ела, общаться в итоге пришлось со штаб-квартирой, минуя все региональные офисы и индусов.

У банка был куплен SLA (поддержка) максимального уровня от IBM, а я отлично знал английский, поэтому отрывался на бедных американцах по полной.

Добавлю также, что это был живой и важный проект, с большим количеством пользователей, кучей транзакций и большой же работой по сопровождению. Поддерживаемый при этом очень небольшой командой, так что степень ответственности думаю понятна.

Вот вам пара исторических фото тех лет:

Да, я действительно использовал линукс в банке на рабочей машине еще в 2007 м году. Доступ в домен AD, Lotus Notes, вход на другие машины через rdesktop — это вам не убунту в виртуалке :)

На Tcl + Tk была сделана специальная административная панель для запуска команд, сама сборка — еще на Ant.

Вообщем накопленного опыта хватило для активного участия уже в следующем большом проекте — переводу на IBM Websphere аж целой АБС, пусть и сильно устаревшей.

Но это тема для отдельной истории, печальной и поучительной.

Портлеты, корпоративные порталы и Liferay

Был период в ИТ, когда стало жутко модно делать корпоративные порталы, причем чем жирнее тем лучше.

Первый раз я попал на такой в 2006м году, с тех пор переодически беру заказы на доработку подобных решений, благо их много осталось с тех славных времен.

Видите блоки с управляющими кнопками на картинке выше? — это портлеты, такие мелкие отдельные виджеты, реализующие той или иной функционал.

Поиск и вывод таблиц, голосования, календари, списки, страницы — вот это все и есть портлеты.

Даже целую отдельную спецификацию написали для этих портлетов, не самую маленькую.

На наборах таких портлетов, как предполагалось и будет строиться корпоративный портал.

Формально по спецификации реализовать портал можно было и без полного J2EE сервера приложений (например на сервлет-контейнере вроде Apache Tomcat), но чаще всего его разворачивали как раз на сервере приложений.

Видимо в погоне за двойной жирностью.

Тогдашним королем жирноты был Liferay Portal, который и сейчас все такой же жирный вполне неплохо себя чувствует.

Конечно были и есть подобные решения от всех крупных вендоров, некоторые я даже использовал, но Liferay был все равно упитанее популярнее.

Плюс это опенсорс, хотя кому придет в голову собирать такое чудище из исходников — ума не приложу, практического смысла в этом ноль.

На сегодняшний день, сама концепция внутреннего портала является несколько устаревшей, фактически такие порталы заменили корпоративные чаты. В первую очередь это конечно знаменитый Slack.

Для осмысленного применения подобной штуки нужно наверное от 1000 человек в штате и выделенные ресурсы: верстальщики, контент-менеджеры, администраторы.

Это все помимо Java разработчиков, которые собственно и сделают само решение на базе такого портала.

Как вы понимаете, такие выдающиеся ресурсы есть далеко не у всех. А в редких случаях прямой необходимости — подобные проекты разумнее делать на PHP, Node.js или чем-то подобном но современном.

Что вообщем-то и происходит на практике.

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

Если вдруг появится необходимость починить такого динозавра — пишите, помогу.

ESB, SOA и говно на лопате

Вообще интеграционная шина, да и сама SOA — тема для отдельной большой статьи, благо такой запредельный уровень скотства, да еще продававаемый инфоцыганскими методами просто нельзя пропускать.

Чтобы дети и внуки помнили к чему приводит неуемная жадность и жажда наживы.

Тут расскажу в кратце про саму идею.

Допустим у вас есть несколько информационных систем: CRM, складской учет, 1С у бухов, сервер отчетов и вебсайт с интернет-магазином.

Все это нужно связать воедино, так чтобы остатки на складе были видны в CRM, актуальные товары на складе — на витрине в интернет-магазине, а проводки — в базе у бухов.

И все это естественно в динамике.

Системы эти конечно не ваши, а покупные, готовых адаптеров для такой интеграции — допустим для примера что нет.

Хотя в реальности на 2023 уже наверное есть вообще все возможное и невозможное в плане адаптеров интеграции.

Вот тут и начинается работа интеграционной шины (ESB):

В специальном редакторе (см. скриншот выше — он как раз из реального проекта) описываете связи между системами, способы загрузки и выгрузки данных и логику преобразования.

Дальше нажимается кнопка сборки и готовое интеграционное решение устанавливается на интеграционную шину, которая работает на основе сервера приложений. И на этом (по идее) все начинает работать само, а вам остается только радоваться и считать прибыли.

Конечно суровая реальность сильно отличалась от рекламных проспектов — все работало медленно, глючило, сообщения терялись, а адаптеры отваливались.

Поэтому все подобные решения со временем сошли на нет, на сегодняшний день проект на ESB — уже чистое легаси, от которого все лишь мечтают избавиться поскорее.

От былого блеска не осталось и следов.

Рост производительности и микросервисы

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

Например в какой-то момент оказалось, что абсолютно все мои проекты сдаются и далее эксплуатируются в виртуальной среде а не на реальном железе:

сервер приложений вместе с джавой и базой данных закатывался в образ докера, дальше в этот «виртуальный, но централизованный» сервер приложений деплоились сами JEE-приложения.

И так стало повсеместно.

В этих условиях массовой виртуализации, заморачиваться с централизованным сервером приложений, со сложным процессом развертывания и обслуживания — стало бесмысленно и неинтересно.

Управление и расшаривание общих ресурсов — ключевое что когда-то предлагал сервер приложений, теперь обеспечивает сам слой виртуализации/контейнеризации:

Docker, Ansible, Kubenetes — имя им уже легион.

Так начался исход в микросервисы.

Вымирание

Интерес к концепции серверов приложений сильно упал в угоду микросервисам и контейнерам.

На фоне этого, Oracle передал бразды управления стандартом JEE в руки Apache Foundation, теперь это называется Jakarta EE.

Сие есть знаковое и показательное событие для отрасли в целом и самого стандарта в частности. Ведь еще совсем недавно топовые компании бились за право добавить нужные правки в спецификации Java EE.

Вообщем будущее и стандарта и реализаций туманно:

Одно из последних нововведений в спецификацию — «Web Profile» направлено на урезание функционала сервера приложений в угоду компактности и скорости холодного старта.

Не очень похоже на бурный рост, правда?

На сегодняшний день все проекты разворачиваемые на серверах приложений являются фактически «легаси» и если вообще развиваются то скорее по инерции, чем со смыслом.

Быстрая и яркая история серверов приложений закончилась.