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

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

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

Що оберете ви:
— використовувати кросплатформені інструменти для вашої хмарної інфраструктури зараз, щоб бути якомога менш залежними від 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

Люди боятся привязки к облаку и вендор лока в целом больше чем следовало бы. Весь если делать все универсальным то тоже может получится что то неповоротливое и более тяжело поддерживаемое.
Нужно считать в каждом конкретном случае риски перехода на другую платформу и стоимость поддержки универсальности. Даже если писать что либо не зависимое от клауд провайдеров все равно зависимости могут остаться на сервисы. Например для метрик можно вместо AWS системы выбрать DataDog но риск то все равно остаётся. Можно поддерживать свое и вообще свой Клауд написать с нуля но зачем? Лучше потратить это время на решение проблем бизнеса.
В универсальности есть смысл если вы разработчик B2B продукта который ваши пользователи будут использовать в разных облаках и своих дата центрах.

Сенс універсальності в тому, що якщо Ваша рітейл компанія з обертом в 20 міліардів на рік раптом стане поперек горла Амазону — то Ви б могли відносно просто перейти до гугла. Бо маючи 300 різних проектів, які зав’язли в AWS ви просто закриєте бізнес, якщо того забажає Амазон.

Не думаю, що хтось з великих компаній готовий до таких ризиків

Частично согласен. Ну даже если сервисы написаны универсально переезд занимает не 1 год обычно. Это лишь один из рисков который стоит учитывать.Каждая компания решает для себя как работать с этим рисков. Зависит еще от стадии развития на которой находится компания.

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

А в чем была причина переезда длительностью почти в 2 года?

— міграція майже 200 сервісів
— викинути зайве
— перекинути майже 2 терабайта даних з близько 500 Азур блоб сховищ, не загубити нічого та зробити це швидше ніж сколапсує всесвіт
— пофіксити майже 99% усіх технічних боргів та замість милиць зробити більш менш надійні рішення
— перейти з MS SQL на PgSql та мігрувати туди дані
— перенести дані з Azure Blib Table на PgSql
Та ще 100500 інших дрібниць які були щільно зав’язані на Azure

Это да. А в чем причина именно самого переезда. Неужели AWS получится на столько дешевле что перекрыл все эти расходы?

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

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

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

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

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