Private PaaS: кто жмет на кнопку?

Роман Корешков, наш руководитель проектов, рассказал порталу @ASTERA об особенностях технологий Private Platform as a Servise. Какие преимущества бизнесу предоставляет использование PPaaS? Что важнее: использование нового инструментария или грамотное разделение ответственности между ИТ-подразделениями? Как внедрение этих технологий влияет на организацию ИТ-процессов? Ответы на эти и другие вопросы — в материале «Private PaaS: кто жмет на кнопку?» на сайте издания.

Все большее число корпораций начинает применять технологии Private Platform as a Service (платформа как услуга на собственных инфраструктурных мощностях). Их преимущества подробно описаны в океане маркетинговых материалов: детальный контроль стоимости, сокращение времени выхода приложений на рынок, больший коэффициент использования инфраструктуры и, соответственно, снижение инфраструктурной стоимости, унификация архитектуры предприятия и повышение продуктивности команд разработки.

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

Так где же правда? По моему мнению, существенная ценность PPaaS заключается не столько в новых технологиях или инструментах, более близких к Agile, сколько в возможности изменить основные принципы системы разделения труда между ИТ-подразделениями корпорации. Обратное также верно: если корпорация не меняет принципы системы разделения труда в ИТ, то внедрение PPaaS не принесет ей ожидаемого эффекта.

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

• департамент инфраструктуры, ответственный за функционирование ИТ-инфраструктуры («железо», сети, программное обеспечение системного уровня, базы данных);
• департамент приложений, ответственный за разработку и (или) покупку программного обеспечения и его функционирование.

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

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

Теперь представим, что компания все-таки внедрила PPaaS, но ИТ-отдел продолжает работать по старым принципам разделения труда — «железо» отдельно, ПО отдельно. Тогда единственный эффект от внедрения будет заключаться в том, что для развертывания базы данных администратор департамента инфраструктуры нажмет на кнопку в консоли PPaaS, а не сделает это полуавтоматически инструментами вендора базы данных, как раньше. Это ли та ценность PPaaS, которую банк надеялся получить?

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

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

Попробую формальнее пояснить, как меняется при этом система разделения труда в ИТ и, соответственно, ИТ-процессы в корпорации. Для этого необходимо ввести понятия, присущие любой PaaS:

• класс ресурса — набор всех существующих или будущих ресурсов одной и той же природы, типа (это могут быть, например, базы данных PostgreSQL, экземпляры сервисов Memcached и др.);
• вариация ресурса — набор диапазонов количественных и качественных характеристик, которые имеет или будет иметь ресурс определенного класса.

Одна вариация ресурса отличается от другой тем, что для создания каждой из них требуются индивидуальные технические решения. Так, для реализации вариаций «Размер базы данных до 1 Гб» и «Размер базы данных до 100 Тб» будут использоваться совершенно разные подходы. Качественные характеристики (например, уровни отказоустойчивости и катастрофоустойчивости) являются основой для соглашения об уровне предоставления услуги (SLA). Существенным является то, что должно быть согласовано ограниченное число вариаций, а развертывание нового ресурса конкретной вариации будет происходить в рамках заранее подготовленного для этого технического решения.

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

• за гарантированную способность немедленно развернуть новый ресурс этого класса в одной из предопределенных вариаций (конечно, с учетом ограничений);
• за функционирование уже развернутых ресурсов класса.

Это изменение ответственности и является ключевым изменением системы разделения труда в ИТ. Что касается преобразований в соответствующих ИТ-процессах, то можно отметить несколько ключевых отличий.

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

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

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

Среди преимуществ внедрения PPaaS часто упоминается, что данная технология повышает унификацию архитектуры предприятия на слое приложений и технологическом слое и в то же время предоставляет гибкость, достаточную для поддержки новых типов приложений. Увидеть причины этого позволяет понимание происходящих в ИТ-процессах изменений.

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

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

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