Лекція 2. Хмарні рішення: можливості, переваги, ризики (2016 р.)

Лекція 2. Хмарні рішення: можливості, переваги, ризики

Особливості проектування хмарних рішень

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

Таким чином, при проектуванні "хмарних" рішень необхідно враховувати наступне (на прикладі платформи Windows Azure):

• Будь-який додаток, що є частиною "хмари" - віддалений сервіс. На етапі планування рішення необхідно враховувати тимчасові затримки, між відправленням запиту й одержанням результату, а також необхідність контролю статусу з'єднання і його відновлення.

• Динамічна інфраструктура хмари забезпечує горизонтальну масштабованість, таким чином, кількість одноразово працюючих екземплярів програми може змінюватися. У зв'язку з цим стан додатки необхідно зберігати в довготривалому сховище (не так на локальних дисках).

• Ряд сценаріїв, вартість яких велика, в разі їх реалізації на основі локальної інфраструктури (наприклад обробка великих обсягів даних), можуть бути реалізовані в "хмарному" вирішення у вигляді платформних сервісів.

• Управління виділенням обчислювальних ресурсів для додатка, їх супровід здійснюється платформою.

• Вартість хмарного рішення. Дане поняття стало актуальним при появі "хмарних рішень". Розглянемо його більш детально.

Вартість "хмарного" рішення

При використанні "хмари" замовником оплачується оренда обчислювальних ресурсів, що і є основною статтею витрат, при використанні такого рішення.

В першу чергу, на вартість рішення буде впливати трафік - обсяг переданих, або отриманих даних. Для зменшення вартість даної складової доцільно використовувати стиснення даних, перехід до SOA - архітектурі і розміщення коду, активно працює з даними поруч з їх сховищем (тобто обчислення не виходитимуть за рамки "хмари" і впливати на обсяг переданої інформації).

Вартість другої компоненти - обчислювальних ресурсів - починає вимірюватися з моменту початку розгортання програми і залежить від потужності наданих віртуальних машин.

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

Мультітенантна архітектура

Ми розглянули, з чого складається вартість "хмарного" рішення. Так яким же чином варто вибудовувати архітектуру програми, щоб мінімізувати витрати не знижуючи якості послуг, що надаються?

Таким способом зниження вартості обчислювальних ресурсів і сховища даних є так звана мультітенантна архітектура програми.

Відзначимо, що дана архітектура застосовується, як правило, для додатків, які обслуговують групи ізольованих один від одного користувачів.

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

Таким чином, для кожної групи користувачів, в разі розміщення додатки в хмарі, виділяється тільки необхідне, не фіксована кількість ресурсів, тобто "Вартість" нараховується по - фактом використання "хмарних" ресурсів.

Розглянемо етапи переходу до мультітенантної архітектурі:

1. Виділена архітектура. Кожна група користувачів використовує свою копію програми (сервісу). Кожна копія орієнтована тільки на свою групу користувачів, таким чином, кожна копія містить персональне розширення, в якому зберігаються призначені для користувача настройки. Вся неефективність даної моделі стане наочна при збільшенні числа користувачів. Також стає неможливим підвищення ефективності за рахунок зростання масштабів, оскільки фактично користувачі користуються різними екземплярами програми.

2. Налаштована архітектура. В даному випадку додаток, або сервіс налаштовується для кожного конкретного користувача через конфігурацію. Тобто кожен користувач працює зі своєю копією додатка, не дивлячись на те, що копії ідентичні. Обчислювальні потужності не розділяються між різними екземплярами додатки, що також не дозволяє домогтися підвищення ефективності за рахунок збільшення масштабів .. Розділення ж самого додатка може бути як віртуальним, так і фізичним.

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

4. Масштабована архітектура. Дана модель підтримує мультітенатний підхід, а також можливість горизонтального масштабування. При цьому нові екземпляри додатків додаються до загального пулу. Загальне навантаження розподіляється по всій інфраструктурі. Архітектура налаштовується через конфігурацію.

Моделі організації мультітенантного сховища даних

1. Окремі бази даних. Кожна група користувачів має власну базу даних, з власної схемою даних. Може бути ефективною при невеликому числі користувачів в розрахунку на базу даних. Крім того, даний варіант кращий, в разі пред'являються користувачами строгих вимог до ізоляції і безпеки даних.

2. Спільно використовувані бази даних з різними схемами. Всі користувачі працюють з однією БД, але мають різні набори зумовлених полів. Найбільш корисний даний варіант у разі, якщо зберігання даних різних користувачів в одній таблиці допустимо, а також заздалегідь відомо які поля будуть потрібні. Може привести до ситуації розрядженого наповнення таблиць.

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

Перш, ніж перейти до розгляду переваг і ризиків для бізнесу, коротко розглянемо підхід SOA (Service-oriented architecture).

SOA, або сервісно - орієнтована архітектура - підхід, суть якого полягає в розробці програмного забезпечення, заснованої на використанні сервісів зі стандартизованими інтерфейсами. Іншими словами, додаток "збирається" по частинах з декількох модулів - комплектуючих, а не пишеться "від і до".

Головними цілями, для досягнення яких прагне SOA, є:

1. підвищення масштабованості створюваних систем;

2. спрощення процесів контролю і управління створеними системами;

3. скорочення витрат, пов'язаних з розробкою додатків;

4. збільшення частки повторного використання коду;

5. незалежність систем від платформ, інструментів розробки і мов програмування.

В основі даного підходу лежать:

• багаторазове використання функціональних елементів;

• усунення дублювання функціоналу;

• стандартизація та уніфікація типових процесів;

• перехід компаній на функціональну організацію.

Одним з основних переваг SOA є надійність, особливо при реалізації, заснованої на застосуванні веб - технологій.

При плануванні SOA - архітектури важливо пам'ятати про необхідність наявності централізованого сховища - довідника всіх доступних сервісів. Даний довідник повинен забезпечувати угруповання сервісів по бізнес - функцій, підрозділам, джерел даних і т.п. Класифікація сервісів повинна бути побудована таким чином, щоб забезпечити швидкий пошук розробниками необхідних їм сервісів для створення нових додатків. Компоненти, з яких збирається додаток є "чорні ящики".

Принципи SOA:

• архітектура не повинна бути прив'язана до будь - якої технології;

• система не повинна залежати від використовуваної платформи;

• система не повинна залежати від вживаних мов програмування;

• використовувані сервіси повинні бути незалежні від конкретних додатків і володіти стандартизованими інтерфейсами доступу до них;

• сервіси повинні бути "слабо зв'язаної" між собою.

SOA - не є продуктом, або специфікацією. Якщо ви хочете реалізувати даний підхід, то буде потрібно ретельне і детальне планування вибудовується архітектури.

Переваги SOA, SaaS і хмарних рішень

Розглянемо більш детально, які саме переваги здатний витягти бізнес з застосування SOA, SaaS і хмарних рішень:

• Підвищення ефективності надання послуг. Досягається більш глибоке розуміння, що ж саме необхідно для бізнесу, за рахунок розробки вимірних компонентів (SOA). Компаніям, які реалізують "хмарний" підхід з використанням SOA і SaaS немає потрібні витрачати фінансові, людські та ІТ - ресурси на підтримку власної інфраструктури.

• Гнучкість. Сформовані служби мають високу сумісністю. Нові рішення утворюються за рахунок об'єднання служб раніше створених рішень, що підвищує швидкість реакції ІТ - служб на постійно виникаючі зміни в потребах цільової аудиторії.

• Масштабування. Можливість швидко отримати необхідну кількість ресурсів забезпечує гнучке масштабування без внесення суттєвих організаційних змін.

• Доступність. Для доступу до "хмарної" платформі необхідно лише Інтернет - з'єднання.

• Продуктивність. Територіально розподілені центри даних, ресурси і платформи досягають величин продуктивності недоступних для інфраструктури окремої компанії.

• Контроль. Можливість поєднання різних варіантів розміщення додатків: на власних серверах, на серверах "хмари" або їх поєднання, дозволяє отримати необхідний ступінь контролю за додатком і об'єднувати наявні ресурси (локальні і "хмарні") для рішень поточних завдань.

Зрозуміло, крім переваг у "хмарних" підходів є і ряд ризиків.

Ризики SOA і SaaS

• Істотна прибуток і економія можлива в разі, якщо продуктивність раніше використовуєте була низька. В іншому випадку, перехід на SaaS - рішення може виявитися навіть збитковим. Таким чином, не варто спрямовувати зусилля на зміну рішення, від якого залежить прибуток.

• Складнощі проектування. Завжди є ризик, що спроектовані і реалізовані рішення не буде приносити заявлених переваг. Це може статися з різних причин: від помилок проектування, до невідповідності рішення пропонованим до нього вимогам (наприклад, конфіденційність даних).

• Ризики, пов'язані з реалізацією рішення. Для побудови SOA - архітектури і роботи з "хмарними" рішеннями колектив повинен володіти відповідними компетенціями та досвідом, не тільки в розробці, але і в проектуванні рішень. Вплив даного ризику можна мінімізувати, шляхом проходження навчання та укладення партнерських угод з фірмою - постачальником.

• Ризики використання. Перехід на нову модель управління і роботи вимагає початкових інвестицій, для реорганізації технологічних процесів і методів роботи.

Таким чином, перш ніж почати перехід на новий стиль роботи, або прийняти рішення про необхідність такого, необхідно:

1. провести аналіз бізнес - функцій, можливо спочатку необхідно перевести на нову основу порівняно невелику і автономну частину бізнесу, порівняння ефективності "до" і "після";

2. сформувати план технологічного розвитку - застосування "хмарних" рішень повинно відповідати потребам компанії і її клієнтів, спочатку має сенс тільки доповнювати вже існуючі рішення там, де це має сенс;

3. підтримувати план технологічного розвитку - ризики і проблеми будуть виникати завжди, тільки в міру впровадження стане зрозуміло, де і яким чином SOA, SaaS і "хмари" можуть бути найбільш корисні, необхідно завжди чітке розуміння того, що відбувається з бізнесом, які є проблемні місця і як їх можна усунути, або ступінь їх впливу.

Список додаткових матеріалів для самостійного вивчення

SOA

SaaS

"Хмарні" рішення і бізнес

(Для ознайомлення з повним текстом статті необхідно залогінитись)