Я недавно погрузился в область наведения комфорта в квартире, переосмыслил свой личный опыт с новыми знаниями, и вот что получается:
1. чаще всего в помещениях банально переизбыток СО2, по всяким исследованиям и СНИПам надо не более 800ppm всё же
2. некомфортно, когда на тебя дует (скорость потока большая), а должно быть не более 0.4 м/с
3. и когда дует холодным (дует воздухом, который существенно холоднее), один градус разницы уже заметен
И ведь все три пункта можно решить, только это дорого, а если пытаться минимизировать шум работы всей системы — то очень дорого.
Всё же сведение всего к пружине — это немного трололо )
Мне больше нравится такой вид формулы:
E/M ≤ σ/ρ
E ≤ σ * M /ρ
E ≤ σ * V
То есть энергия ограничена прочностью межатомных связей. Что идеологически очень хорошо совпадает с предыдущей частью, где энергия тех же самых межатомных связей высвобождалась вследствие химических реакций.
Автор хочет сказать, что транспорт для доставки логов должен быть частью инфраструктуры системы запуска контейнеров, а не находиться ВНУТРИ контейнера.
Пример с фолли был гиперболой для рабочей ситуации какой-то компании, код которой хранится в наборе гит реп в модном корпоративном гитхабе, битбакете или ещё как либо, сама фолли же — та самая библиотека С, которую вы меинтейните, внесли туда свои изменения и хотите, чтобы они до всех доехали. Для этого можно
не делать ничего, через какое-то время это приведёт к тому, что попросят сделать хотфикс, причём в старой версии — потому что текущая слишком далеко убежала вперёд, а баг вот сейчас и откат на предыдущую версию не поможет
найти всех пользователей и сделать PR в их код/сборочные зависимости, чтобы они перешли на новую версию, а для этого надо найти всех, кто это библиотеку использует
Монорепа очевидно не позволяет выбрать первый вариант, и существенно облегчает второй. Надеюсь, теперь пример стал понятен?
Т.е. всех проектов использующих библиотеку фейсбука, я верно понимаю?
Конечно. Всех, что разрабатываются в вашей компании.
Да что вы заладили со своим хеллом, это не самое частое явление. Вот я беру ваш же пример — есть линукс, есть folly, есть gcc как инструмнт сборки, есть буст, есть миллиард приложений написаных с их использованием.
Ага, и ещё замечательная пара пакетов libcurl4-gnutls-dev и libcurl4-openssl-dev, которые «инфицируют» дерево зависимостей — если хотя бы в одном месте слинковались с libcurl4-openssl-dev, то все-все-все остальные библиотеки в рамках этого бинарника ни в коем случае не должны быть слинкованы с libcurl4-gnutls-dev. Это то, что сходу в голову пришло. Для обновления gcc надо пересобрать ВСЁ, т.к. библиотеки становятся бинарно несовместимыми. Все живут конечно, пока маленькие, как только появляется несколько десятков библиотек с активной разработкой, так появляются проблемы с взаимной совместимостью, завязками на минорные версии и т.д.
Да вполне — если ваша контора не готова выделить отдельную команду чтобы писать для себя системы сборки, версионирования, индексации и прочий тулинг — то монорепа не нужна.
Но не обязательно писать свой — можно взять Bazel, как это сделали Dropbox, Uber и SpaceX.
Но если просто поменять код — то и в полирепе сделайте то же самое. Выкачайте 100500 репозиториев и поменяйте все места. Затем запушьте. В чем проблема?
А как вы их найдёте то? Сможете найти на гитхабе, например, всех пользователей folly?
Вы владеете кодом всех проектов в кашей компании? Тестировать, ревьюить, выкатывать, иметь ролбек план, делать все эти ваши сини-зеленые развертывания не надо? Странно слышать от руководителя яндекса что обновление — это «поменять код». Поменять код это дай бог треть работы всей. Код еще надо проревьюить, оттестировать, выкатить, мигрировать данные и т.п. Не говоря уже про то, что у вас не будет владения кодом для всех 100500 проектов. А значит — «надо заменеджить каждую команду обновить свой код на новую версию». Только одновременно.
Представьте себе, что это минорное изменение, которое не требует изменения кода. Тестирование и деплой в любом случае выполняются в соответствии с релизным циклом каждого компонента. Зато вы хотя бы получите автоматический запуск тестов для всех зависимых проектов и увидите, что своим изменением вы ничего не сломали.
А зачем? Это делается откатом нововыкаченного сервиса. Одного, а не 100500 который вы обновили. А если вы чините багу в библиотеке в то время как лежит ваш сервис на проде, то вы либо ждете пока ваш хотфикс затестят, либо имеете нехилый шанс положить остальные 100499 сервисов.
И да, в рассматриваемом примере как раз таки монорепа мешает.
Это если баг свежий, если он там 5 лет живёт и начал триггериться только сейчас, как это было с високосной секундой в ядре linux, например — то откатываться некуда.
Я сталкивался. И когда в гугловом подразделении работал, и на прошлом месте работы в дойче банке (это если что, к вашему замечанию, что дескать в яндексе действительно большие проекты, а у остальных по 20 человек).
Ок, я слишком уж обобщил, не все, а большинство.
Но для полиреп эти все проблемы хорошо известны, решаемы, есть куча готовых хорошо оттестированных инструментов.
Если бы для полиреп это были решенные проблемы — то dependency hell бы не существовало.
И собственно монорепы используют в основном компании, которые пишут свои велосипеды для всего, включая большую часть инструментов разработки.
Факт. Но он не подтверждает утверждение, что не надо использовать монорепы.
Да всё по классике: свой тулинг, тяжело с контрибами жить, статическая линковка, не гит (хотя это решаемый вопрос, в MS вот зафиксили же).
Плюсы: статическая линковка, воспроизводимость сборок (вот это очень хорошее свойство), нормальный поиск и возможность глобального рефакторинга, отсутствие ада зависимостей от минорных версий. Пожалуй, сюда же можно написать и тулинг: CI/CD получаешь бесплатно.
В общем, для плюсов/го/раста/etc работает относительно неплохо, для питона так себе, для ноды вообще всё сложно. Базел не пробовал, так что про него особо ничего сказать не могу. В гугле/фб не работал, а на предыдущем месте монорепа была для одного большого монопроекта, там вариантов не было особо.
Я повторю еще раз вопрос — 1. почему два проекта A и B будут обновляться дольше, чем стопицот проектов из полирепы.
Потому что в монорепе обновление — это вопрос технический, надо взять и поменять в 100500 местах код, а в полирепах — административный, надо заменеджить каждую команду обновить свой код на новую версию, и пока они не обновятся — поддерживать 2, 3 мажорных версии и чинить в них баги параллельно. Вы же не можете самовольно решить, что не будете чинить баги в библиотеке, из-за которой вот сейчас лежит прод, правда?
2. Как относится резолв зависимостей и прочие депенденси хеллы к системе контроля версий.
В случае монорепы всё это не нужно, т.к. именно сборка делается из транка. Я подразумеваю, что монорепа == trunk based development.
Безусловно, это не решение всех проблем, но тут уже вторую статью все в комментариях говорят, что монорепа — это адище, а от большого количества реп волосы становятся мягкими и шелковистыми, при этом с проблемами полиреп в проектах с большим количеством команд не сталкивались. Вот всё далеко не так просто, и гугл/фб/яндекс/мс не от хорошей жизни на монорепах сидят.
А клиенты A, B, ...Z будут переходить уже по мере надобности и сил.
К сожалению, это означает «никогда», и срочное обновление из-за какого нибудь бага будет ооооочень болезненным. Да ещё и поддерживать старые мажорные версии придётся годами, потому что у всех планы, продакшен сломается и т.д. Это из собственного опыта, если что.
Разработчику А ничего не надо, С вообще развивается другими людьми. И вот это проблема: они то библиотеку развивают, но ни разработчики А, ни разработчики B обычно такие изменения не сильно прям хотят, им базовых фичей хватает с головой. И они ни в варианте с монорепой, ни в варианте с полирепами ничего обновлять не хотят и, следовательно, не обновляют. В варианте с монорепой в итоге за совместимостью и обновлениями голова болит у разработчиков C, а вот при полирепах только административными мерами.
Внезапно, про боль и проблемы полиреп и монореп я знаю не понаслышке как раз по опыту работы в Яндексе :) Так что я знаю, что тут происходит, и какие проблемы есть у действительно больших проектов, а не в репах на пару десятков человек.
Альтернатива — в полирепах в принципе нету возможности ограничить использование старых версий. Я видел как варианты с использованием собранных артефактов (deb-пакеты, так уж сложилось, что я в основном касался мира c++ разработки под linux), так и сложные конструкции c git submodules. Во всех этих случаях всё заканчивалось тем, что все в итоге забивают на обновление какой либо библиотеки, количество изменений постепенно растёт, и потом обновление, связанное с каким нибудь security фиксом становится невероятной болью.
И нет, невозможно все эти библиотеки превратить в микросервисы, т.к. это банально медленно. Локальный вызов стоит сотни микросекунд, сетевой — единицы миллисекунд, как минимум, а 99 процентиль — десятки и сотни миллисекунд, + он всегда может не уложиться в таймаут для конкретного запроса.
Очевидно, A и B в этом случае просто физически не могут зависеть от разных версий C, ведь C может существовать в репозитории только в одной версии в каждый момент времени, и такой проблемы не существует.
А заодно существенно ухудшили качество распознавания, ведь в оригинальной колонке не просто так несколько микрофонов. Они пытаются формировать «луч», улучшая таким образом показатель сигнал/шум.
Фуры не нужны, ведь всё можно перевезти в багажнике легковушки, просто их понадобится много.
А по делу — основным минусом полирепозиториев является невозможность быстро обновиться. В худшем же случае в какой-то момент невозможно использовать одновременно библиотеки A и B, потому что они обе зависят от библиотеки C, только разных версий, и конечно же в итоговой программе такой зоопарк не соберётся.
Я сам вообще не далеко не фанат монореп, но говорить о том, что набор независимых репозиториев существенно лучше — это самообман. И чем больше команд, тем больнее кушать этот кактус.
При старте с двух педалей и окончании пробуксовки (если вдруг такая будет) идут ударные нагрузки на тормоза фрикционов. Если по лайту стартовать, то конечно ничего не будет.
1. чаще всего в помещениях банально переизбыток СО2, по всяким исследованиям и СНИПам надо не более 800ppm всё же
2. некомфортно, когда на тебя дует (скорость потока большая), а должно быть не более 0.4 м/с
3. и когда дует холодным (дует воздухом, который существенно холоднее), один градус разницы уже заметен
И ведь все три пункта можно решить, только это дорого, а если пытаться минимизировать шум работы всей системы — то очень дорого.
Мне больше нравится такой вид формулы:
E/M ≤ σ/ρ
E ≤ σ * M /ρ
E ≤ σ * V
То есть энергия ограничена прочностью межатомных связей. Что идеологически очень хорошо совпадает с предыдущей частью, где энергия тех же самых межатомных связей высвобождалась вследствие химических реакций.
Имхо, все самые офигенные штуки/проекты появляются именно по этому принципу.
Монорепа очевидно не позволяет выбрать первый вариант, и существенно облегчает второй. Надеюсь, теперь пример стал понятен?
Конечно. Всех, что разрабатываются в вашей компании.
Ага, и ещё замечательная пара пакетов libcurl4-gnutls-dev и libcurl4-openssl-dev, которые «инфицируют» дерево зависимостей — если хотя бы в одном месте слинковались с libcurl4-openssl-dev, то все-все-все остальные библиотеки в рамках этого бинарника ни в коем случае не должны быть слинкованы с libcurl4-gnutls-dev. Это то, что сходу в голову пришло. Для обновления gcc надо пересобрать ВСЁ, т.к. библиотеки становятся бинарно несовместимыми. Все живут конечно, пока маленькие, как только появляется несколько десятков библиотек с активной разработкой, так появляются проблемы с взаимной совместимостью, завязками на минорные версии и т.д.
Но не обязательно писать свой — можно взять Bazel, как это сделали Dropbox, Uber и SpaceX.
А как вы их найдёте то? Сможете найти на гитхабе, например, всех пользователей folly?
Представьте себе, что это минорное изменение, которое не требует изменения кода. Тестирование и деплой в любом случае выполняются в соответствии с релизным циклом каждого компонента. Зато вы хотя бы получите автоматический запуск тестов для всех зависимых проектов и увидите, что своим изменением вы ничего не сломали.
Это если баг свежий, если он там 5 лет живёт и начал триггериться только сейчас, как это было с високосной секундой в ядре linux, например — то откатываться некуда.
Ок, я слишком уж обобщил, не все, а большинство.
Если бы для полиреп это были решенные проблемы — то dependency hell бы не существовало.
Факт. Но он не подтверждает утверждение, что не надо использовать монорепы.
Плюсы: статическая линковка, воспроизводимость сборок (вот это очень хорошее свойство), нормальный поиск и возможность глобального рефакторинга, отсутствие ада зависимостей от минорных версий. Пожалуй, сюда же можно написать и тулинг: CI/CD получаешь бесплатно.
В общем, для плюсов/го/раста/etc работает относительно неплохо, для питона так себе, для ноды вообще всё сложно. Базел не пробовал, так что про него особо ничего сказать не могу. В гугле/фб не работал, а на предыдущем месте монорепа была для одного большого монопроекта, там вариантов не было особо.
Потому что в монорепе обновление — это вопрос технический, надо взять и поменять в 100500 местах код, а в полирепах — административный, надо заменеджить каждую команду обновить свой код на новую версию, и пока они не обновятся — поддерживать 2, 3 мажорных версии и чинить в них баги параллельно. Вы же не можете самовольно решить, что не будете чинить баги в библиотеке, из-за которой вот сейчас лежит прод, правда?
В случае монорепы всё это не нужно, т.к. именно сборка делается из транка. Я подразумеваю, что монорепа == trunk based development.
Безусловно, это не решение всех проблем, но тут уже вторую статью все в комментариях говорят, что монорепа — это адище, а от большого количества реп волосы становятся мягкими и шелковистыми, при этом с проблемами полиреп в проектах с большим количеством команд не сталкивались. Вот всё далеко не так просто, и гугл/фб/яндекс/мс не от хорошей жизни на монорепах сидят.
К сожалению, это означает «никогда», и срочное обновление из-за какого нибудь бага будет ооооочень болезненным. Да ещё и поддерживать старые мажорные версии придётся годами, потому что у всех планы, продакшен сломается и т.д. Это из собственного опыта, если что.
Внезапно, про боль и проблемы полиреп и монореп я знаю не понаслышке как раз по опыту работы в Яндексе :) Так что я знаю, что тут происходит, и какие проблемы есть у действительно больших проектов, а не в репах на пару десятков человек.
И нет, невозможно все эти библиотеки превратить в микросервисы, т.к. это банально медленно. Локальный вызов стоит сотни микросекунд, сетевой — единицы миллисекунд, как минимум, а 99 процентиль — десятки и сотни миллисекунд, + он всегда может не уложиться в таймаут для конкретного запроса.
А по делу — основным минусом полирепозиториев является невозможность быстро обновиться. В худшем же случае в какой-то момент невозможно использовать одновременно библиотеки A и B, потому что они обе зависят от библиотеки C, только разных версий, и конечно же в итоговой программе такой зоопарк не соберётся.
Я сам вообще не далеко не фанат монореп, но говорить о том, что набор независимых репозиториев существенно лучше — это самообман. И чем больше команд, тем больнее кушать этот кактус.