В этом материале речь не про абстрактный «открытый код», а вполне конкретно про 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-сервисы крупных провайдеров.
Если же такой подход кажется неподходящим... что ж, это рынок, он рассудит :-)
Про админов - в случае обслуживания у нас это скорее наоборот, потому что поддерживать большое количество однотипных сервисов гораздо проще, чем что-то другое, пусть оно даже меньшего размера (зато со своей спецификой, да ещё и гораздо меньшим сообществом на случай проблем, которые все равно иногда случаются). В случае обслуживания кем-то ещё - опять же, найти админа, знающего и умеющего более популярное решение (стандарт индустрии по факту), всегда сильно проще.
Вычислительные ресурсы в данной конкретной истории совсем не те, чтобы это было значительной разницей.
Думаете, в этом больше рисков, чем в том, что менее популярное решение не будет достаточно хорошо развиваться (потому что к нему меньше интереса и у пользователей, и у разработчиков, и нет стабильной финансовой поддержки)? Мне так не кажется.
А форкнуть можно и GitLab. Как у решения с гораздо большей аудиторией, скорее всего этим форком заинтересуются больше людей, чем даже условная половина сообщества маленького проекта.
И ещё важно в данном случае (если уж сравнивать с другими примерами): а) оба этих продукта - self-hosted и б) работают поверх одной и той же Git (а не на разных систем версионирования, что потребовало бы дополнительных манипуляций на уровне самого хранилища).
Зависит от того, что и с чем сравнивать. Тут мы сравниваем два Open Source-проекта. Один из которых значительно (ну, уж на порядок — точно) популярнее другого.
P.S. Не думаю, что указанный выше стек был самым популярным. Для меня таковым являлся Linux + Apache. Но не суть…
Не только, но преимущественно — да. Потому что так накапливается опыт/инструменты, с которыми создается добавленная стоимость, чтобы оказывать услуги эффективно и качественно (а не просто перепродавать чьи-то часы работы).
В этом материале речь не про абстрактный «открытый код», а вполне конкретно про 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-сервисы крупных провайдеров.
Если же такой подход кажется неподходящим... что ж, это рынок, он рассудит :-)
Про админов - в случае обслуживания у нас это скорее наоборот, потому что поддерживать большое количество однотипных сервисов гораздо проще, чем что-то другое, пусть оно даже меньшего размера (зато со своей спецификой, да ещё и гораздо меньшим сообществом на случай проблем, которые все равно иногда случаются). В случае обслуживания кем-то ещё - опять же, найти админа, знающего и умеющего более популярное решение (стандарт индустрии по факту), всегда сильно проще.
Вычислительные ресурсы в данной конкретной истории совсем не те, чтобы это было значительной разницей.
Думаете, в этом больше рисков, чем в том, что менее популярное решение не будет достаточно хорошо развиваться (потому что к нему меньше интереса и у пользователей, и у разработчиков, и нет стабильной финансовой поддержки)? Мне так не кажется.
А форкнуть можно и GitLab. Как у решения с гораздо большей аудиторией, скорее всего этим форком заинтересуются больше людей, чем даже условная половина сообщества маленького проекта.
И ещё важно в данном случае (если уж сравнивать с другими примерами): а) оба этих продукта - self-hosted и б) работают поверх одной и той же Git (а не на разных систем версионирования, что потребовало бы дополнительных манипуляций на уровне самого хранилища).
Зависит от того, что и с чем сравнивать. Тут мы сравниваем два Open Source-проекта. Один из которых значительно (ну, уж на порядок — точно) популярнее другого.
P.S. Не думаю, что указанный выше стек был самым популярным. Для меня таковым являлся Linux + Apache. Но не суть…
Не только, но преимущественно — да. Потому что так накапливается опыт/инструменты, с которыми создается добавленная стоимость, чтобы оказывать услуги эффективно и качественно (а не просто перепродавать чьи-то часы работы).