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

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

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

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

Теми: cloud, DevOps, допомога, порада

Ctrl + Enter

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 17.01.2023 17:08

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

Відповісти

Підтримати

Roman Gordiienko Solution Architect 28.01.2023 17:17

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

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

Pavlo Vasylchenko

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 28.01.2023 22:06

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

Roman Gordiienko

Kai Owas 17.05.2022 00:49

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

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 17.01.2023 17:02

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

Kai Owas

Kai Owas 17.01.2023 17:44

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

Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 28.01.2023 12:26

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

Dmytro Brahinets Delivery lead в Uinno 14.05.2022 20:31

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

Vadym Mykolaichuk DevOps Engineer в Sana Commerce 15.05.2022 08:39

Якщо говорити про 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 ... тут купа всього може бути..)

Dmytro Brahinets

Roman Gordiienko Solution Architect 28.01.2023 17:19

Коммунікація, сховища данних, моніторинг, управління інфрою... не все ж тільки Кубер

Володимир Корнійчук Senior Software Engineer (C++) в Infopulse, Part of Tietoevry Create 13.05.2022 18:08

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

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

Borys Tsolin DevOps в Capgemini 13.05.2022 16:10

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

Дмитро Сафронов Senior software engineer 13.05.2022 16:00

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

Валентин Радчук Senior Developer 13.05.2022 13:59

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

Vadym Mykolaichuk DevOps Engineer в Sana Commerce 14.05.2022 17:04

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

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

Валентин Радчук

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

15 коментарів

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