В целом у меня такое чувство, что удешевили на 50%, но не упомянуты две важные цифры - сколько стоила миграция и сколько платят за поддержку Фланту. У меня такое чувство, что заказчик выиграл хорошо если 20-25%%, а в первый год наверняка вышло дороже.
Наша поддержка обходится значительно дешевле, чем стоимость инфраструктуры. Стоимость обслуживания инфраструктуры до и после и не изменилась. На время миграции вырастала, но не в разы.
Про трафик недоработка с нашей стороны, прокомментировал выше.
Очень хороший вопрос про трафик. Спасибо за него и вам, и другим людям в комментариях. Мы стали анализировать эту ситуацию и поняли, что далеко не всё в ней понимаем.
В статье были неверно расставлены акценты. Из-за них складывалось впечатление, что разница в стоимости каких-то услуг общего назначения (например, трафик) у двух провайдеров принесла столь значимый экономический выигрыш. Это не так. Миграция на другого провайдера вообще была второстепенна, а первична — новая схема инфраструктуры: self-hosted Kubernetes и Open Source-софт вместо managed-сервисов. Постарались переставить акценты в тексте статьи.
С вопросом получившейся разницы в стоимости трафика мы ещё разбираемся, но это оказалось не так очевидно, как предполагалось. На следующей неделе планируем дать пояснение.
Во-первых, Deckhouse — это Open Source-проект (и сертифицирован в CNCF на соответствие стандартному Kubernetes API). Во-вторых, идея этой платформы в поддержке разных провайдеров, чтобы не зависеть от поставщиков инфраструктуры.
Vendor lock — это про стоимость потенциального ухода (если что-то пойдет не так). Уйти с достаточно стандартного Kubernetes (и Open Source-проектов, задействованных в нем) проще, чем с проприетарных услуг AWS.
От людей внутри фирмы вы тоже будете зависеть... Но зависимость от них и их решений за lock считаться не будет? ;-) А ведь не так очевиден ответ на вопрос, кто даст больше гарантий: компания-подрядчик или сотрудник(и). Особенно в случаях, когда речь про малое число сотрудников (проекту не нужно больше для сопровождения инфраструктуры). И особенно сейчас, когда наблюдается острейшая нехватка кадров на рынке.
В этом материале речь не про абстрактный «открытый код», а вполне конкретно про Open Source, который не только про доступность кода, но и те самые свободы. Они зафиксированы в Open Source Definition. Код авторов публикации — это, как я понял, fistful-server и другие проекты организации RBKmoney. У них Open Source-лицензия Apache-2.0 License.
Прислушиваться полезно, согласен. Впрочем, приглашать к PR это тоже не мешает - уж хотя бы в случаях, когда понимаешь, что вот прямо сейчас сами этим не займёмся.
Но на уровне "прислушаться" - мы прислушались, автору (@maledog) за эти мысли спасибо!
Мне видится, что философия PostgreSQL с самого начала была в минимальном техдолге — в том, чтобы проектировать и делать всё с «самых низов» очень красиво и правильно. Благодаря этому они и достигли той самой железобетонности. В то же время это естественным образом увеличивало порог вхождения. Начинающим пользователям было сложно (что, впрочем, не помешало проекту собрать свою аудиторию…), и тут прослеживается некий такой исторический след, который мешает. Считать ли это техдолгом перед массовыми пользователями? :-)
С другой стороны, с тех пор многое изменилось — в том числе и подход к инфраструктуре. Операторы для K8s, которые здесь предлагает Коля (и по которым он делал обзор), — это как раз новый, сегодняшний взгляд на проблему (и вариант её решения).
Согласен, что интересно… Для этого нужно ждать информацию от самой Facebook. Им явно придётся выдать на публику какой-то отчёт. Пока есть только такое.
Это странно - как будто бы что-то не так было объяснено или понято. Можем разобраться, если это сколь-нибудь актуально (напишите в личку тогда, плз).
Потому что написанное на сайте - правда. У наших клиентов работают кластеры и в разных публичных провайдерах (AWS, GCP, Azure, Яндекс.Облако...), и в частных (OpenStack, vSphere), и на обычном bare metal.
Так что да, сейчас выглядит как «заказчика заставили заплатить за переезд в систему, в которой удобней работать исполнителю».
Не увидел этого примечания вчера. Как уже написал в комментарии выше, заказчик платит за то, чтобы получать результат для бизнеса, а инструменты для него вторичны. Если заказчик принципиально требует использования какой-то конкретной системы (а ее использование все же сопряжено с проблемами), на то должны быть весомые причины*, надо их отдельно обсуждать и приходить к компромиссу. А если нет компромисса, то искать другого исполнителя, и всем будет хорошо.
* В данном случае их не было. Здесь в комментариях они тоже по сути свелись к "работает - не трогай" без знания всей ситуации. А в плане более простой поддержки того, что было, дополни свои ответы напоминанием, что речь шла не про одну Gitea, а про Gitea+Jenkins.
Обсуждение статьи ушло не в том русле, для которого она была написана. Краткий ответ на ваш вопрос есть здесь, и там же объяснено, почему для более подробного ответа нужно было бы писать другой материал.
В "Как-то работало" и "как-то умудрились продать" чувствуется одновременно и противоречие, и разгадка для конкретного случая :-) За услугами не приходят просто так, когда все, что уже есть сейчас, бизнес устраивает... Проблемы были - и в том числе из-за того, что в схеме участвовала не только маленькая и делающая свое дело Gitea, но ее связка с Jenkins. И эта реализация не была достаточно гибкой и прозрачной, приносила и больше непонятного поведения, и сложности в процессе отладки. Но мы писали не об этом, а о пути, который посчитали оптимальным, учитывая многие факторы и в конечном счёте эффективность для бизнеса.
Спор в комментариях вообще получился о том, выгодно ли это бизнесу, когда статья была практической инструкцией для тех, кто хочет это сделать.
У статьи вообще не было умысла продвигать идею миграции с Gitea на GitLab как таковую. Материал для тех, кто такое решение уже принял или имеет свои причины его рассматривать. Для "убеждения" в такой миграции, как я уже писал, надо делать отдельную и совершенно другую статью, потому что раскрывать в ней надо бизнесовые темы (метрики, риски...) и весьма осторожно, т.к. случаи индивидуальны, а критериев - много. Сейчас же складывается впечатление, как будто мы призвали всех делать такую миграцию. Но этого не было и нет.
Если же переходит к теме бизнеса, то он ориентируется на свои показатели (метрики вроде скорости доставки новых версий бизнес-критичного софта) - ему они важны, а не то, какая Open Source-утилита будет под капотом для достижения адекватных значений. Нужен практический результат. Да, конечно, важен ещё фактор упомянутого vendor lock-in, потому что это финансовые риски, но конкретно эту тему уже в комментариях раскрыли достаточно, по-моему; аргументы приведены были, а выводы каждый волен делать сам.
"На куб у нас" означает, что он мог бы быть в том же провайдере (или на ваших серверах), но не использовать managed от него.
У каждого managed-решения своя специфика, которую нужно глубоко знать для обеспечения SLA по работе критичных для бизнеса приложений в нем.
У нас K8s-дистрибутив, который одинаково работает на разных провайдерах (в т.ч. на on-prem bare metal или OpenStack), сертифицированный в CNCF по соответствию базовым API оригинального K8s. Такой подход позволяет пользователю не быть ограниченным одним провайдером, а это огромная изначальная ценность Kubernetes, которую "съели" managed-сервисы крупных провайдеров.
Если же такой подход кажется неподходящим... что ж, это рынок, он рассудит :-)
Наша поддержка обходится значительно дешевле, чем стоимость инфраструктуры. Стоимость обслуживания инфраструктуры до и после и не изменилась. На время миграции вырастала, но не в разы.
Про трафик недоработка с нашей стороны, прокомментировал выше.
Очень хороший вопрос про трафик. Спасибо за него и вам, и другим людям в комментариях. Мы стали анализировать эту ситуацию и поняли, что далеко не всё в ней понимаем.
В статье были неверно расставлены акценты. Из-за них складывалось впечатление, что разница в стоимости каких-то услуг общего назначения (например, трафик) у двух провайдеров принесла столь значимый экономический выигрыш. Это не так. Миграция на другого провайдера вообще была второстепенна, а первична — новая схема инфраструктуры: self-hosted Kubernetes и Open Source-софт вместо managed-сервисов. Постарались переставить акценты в тексте статьи.
С вопросом получившейся разницы в стоимости трафика мы ещё разбираемся, но это оказалось не так очевидно, как предполагалось. На следующей неделе планируем дать пояснение.
Во-первых, Deckhouse — это Open Source-проект (и сертифицирован в CNCF на соответствие стандартному Kubernetes API). Во-вторых, идея этой платформы в поддержке разных провайдеров, чтобы не зависеть от поставщиков инфраструктуры.
Vendor lock — это про стоимость потенциального ухода (если что-то пойдет не так). Уйти с достаточно стандартного Kubernetes (и Open Source-проектов, задействованных в нем) проще, чем с проприетарных услуг AWS.
От людей внутри фирмы вы тоже будете зависеть... Но зависимость от них и их решений за lock считаться не будет? ;-) А ведь не так очевиден ответ на вопрос, кто даст больше гарантий: компания-подрядчик или сотрудник(и). Особенно в случаях, когда речь про малое число сотрудников (проекту не нужно больше для сопровождения инфраструктуры). И особенно сейчас, когда наблюдается острейшая нехватка кадров на рынке.
На время переезда стоимость обслуживания вырастала, но не в разы. После переезда она вернулась на прежний (т.е. до миграции) уровень.
В этом материале речь не про абстрактный «открытый код», а вполне конкретно про Open Source, который не только про доступность кода, но и те самые свободы. Они зафиксированы в Open Source Definition. Код авторов публикации — это, как я понял, fistful-server и другие проекты организации RBKmoney. У них Open Source-лицензия Apache-2.0 License.
Привет! Мы знаем, спасибо :-) Популярностью она пока совсем не пользуется, но чуть-чуть следим за ней.
Прислушиваться полезно, согласен. Впрочем, приглашать к PR это тоже не мешает - уж хотя бы в случаях, когда понимаешь, что вот прямо сейчас сами этим не займёмся.
Но на уровне "прислушаться" - мы прислушались, автору (@maledog) за эти мысли спасибо!
Присмотритесь ещё к Deckhouse ;-)
Мне видится, что философия PostgreSQL с самого начала была в минимальном техдолге — в том, чтобы проектировать и делать всё с «самых низов» очень красиво и правильно. Благодаря этому они и достигли той самой железобетонности. В то же время это естественным образом увеличивало порог вхождения. Начинающим пользователям было сложно (что, впрочем, не помешало проекту собрать свою аудиторию…), и тут прослеживается некий такой исторический след, который мешает. Считать ли это техдолгом перед массовыми пользователями? :-)
С другой стороны, с тех пор многое изменилось — в том числе и подход к инфраструктуре. Операторы для K8s, которые здесь предлагает Коля (и по которым он делал обзор), — это как раз новый, сегодняшний взгляд на проблему (и вариант её решения).
Вот тут теперь что-то появилось.
Согласен, что интересно… Для этого нужно ждать информацию от самой Facebook. Им явно придётся выдать на публику какой-то отчёт. Пока есть только такое.
Здесь есть перевод статьи от Cloudflare с их сторонним взглядом и техническими деталями, что именно произошло.
Ещё пару лет назад на Хабре был перевод очень по теме, которую здесь авторы не затронули: «Каково быть мейнтейнером свободного ПО».
Это странно - как будто бы что-то не так было объяснено или понято. Можем разобраться, если это сколь-нибудь актуально (напишите в личку тогда, плз).
Потому что написанное на сайте - правда. У наших клиентов работают кластеры и в разных публичных провайдерах (AWS, GCP, Azure, Яндекс.Облако...), и в частных (OpenStack, vSphere), и на обычном bare metal.
Не увидел этого примечания вчера. Как уже написал в комментарии выше, заказчик платит за то, чтобы получать результат для бизнеса, а инструменты для него вторичны. Если заказчик принципиально требует использования какой-то конкретной системы (а ее использование все же сопряжено с проблемами), на то должны быть весомые причины*, надо их отдельно обсуждать и приходить к компромиссу. А если нет компромисса, то искать другого исполнителя, и всем будет хорошо.
* В данном случае их не было. Здесь в комментариях они тоже по сути свелись к "работает - не трогай" без знания всей ситуации. А в плане более простой поддержки того, что было, дополни свои ответы напоминанием, что речь шла не про одну Gitea, а про Gitea+Jenkins.
Сравнивая все подобные показатели, надо ещё помнить, что GitLab пришел на замену не только Gitea, но её связке с Jenkins.
Обсуждение статьи ушло не в том русле, для которого она была написана. Краткий ответ на ваш вопрос есть здесь, и там же объяснено, почему для более подробного ответа нужно было бы писать другой материал.
В "Как-то работало" и "как-то умудрились продать" чувствуется одновременно и противоречие, и разгадка для конкретного случая :-) За услугами не приходят просто так, когда все, что уже есть сейчас, бизнес устраивает... Проблемы были - и в том числе из-за того, что в схеме участвовала не только маленькая и делающая свое дело Gitea, но ее связка с Jenkins. И эта реализация не была достаточно гибкой и прозрачной, приносила и больше непонятного поведения, и сложности в процессе отладки. Но мы писали не об этом, а о пути, который посчитали оптимальным, учитывая многие факторы и в конечном счёте эффективность для бизнеса.
Спор в комментариях вообще получился о том, выгодно ли это бизнесу, когда статья была практической инструкцией для тех, кто хочет это сделать.
У статьи вообще не было умысла продвигать идею миграции с Gitea на GitLab как таковую. Материал для тех, кто такое решение уже принял или имеет свои причины его рассматривать. Для "убеждения" в такой миграции, как я уже писал, надо делать отдельную и совершенно другую статью, потому что раскрывать в ней надо бизнесовые темы (метрики, риски...) и весьма осторожно, т.к. случаи индивидуальны, а критериев - много. Сейчас же складывается впечатление, как будто мы призвали всех делать такую миграцию. Но этого не было и нет.
Если же переходит к теме бизнеса, то он ориентируется на свои показатели (метрики вроде скорости доставки новых версий бизнес-критичного софта) - ему они важны, а не то, какая Open Source-утилита будет под капотом для достижения адекватных значений. Нужен практический результат. Да, конечно, важен ещё фактор упомянутого vendor lock-in, потому что это финансовые риски, но конкретно эту тему уже в комментариях раскрыли достаточно, по-моему; аргументы приведены были, а выводы каждый волен делать сам.
"На куб у нас" означает, что он мог бы быть в том же провайдере (или на ваших серверах), но не использовать managed от него.
У каждого managed-решения своя специфика, которую нужно глубоко знать для обеспечения SLA по работе критичных для бизнеса приложений в нем.
У нас K8s-дистрибутив, который одинаково работает на разных провайдерах (в т.ч. на on-prem bare metal или OpenStack), сертифицированный в CNCF по соответствию базовым API оригинального K8s. Такой подход позволяет пользователю не быть ограниченным одним провайдером, а это огромная изначальная ценность Kubernetes, которую "съели" managed-сервисы крупных провайдеров.
Если же такой подход кажется неподходящим... что ж, это рынок, он рассудит :-)