Комментарии 30
Где-то читал, что в Амазон приходят его "попробовать", а потом никто не может от него уйти из-за вендор-лока...
AWS в целом не дешевый если сравнивать с ценой на работу опенсурса на голом железе, но без учета трудозатрат. В трудозатратах кроется вся суть. Для большинства проектов трудозатраты на поддержание своей инфраструктуры и сервисов в рабочем состоянии это дороже, с точки зрения ЗП и убытков от сбоев чем готовые сервисы в cloud провайдерах.
Проектов в которых возникает проблема с масштабами как у описанной компани не так много. В целом 1.5 месяца на перезд после того как у вас сформировался устойчивый доходный бизнес, приносящий доход, для меня это выглядит очень быстро и не как проблема, просто автору статьи нужно было за что-то зацепиться для увеличения значимости посыла статьи.
На мой взгляд AWS самый user friendly из доступных cloud.
В статье не рассмотрены затраты на сам переезд и сколько после переезда стала стоять поддержка?
Очень странные сравнения по оптимизации костов, с акцентом на GCP. Что мешало переехать в тот же самый EKS в AWS? Все те же HPA и автоскейлеры, плюс спотовые инстансы в AWS куда дружелюбнее и могут не перегружаться месяцами. Я к тому, что никто не запрещает использовать AWS и не залезать в вендор-лок слишком глубоко, экономить косты и при этом иметь возможность уехать в другое облако в адекватные сроки.
Коллеги достаточно чётко отвечают на этот вопрос - стоимость трафика и дисков с высоким IOPS была слишком высока. От этого проект никак не смог бы деться без переезда.
По поводу спотовых инстансов - да, могут жить месяцами, а потом резко закончится. В нашей практике были случаи когда у нас была Autoscaling group на спотах с 3 типами инстансов. И в один прекрасный день все типы стали резко недоступны на несколько часов.
Так и надо писать, а то амазон такой плохой и якобы не позволяет использовать кубернетес и прочие не вендор-лок решения - вот такое впечатление остается после статьи.
Основные работы были выполнены примерно за 3 недели. Но с учетом подготовки и стабилизации некоторых сервисов после переезда весь этот проект в общем занял около полутора месяцев.
кстати, это весьма быстро. Или кто-то думал, что съехать с кубера в одном облаке в другой будет сильно быстрее? Тем более - сами пишете - очень много времени заняла настройка балансировщика в гугле (т.е. именно тот компонент, который нельзя проэмулировать или безболезненно заменить)...
Про кубер тоже интересно. Вот все говорят, что кубер везде одинаковый. Но это не так. Везде свои особенности. В том же ДО - хрен, а не больше 10 pvc. Или балансировщики разные. Или версии компонентов. Или набор компонентов и рестрикций. В результате поверх куба можно написать некий обобщающий слой. Но это работа, которую кто-то должен сделать и не всегда она имеет бизнес-велью
ну так разве наш deckhouse - не обобщает? :)
Я не хочу писать о том, что я руками сам не трогал ;-)
Но могу напомнить про закон протекающих абстракций. Строя некий фасад - все равно оно будет ломаться где-то. И все равно не удастся скрыть детали реализации конкретных платформ - или это надо инженеров иметь больше, чем у Фланта с Саусбридж вместе взятыми :-) чтобы все было красиво и работало в 99% случаев.
Касательно дистрибов куба... могу вспомнить историю с ранчером, который предлагал решить все проблемы пользователя, а в результате до сих пор не может обеспечить плавный переход с rke v1 на rke v2. И будущее туманно, учитывая, что их купила Сусе ))))
наш путь - особенный! ( я знаю, что все так говорят :) )
И ИМХО, это плохо для заказчика, так как означает для него Flant vendor lock.
Во-первых, Deckhouse — это Open Source-проект (и сертифицирован в CNCF на соответствие стандартному Kubernetes API). Во-вторых, идея этой платформы в поддержке разных провайдеров, чтобы не зависеть от поставщиков инфраструктуры.
Vendor lock — это про стоимость потенциального ухода (если что-то пойдет не так). Уйти с достаточно стандартного Kubernetes (и Open Source-проектов, задействованных в нем) проще, чем с проприетарных услуг AWS.
Тут пишут, что egress GCP это 12-8 центов за Гб. У Амазона от 9 центов и ниже. Непонятно как вы на трафике экономите?
А если заморочиться с AWS Private Link то платить можно 2 цента за Гб + сколько возьмёт местный провайдер.
Я могу предположить, что у клиента утилизация ресурсов была низкой. При переезде купили сервера дешевле, настроили автомасштабирование и сэкономили за счёт лучшей утилизации ресурсов. Что с egress непонятно, у гугла он вроде дороже чем у AWS. Могу предположить, что было много «лишнего» трафика внутри AWS зон, который после переезда пропал.
Очень хороший вопрос про трафик. Спасибо за него и вам, и другим людям в комментариях. Мы стали анализировать эту ситуацию и поняли, что далеко не всё в ней понимаем.
В статье были неверно расставлены акценты. Из-за них складывалось впечатление, что разница в стоимости каких-то услуг общего назначения (например, трафик) у двух провайдеров принесла столь значимый экономический выигрыш. Это не так. Миграция на другого провайдера вообще была второстепенна, а первична — новая схема инфраструктуры: self-hosted Kubernetes и Open Source-софт вместо managed-сервисов. Постарались переставить акценты в тексте статьи.
С вопросом получившейся разницы в стоимости трафика мы ещё разбираемся, но это оказалось не так очевидно, как предполагалось. На следующей неделе планируем дать пояснение.
Добавили в статью уточнение про внутренний трафик между регионами AWS. В старой схеме по факту функционировал full mesh (между API, PgBouncer и СУБД). Но эта схема была сделана на этапе быстрого запуска проекта. С ростом проекта стала заметна проблема неэффективности такого подхода (этот излишний трафик привел к растущим дополнительным расходам). При переезде в новую инфраструктуру проблема решилась сама собой, т.к. взаимодействие между сервисами приложения стало более оптимальным.
P.S. Попутно ещё уточнили про IOPS: платить перестали за provisioned IOPS, а нужную производительность (для СУБД) получили благодаря большим SSD-дискам.
Поднять приватный куб на рентованом железе получилось бы еще дешевле.
на арендованном железе теряешь гибкость масштабирования - никто не может железо поставлять мгновенно ) все равно будет какой-то лаг между заказом железа и его реальной доступностью для ПО... Я уж не говорю о том, что запросто еще можно влететь в историю с недостатком айпи адресов, места в стойках или еще чем-то подобном... Облако вроде как эти проблемы решает... но какой ценой?
Не соглашуть. Ни вцелом ни в деталях. Сразу контр-пример https://metal.equinix.com/ из известных. Да и вцелом из-за отностительно дешевизны железа стоит делать overprovisiong.
Вы можете не соглашаться как угодно и сколько угодно. Реальность провайдеров вроде reg.RU / servers.com в том, что железки в лучшем случае за день появляются. Если хостишься в датацентре - там тоже закупочный цикл железа и все такое. Месяцы.
Вы хороший пример насчёт эквиникса приводите и слава богу, что они есть. Но это только часть многообразного мира.
К примеру, для меня было вообще открытием, что виртуальный хостинг в Германии все ещё жив. На него есть спрос. Я сам в шоке. И не всегда клиенты хотят переползать на что-то более технологичное…
Сравнивать GCP с REG.ru как-то вообще не оно. А вот сравнить GCP с Equinix очень даже оно. Виртальный шаред хостинг шив еще как и в США, Германия тут не одинока.
Странно, что сравнивали ECS и GKE, когда у AWS есть EKS.
Касаемо цены за трафик - AWS очень хорошо торгуются, при определенных объемах цену на трафик можно уронить в 10 раз. Может проблема была в Inter-AZ трафике? Что объяснимо, если используется Posgtres, т.к. мастер строго в одной зоне доступности, когда как клиенты в ECS могут (и должны) быть размазаны по всем зонам.
может быть это заявка на использование более cloud native баз, чем постгрес?
Если говорить про SQL, то у AWS есть Aurora Serverless, но она и дороже, и не лишена неких технических нюансов. Например, скейлинг вверх там не такой быстрый, как хотелось бы. Плюс, хотя AWS и гарантирует совместимость на уровне протокола, производительность в разных сценариях может отличаться от классической БД, что, возможно, придется парировать изменением кода.
Но все это - рассуждения в отрыве от бизнес задачи
Это касается, например, оркестратора контейнеров ECS: сравнивать его возможности с возможностями Kubernetes было бы некорректно.
Это точно :-)
В целом у меня такое чувство что заказчик поменял AWS vendor lock на Flant vendor lock, и ИМХО первое было лучше.
Я не против того, что при определенном scale может быть выгоднее использовать железные или виртуальные серверы чем SaaS, но ИМХО для этого нужны соответствующие люди внутри фирмы. Платить и зависеть от внешней фирмы?! - по-моему это менее надежно и выгодно чем использовать SaaS.
Короче, я бы просто оптимизировал внутри AWS.
От людей внутри фирмы вы тоже будете зависеть... Но зависимость от них и их решений за lock считаться не будет? ;-) А ведь не так очевиден ответ на вопрос, кто даст больше гарантий: компания-подрядчик или сотрудник(и). Особенно в случаях, когда речь про малое число сотрудников (проекту не нужно больше для сопровождения инфраструктуры). И особенно сейчас, когда наблюдается острейшая нехватка кадров на рынке.
при определенном scale
Да, надо строить культуру DevOps, как это сделали Netflix, Google, Facebook, и другие.
Очень сомневаюсь что Adapty достигла этого scale.
Поэтому я бы оставался в AWS с *aaS, говоря простым языком - с RDS, managed K8S, и т.д.
Кстати: Упоминание про дорогой траффик, как уже сказали многие, очень странное, да и для удешевления IOPS в AWS есть разные решения.
В целом у меня такое чувство, что удешевили на 50%, но не упомянуты две важные цифры - сколько стоила миграция и сколько платят за поддержку Фланту. У меня такое чувство, что заказчик выиграл хорошо если 20-25%%, а в первый год наверняка вышло дороже.
В целом у меня такое чувство, что удешевили на 50%, но не упомянуты две важные цифры - сколько стоила миграция и сколько платят за поддержку Фланту. У меня такое чувство, что заказчик выиграл хорошо если 20-25%%, а в первый год наверняка вышло дороже.
Наша поддержка обходится значительно дешевле, чем стоимость инфраструктуры. Стоимость обслуживания инфраструктуры до и после и не изменилась. На время миграции вырастала, но не в разы.
Про трафик недоработка с нашей стороны, прокомментировал выше.
Так а как получилось сэкономить на трафике то? Пример расчета то можно?
с учетом например того что в Амазоне базовый WAF c защитой от ДДоС атак уже включен в ценник, а в Гугле надо отдельно докупать.
Переехать в Kubernetes и платить за инфраструктуру вдвое меньше? История Adapty