Мультихмарне управління

«Мультихмарність» часто вживають як стратегічний термін — привід диверсифікуватися від одного постачальника, домовитися про кращу ціну або виконати вимогу щодо резидентності даних. Мультихмарне управління — це вужчий, операційний рівень під цією стратегією: інструменти та процеси, які дозволяють команді інфраструктури реально запускати навантаження в кількох провайдерах, не перетворюючи роботу з кожним із них на окреме завдання. Без цього «мультихмарність» на практиці означає окрему консоль, окремий набір облікових даних і окрему термінологію для кожного провайдера — і жодного єдиного місця, де можна отримати відповідь на базове питання: яка інфраструктура існує прямо зараз і хто останнім її змінював.

Кожен провайдер постачає власну консоль, CLI, модель IAM і власну термінологію для тих самих базових примітивів — віртуальної машини, групи безпеки, DNS-зони, тома сховища. Саме цю фрагментацію реально вирішує мультихмарне управління. Починається все з виявлення (discovery): підключення облікового запису провайдера й миттєвого перегляду інвентарю того, що там уже працює, — ще до будь-якої міграції чи зміни. Далі до типових дій життєвого циклу — розгортання, запуску, зупинки, зміни розміру, знищення — застосовується один узгоджений робочий процес, незалежно від того, у якого провайдера розташований ресурс. Сильніші реалізації керують конфігурацією безпосередньо і синхронно на боці самого провайдера, а не через кешовану копію у власній базі даних, тож зміна, зроблена через інструмент, — це та сама зміна, яку ви побачите, увійшовши до власної консолі цього провайдера.

Мультихмарне управління виходить за межі життєвого циклу обчислювальних ресурсів і охоплює ті частини операційної діяльності, які справді створюють ризик, коли вони неузгоджені між провайдерами. Контроль доступу має працювати однаково всюди — єдиний вхід (SSO), рольові дозволи та підвищення прав для чутливих дій лише після затвердження, а не окрема модель ідентифікації для кожного провайдера. Кожна зміна має бути атрибутованою, тому журнал аудиту, що охоплює всіх підключених провайдерів, тут важливіший, ніж у середовищі з одним хмарним провайдером, — це різниця між питанням, на яке можна відповісти відразу, і повноцінним розслідуванням. А оскільки вартість інфраструктури — одне з перших, що стає непрозорим у мультихмарному середовищі, видимість витрат і виявлення аномалій мають бути в тому самому місці, де й розгортання ресурсів, а не в окремій таблиці, яку звіряють раз на місяць. Багато команд також експлуатують інфраструктуру, яка взагалі не є хмарною, — локальні (on-premise) або bare-metal сервери, — і очікують, що та сама дисципліна моніторингу та патчингу поширюватиметься і на них.