☁️ Бути Cloud Agnostic чи використовувати всі переваги екосистеми вашої хмари?

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

Що оберете ви:
— використовувати кросплатформені інструменти для вашої хмарної інфраструктури зараз, щоб бути якомога менш залежними від vendor lock та в майбутньому було легше розгорнути інфраструктуру в іншій хмарі
— використовувати аналоги, які пропонує ваш cloud provider для нативної взаємодії сервісів та спрощення їх конфігурації, а коли стане питання розгортання в іншій хмарі, то почнете шукати аналоги в тій, новій хмарі

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Якось мені «пощастило» мігрувати намертво прибиту до Азура систему у амазон.
Це було неймовірно складно та зайняло майже два роки.
Тому коли мігрували то замовник висунув жорсткі вимоги щоб прив’язки до хмари були якомога слабкіші та щоб усі вони могли бути швидко замінені на інше хмарне середовище. Найважче це було зробити для зберігання файлів — у Азура та амазона дуже різні підходи тож були проблеми із абстрагуванням та одночасно збереженням високого рівня надійності системи. Вдалося але не сказав би що воно того варте.
Найлегше було замінити брокера повідомлень
Azure queue на Кролика.
Тож треба дуже ретельно планувати такі речі та може навіть зробити тестові застосунки щоб перевірити чи буде відповідати система вимогам бізнесу.

Найпростіше мабуть буде кубер використовувати, бо кубер він всюди кубер.

Якщо говорити про K8s, то в Azure є пачка сервісів, де можна вибирати:
— networking plugin: Azure CNI vs kubenet
— network policy: Azure vs Calico
— container registry: ACR vs Dockerhub
— secrets manager: Azure Key Vault vs Hashicorp Vault
— monitoring toolset: Azure Monitor vs ... тут купа всього може бути..)

але менеджмент не виключає в майбутньому присутність в інших

Якщо менеджмент не виключає — то ось вам і відповідь. Зробите нативну хмару, а потім зненацька виявиться, що треба переїздити — і будете винні (вас же попереджали!). А з agnostic підходом, ну, будете довго пиляти — але ж це та задача, яку вам поставили і гроші платять.
Зафіксуйте тільки десь, що це саме менеджмент поставив обмеження, а не вам в голову стрельнуло.

На мою думку cloud agnostic підхід дуже конфліктує з бізнес інтересами: створює великий оверхед на реалізацію того ж самого функціоналу, який з cloud-native міг бути набагато простішим.
В свою чергу cloud native підхід все більше переважає серед сучасних підходів (нагадаю, що це суто моя думка)
Єдине, що може цей підхід виправдати — це сама бізнес необхідність розробляти софт або інфру саме так, а уявити такий кейс складнувато.

У нас спочатку замовник хотів бути клауд агностік а потім потрохи почали прив’язуватися до сервісів хмари тому що розгортання і підтримка всього зоопарку сервісів у своєму k8s вимагає багато часу та грошей.

Як правило замовник не залишає такого вибору і сам диктує — будувати cloud agnostic інфраструктуру чи використовувати сервіси cloud provider’a.
Cloud agnostic підхід — це купа часу та зусиль в погоні за міфічно свобоою від vendor lock
Використання нативних сервісів хмарного провадера — це значна економія в часі і ресурсах
Якби мені довелось обирати я б обрав другий варіант, але, повторюсь, замовник замовляє бал і замовник диктує як будувати інфраструктуру

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

За те, що поділились думками — дякую ☺️

Підписатись на коментарі