Comments 31
Почему многие разумные разработчики не хотят подсаживается на самописные решения? Понимают что время, потраченое на освоение vendor lock-in не окупится при смене работы. А рост внутри одной компании чаще зависит не от профессиональных навыков...
На каком-то этапе это все перестает иметь значение. По крайней мере решающее значение.
На самом деле время, нужное для onboarding-а нового разработчика Яндекса на самописные инструменты, не столь большое (если судить по данным опросов). Это достигается с одной стороны благодаря тому, что инструмент может выглядеть похожим на общедоступные альтернативы, например, Arc. А с другой стороны упростить onboarding помогают хорошие курсы про эти инструменты.
А ещё часть этих инструментов вполне себе становится частью Open Source со временем, см. ClickHouse, YDB, YTSaurus.
то достигается с одной стороны благодаря тому, что инструмент может выглядеть похожим на общедоступные альтернативы
И порождает потом из-за похожести gotcha... Когда в общедоступный инструмент действует по другому в некоторых случаях.
ClickHouse классный нишевый инструмент для веб аналитики, честно был приятно удивлен, когда покопался в инструментарии и я даже добавил его поддержку в SchemaSpy. Но, даже для задач поведенческой аналитики ему еще как минимум "State machine user defined function support" не хватает, что в PostgreSQL делается легко. Быстрый, но не полнофункциональный, с ограничениями из-за компромиссов с его структурами данных в памяти и на диске и его архитектурой.
Передача YDB и YTSaurus в Open Souce похожа на попытку спасения и отчуждения от компании технологий перед ее разделением. Пользовательская база значительно меньше чем у CH.
И порождает потом из-за похожести gotcha... Когда в общедоступный инструмент действует по другому в некоторых случаях.
Идеальных решений не бывает.
Передача YDB и YTSaurus в Open Souce похожа на попытку спасения и отчуждения от компании технологий перед ее разделением. Пользовательская база значительно меньше чем у CH.
Стоит посмотреть на хронологию YDB, CH и YTSaurus, adoption любого нового продукта это сложная задача.
Идеальных решений не бывает.
adoption любого нового продукта это сложная задача.
В итоге, вместо доведения "до ума" main stream Open Source проектов наплодили в компании самописных решений. Выбивающимся из этого корпоративного развлечения в Яндексе пока только можно назвать позитивный опыт коллег с PostgreSQL и ClickHouse. Хорошо что есть на планете эти действительно полезные всему сообществу люди!
Вторая часть Марлезонского балета наступила, когда СТО Yandex Platform Engineering пишет статью, что "самописные решения" это OK. Видимо для убеждения тех кто сомневается стоит ли инвестировать свое время в изучение этого зоопарка фреймворков и технологий. Чтобы потом:
Вы так акцентируетесь на IPv6, можете подсказать почему?
Почему инфраструктура big tech обычно состоит из самописных решений?
- Потому что они могут себе это позволить.
- Потому что у них очень специфические потребности.
История #2: монорепозиторий
Крайне слабо верится, честно сказать, что это действительно здравое решение. В основном потому, что основной подход построения сложных IT-систем это всё-таки декомпозиция, уровни (стэки) абстракций и всё такое прочее — инкапсуляция, мать её. Моно — скорее анти-шаблон. Разработчик поправил CSS, и этот коммит виден разработчику backend'а, а то и SRE? А если не виден, то почему это не могут быть просто git submodules, набор которых будет различен для каждого проекта, и вовсе не каждому второму потребуется использовать даже треть всех имеющихся — у вас там же не full mesh, верно?
И да, fuse это отдельная песня, особенно на macOS.
Крайне слабо верится, честно сказать, что это действительно здравое решение.
Мы делились какое-то время назад аргументацией почему для нас монорепозиторий полезен. Кроме того стоит посмотреть на статью advantages and disadvantages of a monolithic repository: a case study at google.
Если коротко - то основные плюсы для нас заключаются в стандартизации и переиспользовании кода.
И да, fuse это отдельная песня, особенно на macOS.
Да, с macOS и fuse ситуация не самая приятная, но текущее решение удовлетворяет наши потребности.
А чем git submodules для «переиспользование кода» не годятся? )
Для переиспользования кода - годятся, для поддержки большого репозитория в который коммитят тысячи разработчиков - так себе. Вы пробовали разрабатывать и резолвить конфликты в репозитории где есть несколько сабмодулей? Я даже когда один разрабатывал в репозитории с сабмодулями постоянно натыкался на грабли. Может конечно я просто не разобрался и на самом деле всё очень просто и легко (или с тех пор как я пробовал стало сильно лучше), было бы интересно ваш опыт узнать.
для поддержки большого репозитория в который коммитят тысячи разработчиков - так себе
Что? Откуда снова берётся «большой репозиторий», если есть саб-модули? Какая разница сколько разработчиков туда коммитит? Вас не смущает, что тот же Github используют миллионы, а там вовсе не монорепа? )
если что, вон веточка выше, всё прекрасно иллюстрирует. Это и правда NIH-синдром, всё остальное — от лукавого. Зато с митапами и слайдиками.
Что? Откуда снова берётся «большой репозиторий», если есть саб-модули?
Объясняю - сабмодули - это способ организовать иерархию мелких репозиториев и объединить их в один.
Вас не смущает, что тот же Github используют миллионы, а там вовсе не монорепа? )
Для жизни в гитхабе никаких сабмодулей не нужно, но там и уровень переиспользования кода так себе.
Ещё раз спрошу - а вы пробовали пользоваться сабмодулями или нет?
У вас какой вопрос был, почему сабмодули не подошли, или зачем нужен монорепозиторий?
Я пытался сказать что для организации монорепозитория сабмодули - плохое решение. А без монорепозитория зачем вы предлагаете сабмодули мне неясно.
Если вопрос в том зачем вообще нужен монорепозиторий то это совсем другой вопрос, я на него не пытался ответить, боюсь что для ответа на него нужна целая статья, возможно даже на хабре уже есть такая.
Почитал с чего все началось - понял что отвечал не на тот вопрос. Если что сабмодули сами по себе не решают практически ни одной проблемы, которую решает монорепозиторий. Можете почитать слайды с доклада выше, там в целом есть основная аргументация. И да, пользоваться сабмодулями для организации зависимостей если они часто меняются и надо менять зависимости паралельно с основным кодом - очень неудобно.
что характерно, много слов и не одного примера, зато не очень чёткая отсылка на саб-модуль ^W слайды, которые мне можно (спасибо!!!11) почитать, и которые я уже почитал. Не нашёл там ничего про то, как не подойдёт разделение при помощи саб-модулей. На какой странице искать-то, ну…
Для примера страница 14, хотелось бы услышать как сабмодули помогут в решении проблемы
Be on the cutting age of your dependencies while being sure there are no unexpected breaking changes
так же (не-/) помогут как и моно-репа. Серьёзно, в чем отличие? Вытаскивайте свежак, гоняйте юнит-тесты. В чём в сим аспекте принципиальное отличие-то, что это не один репозиторий? ))
Если это был ваш основной довод, блин, то это лишь чёткое подтверждение тезиса NIH-синдрома.
так же (не-/) помогут как и моно-репа. Серьёзно, в чем отличие?
Вытаскивайте свежак, гоняйте юнит-тесты. В чём в сим аспекте
принципиальное отличие-то, что это не один репозиторий? ))
Нет, в монорепе не надо ничего "вытаскивать", при изменении зависимостей сразу видно, какие потребители затронуты.
Зависимости тут если что - это внутренние общие библиотеки, а не внешнее что-то.
Если это был ваш основной довод, блин, то это лишь чёткое подтверждение тезиса NIH-синдрома.
Нет, это не мой "основной довод", просто если несколько аргументов привести то дискуссия уйдет куда-то не туда.
Нет, в монорепе не надо ничего "вытаскивать", при изменении зависимостей сразу видно, какие потребители затронуты.
Кому видно, где видно, как видно? Вот у нас есть большая git-репа (моно!), с кучей каталогов, одни люди клепают /mono/some/foo/bar, другие вообще /mono/something/else, при том, что последняя #include-юзает файло из этого самого bar/, и его недавно поменяли — и кому тут видно, кого затронула последняя правка этого файла? Первым? — Как? — Как? grep'ом? по всей моно-репе? На fuse? — лол! Вторым? Они давно забыли, про этот include… В случае с submodule у них хотя бы чё-то пикнуло при git pull'е.
Другой пример, это несколько git-реп, часть из которых юзает другие через git-submodules, ответ на вопрос какие именно репы юзаются (через submodules) тривиален. Зато иерархия меняется легко и просто, она не задана каким-то одним способом, что добавляет гибкости, которой в случае с моно-репой просто нет.
И ровно так же можно провернуть обратное — привязку к определённой версии «сторонней»-репы если свежие правки там оказались проблемными. Можно хоть так, хоть сяк.
Вот у нас есть большая git-репа (моно!), с кучей каталогов, одни люди клепают /mono/some/foo/bar, другие вообще /mono/something/else, при том, что последняя #include-юзает файло из этого самого bar/, и его недавно
поменяли — и кому тут видно, кого затронула последняя правка этого файла? Первым? — Как? — Как? grep'ом? по всей моно-репе? На fuse? — лол! Вторым? Они давно забыли, про этот include… В случае с submodule у них
хотя бы чё-то пикнуло при git pull'е.
В случае монорепозитория при изменении в /mono/some/foo/bar прогонится сборка else и если там были изменения которые поломали компиляцию или тесты /mono/something/else - такое изменение не будет вкоммичено, пока не поправят компиляцию и тесты. А если тесты прошли, то else получит свежую версию foo/bar автоматически.
В случае сабмодулей автору else надо
каким-то образом узнать про изменения в foo/bar
обновить версию самостоятельно, а у него дедлайн по своему проекту и конечно не до обновления каких-то библиотек
он может быть несогласен с изменениями в foo/bar и мог бы предложить какое-то альтернативное решение
проектов else несколько штук, каждый из которых должен пройти пункты 1-3
Другой пример, это несколько git-реп, часть из которых юзает другие через git-submodules, ответ на вопрос какие именно репы юзаются (через submodules) тривиален. Зато иерархия меняется легко и просто, она не задана каким-то одним способом, что добавляет гибкости, которой в случае с моно-репой просто нет.
Когда у тебя много проектов - гибкость становится из преимущества проклятием. У разных проектов свое представление о том какие транзитивные зависимости нужно использовать, какую систему сборки, какую версию компилятора, на каком языке писать. Любое изменение может привести к тому что те кто твой код используют решат что им выгоднее поддерживать форк, чем следовать втоим изменениям.
И ровно так же можно провернуть обратное — привязку к определённой версии «сторонней»-репы если свежие правки там оказались проблемными. Можно хоть так, хоть сяк.
И это приведет к тому что вместо исправления в "сторонней" репе люди будут жить на старой версии, потом вообще форкнут её и будут жить на форке, где тут "переиспользование кода"?
о-да, поняяяятно. Когда моно — автоматика такая, что аж на этапе коммита в одном месте билды по всему fuse-богатству идут, а вот если git-саб-модули, то строго ручной привод. На этом дискуссию считаю удавшейся и законченной — NIH-синдром хоть и неявно доказан, но отчётливо проглядывается.
Когда моно — автоматика такая, что аж на этапе коммита в одном месте билды по всему fuse-богатству идут, а вот если git-саб-модули, то строго ручной привод.
Есть реальный опыт автоматизации большого количества проектов на сабмодулях? Так чтобы проверки во всех зависимых модулях прогонялись автоматически, чтобы можно было поправить зависимый модуль если в нём начали падать тесты или компиляция? Я с самого начала просил про него рассказать.
Мой опыт работы с сабмодулями говорит что работать с ними неудобно даже когда есть всего один сабмодуль и надо внести синхронно изменения в проект и в его зависимость.
Опять же из моего опыта работы с отдельными git-репозиториями (не с сабмодулями, а просто без монорепозитория) - было два проекта, один добавил себе зависимость из второго, а второй из первого, в итоге после обновления одного из них до актуальной версии получилась циклическая зависимость - это просто следствие гибкости и отсутсвия проверок на всём стеке зависимостей.
Ну и по прежнему непонятно, что делать когда зависимость решает поменять систему сборки, начать писать на другом языке или воспользоваться новым таким стандартом языка, который в зависимых проектах не поддерживается, а раз мы топим за максимальную гибкость - такие случаи 100% будут.
Если что я не считаю что монорепозиторий - единственно верный подход, у меня есть перед глазами примеры плохих монорепозиториев. Просто те проблемы что решает монорепозиторий сабмодулями не решаются совсем никак.
Почему инфраструктура big tech обычно состоит из самописных решений?
Потому что это - конкурентное преимущество.
Кажется, что это созвучно с "инновациями". Только формулировка "инновации" попахивает "инновациями ради инноваций". Имхо, свой тулинг, которого пока ни у кого нет, или который адаптируется под нужны компании быстро и лучшим образом - это чуть ли не одно из самых важных конкурентных преимуществ, которое даёт некоторым компаниям возможность быть на шаг впереди.
Пока остальные адаптируются, мигрируют, ждут реализации фич, ждут апрува в апстрим, другие уже выходят на рынок.
P.S. Даже знаю одну такую компанию, которая переходит на bazel несколько лет и уже несколько раз поднимался вопрос, что, вероятно, своё in-house решение могло получиться гораздо быстрее. А самое главное, могло бы поставляться итеративно (т.е. с приростом функциональности во времени поступательно).
Потому что это - конкурентное преимущество.
Согласен, что конкурентное преимущество это лучший термин, чем инновация.
P.S. Даже знаю одну такую компанию, которая переходит на bazel несколько лет и уже несколько раз поднимался вопрос, что, вероятно, своё in-house решение могло получиться гораздо быстрее. А самое главное, могло бы поставляться итеративно (т.е. с приростом функциональности во времени поступательно).
Ровно такой же опыт был с hg. Поэтому появился arc.
Немного обобщу:
Готовые решения не способны поддержать специфических нужд.
Вообще это встречается везде и всюду, но значительный эффект появляется только на масштабе.
Пример на коленке - захотелось мне прикинуться репликой mysql на rust. Нашлась готовая библиотека, на первый взгляд работает, guid поддерживает - все хорошо.
Начинаешь копаться - библиотека парсит каждое событие во внутреннюю структуру. И событий там много (всякие health-check в 90% случаев). А мне оно вот вовсе не нужно, мне достаточно create/update/delete. Вот и получается, что библиотека в 90% случаев занимается чем-то для меня бесполезным. Хочешь производительности - пиши своё (в данном случае хотя бы делай пулл-реквест).
Пока можно не экономить на таких мелочах - почему бы и нет. Если вдруг придется разворачивать кластер на 1000 машин (что и случается в больших компаниях) - экономия на этих 90% бесполезных событий может стоит 5-10 загруженных ядер.
И это не библиотека плохая. Просто она универсальна и предоставляет максимально полное решение, которое подойдет большинству.
проблема в том что если ты как минимум не яндекс, то лучше в самописное не лезть, не вывезешь. И то что должно было стать преимуществом, станет самописным 20-ти летним легаси висящим аки гиря на ногах
Почему инфраструктура big tech обычно состоит из самописных решений