Поліпшення дизайну сервісу в моделі IaaS



/ фото 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 відбувається за допомогою користувальницького інтерфейсу, представленого у вигляді порталу самообслуговування. Розробники отримують зручний інтерфейс для роботи з сервісом і доступ до исходниками програми.

Цей тип моделі характеризується максимальним рівнем стандартизації, що дозволяє розробникам швидко перемикатися між вихідним кодом і робочим додатком, усуваючи всілякі складності.

Висновок
На закінчення відзначимо, що вибір патерну для вашої організації залежить від безлічі факторів, серед яких виділяються:
  1. Рівень власних навичок;
  2. Однорідність процесів розробки програми;
  3. Бізнес-вимоги, пов'язані з життєвим циклом програми (зокрема, час);
  4. Архітектура програми;
  5. Гнучкість управлінських процесів.
Також варто сказати, що швидкість і спосіб доставки сервісу до кінцевого користувача в моделі IaaS залежить від безлічі змінних. Однак одними з визначальних чинників залишаються вибір патерну розгортання і злагоджена робота суміжних команд один з одним.

P. S. Інші матеріали з нашого блогу на Хабре:

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.