Перечисленные дистрибутивы - это компактные инсталляции для задач типа тестирования, локальной разработки и т.п. Deckhouse - это полноценная платформа для production, расширяющая возможности ванильного K8s; ближайшие аналоги - это OpenShift и Tanzu.
На первый вопрос логичным ответом звучит то, что еще тогда сразу требовалось managed-решение:
У ИТ-команды robota.ua не было опыта работы с Kubernetes, поэтому managed-сервис стал самым рациональным способом кубернетизировать приложения.
А из чего было выбирать в самой Украине?..
По третьему вопросу: график хорошо показывает, что с ростом кластера затраты на текущий вариант Kubernetes'а становятся только выгоднее (по сравнению с managed-решением от крупного провайдера). Если говорить про сравнение с зарплатой, то ведь логично (раз сейчас всё устраивает), что и инженер из-за растущей инфраструктуры: а) понадобится позже, б) будет решать более высокоуровневые задачи по инфре, оставив низкий уровень платформе Deckhouse (об этом был такой наш доклад).
В реестр вносится весь продукт, а не его инсталлятор или его отдельные фрагменты. Для лучшего понимания достаточно взять пример с любым дистрибутивом Linux в реестре (Альт, Astra и т.п.). Deckhouse — это не просто инсталлятор, а дистрибутив с модулями.
Добавили в статью уточнение про внутренний трафик между регионами AWS. В старой схеме по факту функционировал full mesh (между API, PgBouncer и СУБД). Но эта схема была сделана на этапе быстрого запуска проекта. С ростом проекта стала заметна проблема неэффективности такого подхода (этот излишний трафик привел к растущим дополнительным расходам). При переезде в новую инфраструктуру проблема решилась сама собой, т.к. взаимодействие между сервисами приложения стало более оптимальным.
P.S. Попутно ещё уточнили про IOPS: платить перестали за provisioned IOPS, а нужную производительность (для СУБД) получили благодаря большим SSD-дискам.
В целом у меня такое чувство, что удешевили на 50%, но не упомянуты две важные цифры - сколько стоила миграция и сколько платят за поддержку Фланту. У меня такое чувство, что заказчик выиграл хорошо если 20-25%%, а в первый год наверняка вышло дороже.
Наша поддержка обходится значительно дешевле, чем стоимость инфраструктуры. Стоимость обслуживания инфраструктуры до и после и не изменилась. На время миграции вырастала, но не в разы.
Про трафик недоработка с нашей стороны, прокомментировал выше.
Очень хороший вопрос про трафик. Спасибо за него и вам, и другим людям в комментариях. Мы стали анализировать эту ситуацию и поняли, что далеко не всё в ней понимаем.
В статье были неверно расставлены акценты. Из-за них складывалось впечатление, что разница в стоимости каких-то услуг общего назначения (например, трафик) у двух провайдеров принесла столь значимый экономический выигрыш. Это не так. Миграция на другого провайдера вообще была второстепенна, а первична — новая схема инфраструктуры: self-hosted Kubernetes и Open Source-софт вместо managed-сервисов. Постарались переставить акценты в тексте статьи.
С вопросом получившейся разницы в стоимости трафика мы ещё разбираемся, но это оказалось не так очевидно, как предполагалось. На следующей неделе планируем дать пояснение.
Во-первых, Deckhouse — это Open Source-проект (и сертифицирован в CNCF на соответствие стандартному Kubernetes API). Во-вторых, идея этой платформы в поддержке разных провайдеров, чтобы не зависеть от поставщиков инфраструктуры.
Vendor lock — это про стоимость потенциального ухода (если что-то пойдет не так). Уйти с достаточно стандартного Kubernetes (и Open Source-проектов, задействованных в нем) проще, чем с проприетарных услуг AWS.
От людей внутри фирмы вы тоже будете зависеть... Но зависимость от них и их решений за lock считаться не будет? ;-) А ведь не так очевиден ответ на вопрос, кто даст больше гарантий: компания-подрядчик или сотрудник(и). Особенно в случаях, когда речь про малое число сотрудников (проекту не нужно больше для сопровождения инфраструктуры). И особенно сейчас, когда наблюдается острейшая нехватка кадров на рынке.
Время такое…
Обсудили в kubernetes_ru со статистикой и прочим: потому что Argo популярнее ;-)
Совсем не вижу «форсинга» в этой статье ;-)
Опубликовали на английском.
Перечисленные дистрибутивы - это компактные инсталляции для задач типа тестирования, локальной разработки и т.п. Deckhouse - это полноценная платформа для production, расширяющая возможности ванильного K8s; ближайшие аналоги - это OpenShift и Tanzu.
А как померить, что проблем больше, чем пользы? Растущее сообщество и количество внедрений разве не является доказательством большей пользы?
Для сети у нас в планах cilium (issue).
На первый вопрос логичным ответом звучит то, что еще тогда сразу требовалось managed-решение:
А из чего было выбирать в самой Украине?..
По третьему вопросу: график хорошо показывает, что с ростом кластера затраты на текущий вариант Kubernetes'а становятся только выгоднее (по сравнению с managed-решением от крупного провайдера). Если говорить про сравнение с зарплатой, то ведь логично (раз сейчас всё устраивает), что и инженер из-за растущей инфраструктуры: а) понадобится позже, б) будет решать более высокоуровневые задачи по инфре, оставив низкий уровень платформе Deckhouse (об этом был такой наш доклад).
В реестр вносится весь продукт, а не его инсталлятор или его отдельные фрагменты. Для лучшего понимания достаточно взять пример с любым дистрибутивом Linux в реестре (Альт, Astra и т.п.). Deckhouse — это не просто инсталлятор, а дистрибутив с модулями.
В блоге Kubernetes появился официальный анонс этого релиза. В качестве его главной темы авторы выбрали стабилизацию IPv4/IPv6 dual-stack.
Хорошо, что есть разные инструменты. Но игнорировать Helm невозможно.
Здесь есть очень подробное объяснение.
Добавили в статью уточнение про внутренний трафик между регионами AWS. В старой схеме по факту функционировал full mesh (между API, PgBouncer и СУБД). Но эта схема была сделана на этапе быстрого запуска проекта. С ростом проекта стала заметна проблема неэффективности такого подхода (этот излишний трафик привел к растущим дополнительным расходам). При переезде в новую инфраструктуру проблема решилась сама собой, т.к. взаимодействие между сервисами приложения стало более оптимальным.
P.S. Попутно ещё уточнили про IOPS: платить перестали за provisioned IOPS, а нужную производительность (для СУБД) получили благодаря большим SSD-дискам.
… но в статье осталось :-)
Наша поддержка обходится значительно дешевле, чем стоимость инфраструктуры. Стоимость обслуживания инфраструктуры до и после и не изменилась. На время миграции вырастала, но не в разы.
Про трафик недоработка с нашей стороны, прокомментировал выше.
Очень хороший вопрос про трафик. Спасибо за него и вам, и другим людям в комментариях. Мы стали анализировать эту ситуацию и поняли, что далеко не всё в ней понимаем.
В статье были неверно расставлены акценты. Из-за них складывалось впечатление, что разница в стоимости каких-то услуг общего назначения (например, трафик) у двух провайдеров принесла столь значимый экономический выигрыш. Это не так. Миграция на другого провайдера вообще была второстепенна, а первична — новая схема инфраструктуры: self-hosted Kubernetes и Open Source-софт вместо managed-сервисов. Постарались переставить акценты в тексте статьи.
С вопросом получившейся разницы в стоимости трафика мы ещё разбираемся, но это оказалось не так очевидно, как предполагалось. На следующей неделе планируем дать пояснение.
Во-первых, Deckhouse — это Open Source-проект (и сертифицирован в CNCF на соответствие стандартному Kubernetes API). Во-вторых, идея этой платформы в поддержке разных провайдеров, чтобы не зависеть от поставщиков инфраструктуры.
Vendor lock — это про стоимость потенциального ухода (если что-то пойдет не так). Уйти с достаточно стандартного Kubernetes (и Open Source-проектов, задействованных в нем) проще, чем с проприетарных услуг AWS.
От людей внутри фирмы вы тоже будете зависеть... Но зависимость от них и их решений за lock считаться не будет? ;-) А ведь не так очевиден ответ на вопрос, кто даст больше гарантий: компания-подрядчик или сотрудник(и). Особенно в случаях, когда речь про малое число сотрудников (проекту не нужно больше для сопровождения инфраструктуры). И особенно сейчас, когда наблюдается острейшая нехватка кадров на рынке.
На время переезда стоимость обслуживания вырастала, но не в разы. После переезда она вернулась на прежний (т.е. до миграции) уровень.