Улучшение дизайна сервиса в модели IaaS

Блог компании ИТ-ГРАД
Улучшение дизайна сервиса в модели IaaS
*Текст подготовлен с использованием материала All Things Open

Чтобы доставка сервиса до клиента выполнялась быстрее, необходимо наладить работу смежных команд друг с другом, включая команду разработчиков. Сотрудник Red Hat Джеймс Лабоки несколько месяцев наблюдал за организациями из различных сфер деятельности, включая телекоммуникационную, финансовую и транспортную отрасль. Наблюдения позволили наглядно оценить механизмы взаимодействия команд друг с другом и понять, какую модель применить для улучшения дизайна сервиса. О подходах, используемых командами, моделях развертывания и предоставления сервиса, выводах и полезных заключениях расскажем в этой статье.

Использование повторяющихся развертываний

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

Использование повторяющихся билдов

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

Repeatable Builds, или повторяющиеся билды, — подход, при котором участник команды разработчиков делает запрос на предоставление сервиса. Сервис автоматически разворачивается, и заявителю предоставляется все необходимое, включая возможность модификации сервиса. Заявитель может изменять состав службы (чаще всего вносить изменения в код приложения), автоматически распространяя изменения на остальные экземпляры сервиса.

Разбираемся в деталях

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

# Модель повторяющихся развертываний

Что такое модель повторяющихся развертываний, или Repeatable Deployment? Если вы ИТ-специалист, то наверняка сталкивались с данным понятием. Это модель, в которой команда системных администраторов разворачивает и конфигурирует компоненты инфраструктуры. Сюда входит выделение ресурсов для виртуального окружения, включая виртуальные коммутаторы, хранилища, виртуальные машины, установку ОС или использование «золотого» образа. Если требуется использовать контейнеры, системные администраторы разворачивают их по требованию, обеспечивая защиту в контексте сценария с низкой степенью автоматизации.

Модель повторяющихся развертываний
Рисунок 1. Модель повторяющихся развертываний

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

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

# Модель кастомизированных повторяющихся билдов

Следующая модель, которую стоит рассмотреть, носит название «кастомизированные повторяющиеся билды», или Custom Repeatable Build. Модель распространена в организациях, которые начали использовать автоматизацию до появления предписывающих методов автоматизации или потому, что существовали предпосылки в виде опыта и гибкости, которыми захотелось воспользоваться.

Модель повторяющихся развертываний Модель кастомизированных повторяющихся билдов
Рисунок 2. Модель кастомизированных повторяющихся билдов

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

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

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

# Модель предписанных повторяющихся билдов

Виртуальная инфраструктура в модели предписанных повторяющихся билдов, или Prescriptive Repeatable Build, включает в себя хранилища, сеть, виртуальные машины или контейнеры, конфигурируемые и предоставляемые командой системного администрирования. После того как инфраструктура настроена, она предоставляется не командам по доставке приложений, как в других моделях, а команде PaaS, которая предоставляет услуги PaaS с использованием ресурсов облачной инфраструктуры.

Модель предписанных повторяющихся билдов
Рисунок 3. Модель предписанных повторяющихся билдов

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

Сложности и ограничения

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

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

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

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

Какая модель лучше

Решение, какую модель лучше использовать, зависит от многих факторов, среди которых:

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

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

Отделение существующих элементов внутри организационной платформы
Рисунок 4. Отделение существующих элементов внутри организационной платформы

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

Пример связанности элементов инфраструктуры между собой
Рисунок 5. Пример связанности элементов инфраструктуры между собой

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

Визуализация сервисной композиции для потребителя услуг
Рисунок 6. Визуализация сервисной композиции для потребителя услуг

В завершение отметим, что скорость и способ доставки сервиса до конечного пользователя в модели IaaS зависит от многих факторов, включая необходимость слаженной работы смежных команд друг с другом и выбора соответствующей модели развертывания. А улучшение дизайна сервиса способствует появлению востребованных предложений, примером которых выступает услуга services as a code, актуальная среди разработчиков.

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn