Архитектура частного облака

PartlyCloudy1На протяжении нескольких лет тема облачных вычислений (cloud computing) была целиком и полностью спекулятивной. Вероятно, причиной тому являлся приоритет бизнес-модели над технологиям. Технологические лидеры, безусловно, рассказывали широкой общественности о том,  что же такое облако; поясняли, что облака бывают публичные, частные и гибридные, но за всеми этими разговорами отчетливо виднелись длинные уши маркетинга и продаж. И желание у персонажей, которых я назвал «технологическими лидерами» было только одно – вместо лицензий и проектов продавать услуги. Причем не так как раньше, не услуги по разработке программного обеспечения, а услуги, оплачиваемые постоянно, в ходе всего жизненного цикла. На сегодняшний день ситуация поменялась. Покупка услуг по подписке стала привычным делом. Мы стали покупать не только услуги ЖКХ или пакеты услуг связи, но и музыку по 169 рублей в месяц в Apple Music. Вероятно, скоро можно будет подписаться  на месячный пакет еды в близлежащем супермаркете. В общем, тема бизнес-модели стала неактуальной. Пришло время поразбираться в технологиях.

А с технологиями случилось следующее. Буквально в прошлом году из набора разрозненных и противоречивых лозунгов обо всем как сервис (XaaS), мобилизации, виртуализации, консьюмеризации, больших данных и третьей платформе ИТ начала выстраиваться стройная картина будущего.

Давайте начнем с сервисов. Как известно, XaaS включает в себя понятия IaaS, PaaS и SaaS – инфраструктура как сервис, платформа как сервис и приложение как сервис соответственно. Есть еще iPaaS, BPaaS и DBaaS, но о них как-нибудь в следующий раз. И вообще, про DBaaS пусть лучше рассказывает Oracle, они на днях перевели все сопроводительные материалы на русский язык, а про iPaaS поставщики интеграционных решений. Инфраструктура как сервис позволяет экономить деньги на hardware, ПО как сервис – время на развертывании приложений. Проницательные эксперты, конечно, понимают, что все это не совсем правда. Возможность быстрого выделения корпоративным пользователям виртуальных машин вряд ли сократит общий объем потребления вычислительных ресурсов. Скорее наоборот. Раньше люди ждали несколько месяцев пока им закупят, привезут и смонтируют сервера теперь же они получают их сразу и, естественно, начинают хотеть еще. Аналогичная ситуация с программным обеспечением, но оставим это за скобками. Что такое PaaS мало кто понимал, пока не поменялись модные тренды в архитектуре прикладных систем. Вроде бы незначительное изменение. Раньше рассуждали о сервисах, а теперь стали разговаривать о микросервисах. На самом деле разница между ними существенная.

Сервисы, не те о которых мы рассуждали в предыдущем абзаце, а сервисы в смысле сервис-ориентированной архитектуры, т.е. фрагменты программного обеспечения, доступные через некоторый API, предполагали наличие общей программной платформы. Они не могли существовать без такой платформы, они на ней развертывались. Java Application Server, Enterprise Service Bus, .NET + IIS – примеры таких платформ. Лет десять назад корпоративные архитекторы начали вагонами закупать эти решения и пытаться заставить разработчиков делать программное обеспечение только на этих платформах. Корпоративные разработчики, как известно, сами неплохо разбираются в архитектуре и потому продолжали создавать ПО не на «правильных», а на своих любимых платформах. Модные платформы обычно стоят в сторонке. Надо внедрить модный инструмент? Внедрили, галочку поставили и продолжаем программировать рядом на том, что удобней. Микросервисам не нужна платформа. Вернее платформа, т.е. все необходимое общесистемное ПО находится внутри микросервиса. Эта идея выросла из архитектуры интеграционных сред. Вспомните картинку Java Business Integration

jbi-architecture

Квадратики с надписью “Service Engine” в верхней части рисунка – это контейнеры, такие как JavaEE, BPEL SE и др.  Бывают даже такие экзотические контейнеры, как приложения для работы со списками задач (см. заметку Gassfish ESB v2.2). В каждом контейнере могут быть развернуты десятки соответствующих программных компонент, взаимодействующих с внешней средой через шину сообщений (Кстати, взаимодействие через NMR описывается при помощи WSDL, хотя физически никаких web-сервисов эта шина не поставляет).  В общем, для полной победы этой архитектуре не хватило .NET Service Engine и DBMS Oracle Service Engine. Но на помощь пришла виртуализация. А затем оформилась и идея multitenancy, позволяющая сделать среду для исполнения сервисов еще более эффективной. Приложение «думает», что работает с индивидуальной копией общесистемного ПО, но на самом деле эта копия общая. Как это все устроено см. в предыдущей статьей про контейнеры

Осталось научиться всем этим управлять. В принципе, еще в интеграционных средах появились инструменты связывания  сервисов с конкретными портами.

casa

Оставалось перенести все это из среды разработки в среду исполнения и поручить системным администраторам. В связи с этим очень своевременной  оказалась идея DevOps. Кстати и корпоративная архитектура рано или поздно должна переехать среду исполнения. Как здесь не вспомнить диссертацию Роя Филдинга Architectural Styles and the Design of Network-based Software Architectures еще в 2000 году заметившего, что архитектура – это абстракция времени исполнения  (run-time abstraction). Но вернемся к программным платформам. PaaS это не то, на чем исполняются [микро]сервисы. Скорее это то, что находится между ними. Normalized message router из верхней картинки, растянутый в масштабах организации. И пусть модное ныне утверждение «PaaS is the new app server» вас не смущает.

Архитектура частного облака: 2 комментария

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *