Зростання обчислювальних потужностей та розвиток технологій віртуалізації платформи x86 з одного боку, та розповсюдження ІТ-аутсорсингу з іншого боку призвели до концепції utility computing (ІТ як комунальна послуга). Чому б не платити за ІТ так само, як за воду чи електрику – рівно стільки і рівно тоді, коли це потрібно, і не більше.
У цей час і виникла концепція хмарних обчислень – споживання ІТ послуг із «хмари», тобто. з якогось зовнішнього пулу ресурсів, не переймаючись тим, як і звідки беруться ці ресурси. Так само, як ми не дбаємо про інфраструктуру насосних станцій водоканалу. До цього моменту було опрацьовано й іншу сторону концепції – а саме поняття ІТ-послуг та як ними управляти в рамках ITIL/ITSM.
Було розроблено низку визначень хмар (хмарних обчислень), але при цьому не слід ставитися до них як до істини в останній інстанції – це лише спосіб формалізувати способи надання utility computing.
- «Хмарні обчислення – це технологія розподіленої обробки даних, в якій комп'ютерні ресурси та потужності надаються користувачеві як Інтернет-сервіс» Вікіпедія
- «Хмарні обчислення являють собою модель для забезпечення зручного мережного доступу до загального пулу обчислювальних ресурсів, що настроюються (наприклад, мереж, серверів, систем зберігання даних, додатків і послуг) на вимогу, які можна швидко виділити і надати з мінімальними управлінськими зусиллями або мінімальним втручанням з боку постачальника послуг» NIST
- «Хмарні обчислення – це парадигма забезпечення мережевого доступу до масштабованого і гнучкого пулу фізичних або віртуальних ресурсів, що розподіляються, що надаються в режимі самообслуговування та адмініструються на вимогу» ISO/IEC 17788:2014. Information technology – Cloud computing – Overview and vocabulary.
Відповідно до NIST існує три основних типи хмар:
- IaaS – Infrastructure as a Service — Інфраструктура як сервіс
- PaaS – Platform as a Service – Платформа як сервіс
- SaaS — Software as a Service Програмне забезпечення як сервіс
Для дуже спрощеного розуміння різниці давайте розглянемо модель Pizza-as-a-Service:
NIST визначає такі необхідні риси ІТ послуги, що дозволяють вважатися хмарною.
- Універсальний мережевий доступ (broad network access) – послуга повинна мати універсальний мережевий інтерфейс, що дає можливість підключення та використання послуги практично будь-кому з мінімальними вимогами. Приклад – щоб використовувати електричну мережу 220В достатньо підключитися до будь-якої розетки зі стандартним універсальним інтерфейсом (вилка), який не змінюється від того, чи це чайник буде, пилосос чи ноутбук.
- Вимірюваність сервісу (measured service) – ключовою характеристикою хмарної послуги є вимірність сервісу. Повертаючись до аналогії з електрикою – ви сплатите рівно стільки, скільки споживали з мінімальною гранулярністю, аж до витрат на один раз закип'ятити чайник, якщо за весь місяць ви були в будинку один раз і випили чашку чаю.
- Самостійне конфігурування сервісів на вимогу (on demand self service) – хмарний провайдер надає замовнику можливість розумного конфігурування сервісу без необхідності взаємодії зі співробітниками провайдера. Для того, щоб закип'ятити чайник, зовсім необов'язково заздалегідь зв'язуватися з Енергозбутом і заздалегідь їх попереджувати та отримувати дозвіл. З моменту як будинок підключено (укладено договір) всі споживачі можуть самостійно розпоряджатися наданою потужністю.
- Миттєва еластичність (rapid elasticity) – хмарний провайдер надає ресурси з можливістю миттєвого нарощування/зниження потужності (у певних розумних межах). Як тільки чайник увімкнений - провайдер негайно видає в мережу 3 кВт потужності, і як тільки вимкнений - знижує видачу до нуля.
- Об'єднання ресурсів у пул (resource pooling) – внутрішні механізми провайдера послуг дозволяють об'єднувати окремі потужності, що генерують, у загальний пул (басейн) ресурсів з подальшим наданням ресурсів як послуги різним споживачам. Включаючи чайник, нас найменше хвилює з якої саме електростанції надходить потужність. І решта споживачів споживають цю потужність разом з нами.
Важливо розуміти, що описані вище характеристики хмари взяті не зі стелі, а є логічним висновком концепції utility computing. І публічна послуга повинна мати ці характеристики в рамках концепції. При невідповідності тій чи іншій характеристиці послуга не стає гіршою і не стає «отруйною», вона лише перестає бути хмарною. Ну а хто сказав, що всі послуги мають?
Чому я про це окремо говорю? За минулі 10 років з моменту визначення NIST було багато суперечок про «справжню хмарність» згідно з визначенням. У США досі іноді застосовується у судовій сфері формулювання «відповідає букві закону, але не духу» — і у випадку з хмарними обчисленнями головне саме дух, ресурси в оренду в два кліки мишею.
Слід зазначити, що перераховані вище 5 показників застосовні до громадському хмарі, але за переході до приватному більшість їх стають опціональними.
- Універсальний мережевий доступ (broad network access) – у межах приватної хмари організація повністю контролює як генеруючі потужності, і клієнтів-споживачів. Таким чином, цю характеристику можна вважати автоматично виконуваною.
- Вимірюваність сервісу (measured service) – це ключова характеристика концепції utility computing, оплата за фактом споживання. Але як же оплачувати організації собі? В даному випадку йде розподіл генерації та споживання всередині компанії, ІТ стає провайдером, а бізнес-підрозділи споживачами послуг. І взаєморозрахунок відбувається між підрозділами. Можливо два режими роботи: chargeback (при реальних взаєморозрахунках та русі фінансів) та showback (у вигляді звітності у споживанні ресурсів у руб, але без руху фінансів).
- Самостійне конфігурування сервісів на вимогу (on demand self service) – усередині організації то, можливо загальна ІТ служба, й у разі характеристика втрачає сенс. Однак, за наявності власних ІТ-фахівців або адміністраторів додатків у бізнес-підрозділах необхідно організовувати портал самообслуговування. Висновок – характеристика опціональна залежить від структури бізнесу.
- Миттєва еластичність (rapid elasticity) – у межах організації втрачає сенс через фіксованості набору устаткування організації приватної хмари. Може обмежено застосовуватись у рамках внутрішніх взаєморозрахунків. Висновок - для приватної хмари не застосовується.
- Об'єднання ресурсів у пул (resource pooling) – на сьогоднішній день вже практично не існує організацій, що не застосовують серверну віртуалізацію. Відповідно можна вважати цю характеристику автоматично виконуваною.
Питання: Так що ж таке все-таки це ваша приватна хмара? Що компанії потрібно купити та впровадити, щоб його побудувати?
Відповідь: приватна хмара – це перехід до нової адміністративної моделі взаємодії ІТ-Бізнес, який на 80% складається з адміністративних заходів і лише на 20 технологій.
Оплата лише за спожиті ресурси та легкий вхід, без необхідності закопати кілька сотень мільйонів нафти у капітальних витратах, зумовили новий технологічний ландшафт та появу компаній-мільярдерів. Наприклад, сучасні гіганти Dropbox і Instagram з'явилися як стартапи на AWS з нульовою власною інфраструктурою.
Необхідно окремо підкреслити, що інструменти управління хмарними послугами стають значно опосередкованішими, а ключовим обов'язком ІТ директора стає підбір постачальників та контроль якості. Давайте розглянемо проблематику цих двох нових обов'язків.
З'явившись як альтернатива класичній важкій інфраструктурі із власними ЦОДами та залізом, хмари оманливо легкі. У хмару легко увійти, але питання виходу зазвичай обходиться стороною. Як і в будь-якій іншій галузі хмарні провайдери прагнуть захисту бізнесу та ускладнення конкуренції. Єдиний серйозний конкурентний момент виникає лише за первинному виборі постачальника хмарних послуг, а далі постачальник докладе максимум зусиль, щоб замовник від нього не пішов. Причому далеко не всі зусилля будуть спрямовані на якість послуг або на їх асортимент. Насамперед, це постачання унікальних послуг та використання нестандартного системного ПЗ, що ускладнює перехід до іншого провайдера. Відповідно, при виборі постачальника послуг необхідно одночасно формувати план переходу від цього постачальника (насправді повноцінний DRP – disaster recovery plan) і продумувати архітектуру зберігання даних і резервних копій.
Другий важливий аспект нових обов'язків ІТ-директора – контроль якості послуг від постачальника. Практично всі хмарні провайдери дотримуються SLA за власними внутрішніми метриками, що може мати вкрай опосередковане значення до бізнес-процесів замовника. І відповідно використання своєї системи моніторингу та контролю стає одним із ключових проектів при перенесенні значних ІТ систем до хмарного провайдера. Продовжуючи тему SLA, необхідно підкреслити, що абсолютна більшість хмарних провайдерів обмежує відповідальність за невиконання SLA в місячний абонентський платіж або частку від платежу. Наприклад, AWS та Azure при перевищенні порога в доступності 95% (36 годин на місяць) зроблять 100% знижки до абонентської плати, а Яндекс.Хмара – 30%.
Ну і звичайно ж, не треба забувати, що хмари бувають не лише у виконанні мастодонтів класу Amazon та слонів класу Яндекса. Хмари бувають і менші — розміром із кішку, або навіть мишу. Як показав приклад CloudMouse, іноді хмара просто бере та закінчується. Ви не отримаєте ні компенсації, ні знижки – ви не отримаєте нічого, окрім тотальної втрати даних.
Зважаючи на зазначені вище проблеми з реалізацією ІТ систем високого класу бізнес критичності в хмарних інфраструктурах останніми роками спостерігається явище «хмарної репатріації».
До 2020 для хмарних обчислень пройдено пік роздутих очікувань і концепція знаходиться на шляху до канави розчарувань (згідно з хайпом циклу Гартнер). Згідно з дослідженнями и до 80% корпоративних замовників повертають та планують повертати навантаження з хмар у власні ЦОДи з причин:
- Підвищити доступність/продуктивність;
- Скоротити витрати;
- Для відповідності вимогам ІБ.
Що ж робити і як усі «насправді»?
Немає жодних сумнівів, що хмари прийшли всерйоз і надовго. І з кожним роком їхня роль зростатиме. Однак ми живемо не в далекому майбутньому, а 2020 року в цілком певній ситуації. Що робити з хмарами, якщо ви не стартап, а класичний корпоративний замовник?
- Хмари – це перш за все місце для сервісів з непередбачуваним або яскраво вираженим сезонним навантаженням.
- Найчастіше послуги з передбачуваним стабільним навантаженням дешевше утримувати у своєму ЦОД.
- Починати роботу з хмарами необхідно з тестових середовищ та низькопріоритетних сервісів.
- Розгляд розміщення інформаційних систем у хмарі починається з розробки методики виходу з хмари в іншу хмару (або у власний ЦОД).
- Розміщення інформаційної системи у хмарі починається з розробки схеми резервного копіювання в контрольовану вами інфраструктуру.
Джерело: habr.com