И еще один момент — я не утверждал, что работающее решение без поддержки хуже неработающего с поддержкой. Не знаю, где вы это нашли:) Я лишь сказал, что в ряде случаев бизнес и сам переходит на отечественные решения (и делал это еще до февраля 2022 года и без всяких требований регулятора) — потому что видит в этом выгоду и удобство, потому что продукты качественные и конкурентоспособные. Все ли отечественные ИТ-продукты таковы? Конечно же, нет. Как, собственно, и ИТ-продукты любой другой страны мира.
Вы берете одного не очень добросовестного вендора и хотите этим случаем польностью перечеркнуть все усилия, вложения и искреннюю работу ради удобства пользователей, которую проделывает огромное количество других отечественных вендоров. Это очень странно и не вполне аргументированно:)
Кажется, вы уж больно сильно упрощаете ситуацию и смещаете акценты:) Во-первых, далеко не у всех отечественных вендоров все так плохо — и многие из них еще до известных событий конкурировали с заруюежными вендорами, предоставляя те или иные фичи и возможности, которых у западных вендоров не хватало для ру-рунка. Что же касается системы обучения и хорошей техподдержки от западных вендоров — и тут многим отечественным бизнесам есть что сказать и рассказать. У западных вендоров, даже у очень и очень крупных, с этим тоже нередко есть проблемы.
Все же в текущем контексте это не столько про патриотизм, сколько про требования регулятора или удобство для бизнеса в текущих обстоятельствах — пользоваться многими зарубежными решениями невозможно из-за того, что лицензии на них просто не продаются, официальной поддержки нет, каналы обновлений могут быть заблокированы и т.п. Бизнес, как правило, идет туда, где выгоднее.
Loghouse создавался как вынужденная времянка, потому что подходящего для нас решения по логам на тот момент не было. Мы создали проект, но планы (ресурсы) по его развитию были весьма скромные. Спустя какое-то время появился мейнстримовый Loki, который закрыл для нас все боли, а своих ресурсов на разработку больше не стало. В итоге перешли на Loki.
Нанимали Google Translate:) Плюс для уточнения разных нюансов перелопатили разные англоязычные и русскоязычные источники, чтобы выверить перевод терминов и т.п. Ну и у Андрея мощный бэкграунд во всем этом.
В статье описывается то, с чем авторы столкнулись на практике во время своего последнего исследования кластеров в интернете. Видимо, не везде свежие версии K8s, и такие проблемы продолжают оставаться проблемами для такой категории кластеров.
В исследовании мы фокусировались на микросервисах (да, Zabbix тоже вливается в историю про микросервисы, но, по нашему опыту, в микросервисном мире его используют реже, чем тот же Prometheus). Поэтому тут он входит в категорию «Другие инструменты».
Причем тут негодяи? Я говорю о рисках для бизнеса. Что касается воровства, то это абсолютно некорректное сравнение — воровством было бы использовать инструмент в нарушение лицензии. А экосистема Open Source устроена так, что ты можешь контрибьютить в одни проекты, а пользоваться результатами других проектов. Те же HashiCorp наверняка используют и Linux, и Kubernetes, и кучу других Open Source-утилит, и далеко не во все из них контрибьютят. Они воры, получается? Конечно же, нет. Никто не отрицает, что есть прям нечистоплотные ребята, которые используют Open Source, не отдавая ничего взамен, но все же эта экосистема дала и продолжает давать миру ИТ удивительные и крутые продукты. А подобные решения вендоров экосистему Open Source потенциально уничтожают. Конечно, выгодно использовать Open Source-решение, которое кто-то сделал за вас когда-то давно, но это не означает, что в итоге такая ситуация, как случилась с hashiCorp не является для компании риском. Это вроде бы прям элементарные штуки — речь не о плохих и хороших, а о том, что прямо сейчас для бизнеса, который полагался на какой-то из Open Source-продуктов (и полагался вполне законно), кардинально меняются условия существования. Это риск? Ну, однозначно риск. Очень странно было бы это отрицать.
Всё так, только вы говорите о конечном результате, а не о ситуации, когда проблема приключилась и вам надо собрать сообщество, договориться с другими компаниями, которые хотят участвовать в проекте, изучить код, нанять инженеров, которые будут поддерживать и развивать решение с вашей стороны, ввалиться в R&D и т.п. И если всё это получится вывезти, тогда через пару-тройку лет можно уже будет говорить о каких-то профитах. Но и то будет проблема — теперь на то же решение вы тратите на порядки больше сил и денег. И не всегда это оправданная цена за полученную от решения выгоду. А теперь еще представьте ситуацию, когда автор не бросает проект, а ставит на него ограничения — в этом случае еще и подавляющая часть сообщества может остаться с прежним, уже ограниченным, решением и считать, что для них ничего не поменялось. В такой ситуации собирать сообщество и искать партнеров, с которыми можно будет вместе вваливаться в разработку и поддержание будущего форка, станет еще сложнее.
Кстати, появились некоторые подробности про последствия для всей экосистемы — добавили Upd в конце статьи специально об этом, дублирую тут в комментарии:) Показалось, что вам может быть интересно в контексте диалога.
В Cloud Native Computing Foundation уже начались подробные исследования того, как изменение лицензии на продукты и компоненты продуктов HashiCorp скажутся в том числе и на открытых проектах CNCF. Проблема в том, что можно импортировать в свой проект небольшой фрагмент продукта компании как библиотеку и даже не особо догадываться, что там сменилась лицензия. Например, есть пакет vault/api, который используют все, кто интегрируется с Vault. Лицензия на него тоже поменялась на BSL — и вот где его обнаружили. То есть хотя HashiCorp сказали, что SDK, API и библиотеки останутся под MPL, в реальности это не совсем так — потому что отдельные компоненты их продуктов лицензию в итоге сменили. Да, не все такие проекты CNCF являются конкурирующими по отношению к продуктам HashiCorp, но у Open Source-проектов есть и требования к совместимости лицензий отдельных компонентов. То есть изменения лицензий HashiCorp потенциально способно повлиять на очень большое количество свободных проектов от сообщества. В общем, еще один скользкий момент:)
Стратегии же в бизнесе выстраиваются не исключительно на самых плохих сценариях и рисках. Иначе никто бы бизнесом не занимался. А на разумном прогнозировании этих сценариев и умеренно-оптимистичных прогнозах. Такова реальность. Без надежды на что-то хорошее или на то, что риск может не сбыться, бизнес вообще не построить.
Ну вы же сами и описали все риски:) То, что с ними можно попробовать справиться каким-то образом, не означает, что они рисками не являются. И то, что позиционируются себя как Open Source-вендор на протяжении десятка лет компания вдруг в один день принимает такое решение — это очень серьезное событие в жизни компании, которая ее продуктами пользуется. А между плывите сами дальше (я устал поддерживать проект) и «а теперь это больше не Open Source, платите,» все же есть очень большая разница. И второй сценарий гораздо более неприятен с точки зрения попытки поддержки и развития отдельной Open Source-ветки.
В гугле не нашли таких новостей. В наши новостные фильтры тоже не попало. Видимо, не форкали(
Изначальный Terraform вроде бы достаточно распространенный инструмент, чтобы не давать о нем отдельную справку в статье:) Если вы об этом.
И еще один момент — я не утверждал, что работающее решение без поддержки хуже неработающего с поддержкой. Не знаю, где вы это нашли:) Я лишь сказал, что в ряде случаев бизнес и сам переходит на отечественные решения (и делал это еще до февраля 2022 года и без всяких требований регулятора) — потому что видит в этом выгоду и удобство, потому что продукты качественные и конкурентоспособные. Все ли отечественные ИТ-продукты таковы? Конечно же, нет. Как, собственно, и ИТ-продукты любой другой страны мира.
Вы берете одного не очень добросовестного вендора и хотите этим случаем польностью перечеркнуть все усилия, вложения и искреннюю работу ради удобства пользователей, которую проделывает огромное количество других отечественных вендоров. Это очень странно и не вполне аргументированно:)
Кажется, вы уж больно сильно упрощаете ситуацию и смещаете акценты:) Во-первых, далеко не у всех отечественных вендоров все так плохо — и многие из них еще до известных событий конкурировали с заруюежными вендорами, предоставляя те или иные фичи и возможности, которых у западных вендоров не хватало для ру-рунка. Что же касается системы обучения и хорошей техподдержки от западных вендоров — и тут многим отечественным бизнесам есть что сказать и рассказать. У западных вендоров, даже у очень и очень крупных, с этим тоже нередко есть проблемы.
Про будущее, конечно, много неясного, но прямо сейчас бизнесу некуда деваться
Все же в текущем контексте это не столько про патриотизм, сколько про требования регулятора или удобство для бизнеса в текущих обстоятельствах — пользоваться многими зарубежными решениями невозможно из-за того, что лицензии на них просто не продаются, официальной поддержки нет, каналы обновлений могут быть заблокированы и т.п. Бизнес, как правило, идет туда, где выгоднее.
Loghouse создавался как вынужденная времянка, потому что подходящего для нас решения по логам на тот момент не было. Мы создали проект, но планы (ресурсы) по его развитию были весьма скромные. Спустя какое-то время появился мейнстримовый Loki, который закрыл для нас все боли, а своих ресурсов на разработку больше не стало. В итоге перешли на Loki.
На следующей неделе будет статья с реальным кейсом.
Нанимали Google Translate:) Плюс для уточнения разных нюансов перелопатили разные англоязычные и русскоязычные источники, чтобы выверить перевод терминов и т.п. Ну и у Андрея мощный бэкграунд во всем этом.
В статье описывается то, с чем авторы столкнулись на практике во время своего последнего исследования кластеров в интернете. Видимо, не везде свежие версии K8s, и такие проблемы продолжают оставаться проблемами для такой категории кластеров.
В исследовании мы фокусировались на микросервисах (да, Zabbix тоже вливается в историю про микросервисы, но, по нашему опыту, в микросервисном мире его используют реже, чем тот же Prometheus). Поэтому тут он входит в категорию «Другие инструменты».
Что касается пострадавших, то большое обсуждение в CNCF явно показывает, что пострадавших гораздо больше.
Если есть, что сказать по существу, а не вот так рекламно, вы просто напишите:) Это Хабр, тут такая тактика не особо работает.
Причем тут негодяи? Я говорю о рисках для бизнеса. Что касается воровства, то это абсолютно некорректное сравнение — воровством было бы использовать инструмент в нарушение лицензии. А экосистема Open Source устроена так, что ты можешь контрибьютить в одни проекты, а пользоваться результатами других проектов. Те же HashiCorp наверняка используют и Linux, и Kubernetes, и кучу других Open Source-утилит, и далеко не во все из них контрибьютят. Они воры, получается? Конечно же, нет. Никто не отрицает, что есть прям нечистоплотные ребята, которые используют Open Source, не отдавая ничего взамен, но все же эта экосистема дала и продолжает давать миру ИТ удивительные и крутые продукты. А подобные решения вендоров экосистему Open Source потенциально уничтожают. Конечно, выгодно использовать Open Source-решение, которое кто-то сделал за вас когда-то давно, но это не означает, что в итоге такая ситуация, как случилась с hashiCorp не является для компании риском. Это вроде бы прям элементарные штуки — речь не о плохих и хороших, а о том, что прямо сейчас для бизнеса, который полагался на какой-то из Open Source-продуктов (и полагался вполне законно), кардинально меняются условия существования. Это риск? Ну, однозначно риск. Очень странно было бы это отрицать.
Всё так, только вы говорите о конечном результате, а не о ситуации, когда проблема приключилась и вам надо собрать сообщество, договориться с другими компаниями, которые хотят участвовать в проекте, изучить код, нанять инженеров, которые будут поддерживать и развивать решение с вашей стороны, ввалиться в R&D и т.п. И если всё это получится вывезти, тогда через пару-тройку лет можно уже будет говорить о каких-то профитах. Но и то будет проблема — теперь на то же решение вы тратите на порядки больше сил и денег. И не всегда это оправданная цена за полученную от решения выгоду. А теперь еще представьте ситуацию, когда автор не бросает проект, а ставит на него ограничения — в этом случае еще и подавляющая часть сообщества может остаться с прежним, уже ограниченным, решением и считать, что для них ничего не поменялось. В такой ситуации собирать сообщество и искать партнеров, с которыми можно будет вместе вваливаться в разработку и поддержание будущего форка, станет еще сложнее.
Кстати, появились некоторые подробности про последствия для всей экосистемы — добавили Upd в конце статьи специально об этом, дублирую тут в комментарии:) Показалось, что вам может быть интересно в контексте диалога.
В Cloud Native Computing Foundation уже начались подробные исследования того, как изменение лицензии на продукты и компоненты продуктов HashiCorp скажутся в том числе и на открытых проектах CNCF. Проблема в том, что можно импортировать в свой проект небольшой фрагмент продукта компании как библиотеку и даже не особо догадываться, что там сменилась лицензия. Например, есть пакет vault/api, который используют все, кто интегрируется с Vault. Лицензия на него тоже поменялась на BSL — и вот где его обнаружили. То есть хотя HashiCorp сказали, что SDK, API и библиотеки останутся под MPL, в реальности это не совсем так — потому что отдельные компоненты их продуктов лицензию в итоге сменили. Да, не все такие проекты CNCF являются конкурирующими по отношению к продуктам HashiCorp, но у Open Source-проектов есть и требования к совместимости лицензий отдельных компонентов. То есть изменения лицензий HashiCorp потенциально способно повлиять на очень большое количество свободных проектов от сообщества. В общем, еще один скользкий момент:)
Есть ещё BSD, которая разрешает делать с производным кодом все что угодно (типа тотальная свобода), хоть лицензировать его под EULA какой-нибудь:)
Стратегии же в бизнесе выстраиваются не исключительно на самых плохих сценариях и рисках. Иначе никто бы бизнесом не занимался. А на разумном прогнозировании этих сценариев и умеренно-оптимистичных прогнозах. Такова реальность. Без надежды на что-то хорошее или на то, что риск может не сбыться, бизнес вообще не построить.
Ну вы же сами и описали все риски:) То, что с ними можно попробовать справиться каким-то образом, не означает, что они рисками не являются. И то, что позиционируются себя как Open Source-вендор на протяжении десятка лет компания вдруг в один день принимает такое решение — это очень серьезное событие в жизни компании, которая ее продуктами пользуется. А между плывите сами дальше (я устал поддерживать проект) и «а теперь это больше не Open Source, платите,» все же есть очень большая разница. И второй сценарий гораздо более неприятен с точки зрения попытки поддержки и развития отдельной Open Source-ветки.