/ фото Juhan Sonin CC
Постоянно меняющиеся требования, предъявляемые к облачной инфраструктуре, ведут к необходимости проработки новых бизнес-моделей и создания архитектурных решений. Это позволяет постоянно повышать уровень защищенности и управляемости данных.
В нашем блоге на Хабре мы уже писали о решениях и сервисах для управления данными и организации резервного копирования в облако IaaS-провайдера.
Сегодня нам бы хотелось затронуть тему доставки и дизайна сервисов в модели IaaS. Мы поговорим о моделях развертывания, обуславливающих совместную работу всех участников процесса разработки и доставки приложений.
Дизайн сервисов
Технологии и бизнес-процессы с каждым годом только усложняются, объемы обрабатываемых данных растут. Чтобы максимально эффективно использовать ресурсы компании и повысить степень удовлетворенности пользователей, рекомендуется пользоваться библиотекой ITIL. ITIL предлагает лучшие практики по предоставлению высокого качества ИТ-услуг (сервисов).
Подход акцентирует внимание организации на достижении поставленных целей, а также на ресурсах, затраченных на их достижение. При построении стратегии поставщик услуг должен ориентироваться, прежде всего, на цели своего потенциального заказчика. Для этого необходимо четко понимать, какую роль сыграет предоставляемая ИТ-услуга в бизнесе клиента. Здесь на помощь и приходят методологии ITIL, помогающие построить стратегию, являющуюся основополагающим этапом дизайна сервиса.
ITIL приобретает широкую популярность среди компаний самых разных областей. С ITIL работают такие компании, как Hewlett-Packard, Boeing, IBM, Sony, Honda и многие другие. Компания Forrester провела исследование, опросив 491 участника форума itSMF(IT Service Management Forum). Согласно полученным данным, методики, предлагаемые ITIL, повысили продуктивность сервисов у 85% респондентов, а 65% опрошенных отметили положительное влияние на репутацию бизнеса. Стоит сказать, что в ряды адептов ITIL влилась и компания Cisco. Как говорят её специалисты, дизайн сервисов является критически важным компонентом облачной инфраструктуры.
Именно проникновение облачных технологий во все сферы деятельности оказало значительное влияние на подходы к дизайну сервисов. Дизайн сервисов – это серьезный этап, который включает в себя восемь пунктов: координация дизайна, управление каталогом сервисов, управление уровнем сервисов, управление мощностями, управление доступностью, управление непрерывностью сервиса, управление информационной безопасностью, управление поставщиками. Каждый из этих аспектов подвергся определенным изменениям.
Задача добавления услуги в каталог стала требовать грамотного описания облачного сервиса, чтобы у клиента не возникало вопросов касательно его реализации. То же касается и управления уровнем сервисов: в соглашении об уровне услуг (SLA) теперь должны быть прописаны такие моменты, как время на устранение неполадок облачной инфраструктуры, выплачиваемые компенсации, предоставляемые гарантии и др.
Следующим пунктом идет управление доступностью. При миграции в облако для провайдера становится важной задача предоставления высокого уровня доступности, как если бы пользователь развернул свои приложения «на месте». Например, в случае IaaS необходимо гарантировать наличие памяти или процессоров, готовых к подключению, а также предоставить инструменты по мониторингу ресурсов.
Что касается управления сервисами, то менеджер теперь должен учитывать возможность «падения» не только сайта компании, но и сайта облачного провайдера. Более того, организациям придется изучать предлагаемые сервис-провайдерами решения, исследовать рынок и искать компромиссы. При всем при этом нельзя забывать про оценку условий безопасности, конфиденциальности и целостности данных.
Последним элементом дизайна сервисов является процесс управления поставщиками. Он также подвергся изменениям: появилась необходимость в оценке внешних сервисов и проведении мониторинга качества предоставляемых услуг. Что немаловажно, дополнительной задачей стало установление доверительных отношений с поставщиком.
Модели развертывания
В нынешнем «облачном» мире изменились и процессы, определяющие способы доставки инфраструктуры конечным пользователям ИТ-командами. Сотрудник Red Hat Джеймс Лабоки (James Labocki) несколько месяцев наблюдал за организациями из различных сфер деятельности, включая телекоммуникационную, финансовую и транспортную отрасли. За это время он оценил механизмы взаимодействия команд друг с другом и сумел выделить три основные модели для улучшения дизайна сервиса.
Модель повторяющихся развертываний (Repeatable Deployment)
В этой модели за разработку и настройку элементов инфраструктуры отвечает команда системных администраторов, в обязанности которых входит выделение ресурсов для виртуального окружения (виртуальные коммутаторы, хранилища, виртуальные машины, установка ОС), развертка контейнеров и обеспечение их защиты.
После того как инфраструктура настроена, в работу вступает команда, ответственная за доставку приложений. В обязанности специалистов по доставке входит развертка сервисов, необходимых для запуска и корректного функционирования приложений, конфигурация кластера сервера приложений и настройка пула соединений к базе данных. Заключительным этапом их работы становится развертка приложения из бинарного файла в репозитории.
В такой модели чаще автоматизируется развертывание инфраструктуры и лишь иногда – развертывание и настройка сервера приложений. Развертывание приложения из бинарного файла автоматизируется нечасто.
Эту модель проще всего реализовать, однако отсутствие связности процессов разработки с развертыванием, настройкой и работой самого приложения приводит к невозможности решения задач, требующих организации быстрой доставки. Кроме того, такая модель не является «пуленепробиваемой», поскольку подвержена сильному влиянию человеческого фактора на этапе развертывания приложений.
Модель кастомизированных повторяющихся билдов (Custom Repeatable Build)
В этой модели команда системных администраторов по-прежнему отвечает за развертывание и настройку инфраструктуры: хранилища, сеть, виртуальные машины и контейнеры. Однако это вид задач часто автоматизируется с применением специализированных инструментов. После этого готовая инфраструктура передается в формате неделимой единицы команде, занимающейся доставкой приложений.
Специалисты по доставке отвечают за конфигурацию сервера приложений и отправку на него исполняемых файлов – все это также делается с использованием платформ автоматизации и управления конфигурациями.
Модель кастомизированных повторяющихся билдов экономит время, затрачиваемое на процессы разработки, но требует особых знаний для связки исходника, подготовки рабочего образа и автоматизации развертывания. Кроме того, модель имеет существенный минус: на ввод в эксплуатацию одного приложения уходит несколько месяцев, поэтому такая модель может оказаться неприемлемой для крупных компаний, в чьем ведении находятся тысячи приложений.
Модель предписанных повторяющихся билдов (Prescriptive Repeatable Build)
Виртуальная инфраструктура в модели предписанных повторяющихся билдов включает в себя хранилища, сеть, виртуальные машины или контейнеры, настраиваемые командой системного администрирования. Однако в этом случае настроенная инфраструктура передается не команде по доставке приложений, а команде PaaS, предоставляющей PaaS-услуги с использованием ресурсов облачной инфраструктуры.
Доступ к среде разработки в модели PaaS происходит с помощью пользовательского интерфейса, представленного в виде портала самообслуживания. Разработчики получают удобный интерфейс для работы с сервисом и доступ к исходникам приложения.
Этот тип модели характеризуется максимальным уровнем стандартизации, что позволяет разработчикам быстро переключаться между исходным кодом и рабочим приложением, устраняя всевозможные сложности.
Заключение
В заключение отметим, что выбор паттерна для вашей организации зависит от множества факторов, среди которых выделяются:
- Уровень собственных навыков;
- Однородность процессов разработки приложения;
- Бизнес-требования, связанные с жизненным циклом приложения (в частности, время);
- Архитектура приложения;
- Гибкость управленческих процессов.
Также стоит сказать, что скорость и способ доставки сервиса до конечного пользователя в модели IaaS зависит от множества переменных. Однако одними из определяющих факторов остаются выбор паттерна развертывания и слаженная работа смежных команд друг с другом.
P.S. Другие материалы из нашего блога на Хабре:
