Так и есть, но отчасти. Их проблема, что они пытаются на двух стульях усидеть. Часть их контента смихуечки. Часть - полноценные серьезные обзоры новых продуктов. За последние их и пинают сейчас.
Именно. Он делает тонны контента, но сомнительного качества. Это не только слова gamer nexus, которые в индустрии является наверное лидерами в плане качества и точности тестов. Это слова и сотрудников LTT, которые жалуются на слишком высокий темп публикации видео, из-за чего страдает качество.
И вот только сейчас, обосравшись несколько раз, они наконец-то сняли это видео с извинениями и приступили к работе над внутренними процессами. Линуса даже собственная жена под поезд кинула в этом видео
Если отдельный модули исполняются на разных машинах, то это, по определению, уже не монолит. Монолит это именно что огромный клубок кода, который компилится хер знает сколько. Это все естественно разбито на модули, библиотеки. Используются билд кэши и прочие оптимизации, чтобы инкрементальный билд в большинстве случаев эту проблему сгладил, если у нас компилируемый язык какой-то. Но по итогу это все равно огромная пачка бинарей, которая деплоится и запускается целиком на одной машине.
Разработка именно что отличается кардинально между этими подходами. Именно по этой причине во многом микросервисы рождаются из масштабов не только приложения, но и команды.
Так что это у вас скорее какие-то странные понятия монолита и микросервисов.
Современные ОС и так, по сути, микросервисные. Кругом службы, которые переплетены между собой IPC механизмами. Уж какие-нить macOS и iOS точно. Там на mach ports и всяческих надстройках над ними вроде XPC держится буквально все.
Можно Кэмерона послушать. Специалистам катастрофа была очевидна. Проект изначально был нерабочим и не реализуемым, а чтобы протолкнуть его побыстрее в прод они проигнорировали все проверки и сертификации. Это называется жулики. Техническая грамотность как раз там была на дне.
Батискаф нормально функционировал, погружавшись к Титанику 15 раз.
В этом вся и беда материала их корпуса. В отличии от металла, он медленно разрушается и в один прекрасный момент просто схлопывается. Именно так и произошло, а их акустические датчики полная ерунда. В их аппарате именно что были критически дефекты, которые и привели к катастрофе. Стоял лишь вопрос "когда"
И ради чего все эти подробности? Замечательно, что мы тут с вами прекрасно разбираемся, как все работает внутри, только это не имеет ни малейшего отношения к сабжу.
Статья про кафку, которая работает на уровне абстракции TCP сокета. Приложению абсолютно плевать что и как там на физическом уровне, хоть там голубиной почтой пакеты идут через несколько континентов. На уровне приложения все так, как я написал - как байты были посланы, так они и придут. Все, на этом можно поставить точку. И именно поэтому первый кейс в статье лютый бред, который можно натянуть только на кейс с несколькими TCP сокетами. Опять же, клиенты по-моему так не делают. Они открывают один сокет до каждого брокера.
Должно и гарантируется. Если рассматривать кейс с одним соединением, на первой картинке нарисован полный бред. Неважно совершенно какими маршрутами полетят пакеты. Стэк их в любом случае соберет в том порядке, в котором они были посланы.
С точки зрения клиента гарантия все равно сохраняется - как байты были посланы, так они и придут. Поэтому на первой картинке с разными маршрутами пакетов нарисована полная глупость. Она работает только если до одного брокера открывается несколько соединений, что помоему клиенты кафки не делают
Это уже другой вопрос вообще. Я писал конкретно про "Никогда не встречал ситуации, где количество микросервисов превышает количество разработчиков". В этом ничего плохого я не вижу, и какие лучшие практики микросервисной архитектуры это нарушает тоже.
А то, что вы описываете, конечно ничего в этом плохого нет. Модульный монолит нынче модная штука. Лучше или хуже это микросервисов зависит от конкретного кейса.
Наш техдир принял решение сбросить всю ответственность с себя тактически отступить и сказал: «делайте как хотите, я ни хрена не понимаю».
Вот где-то здесь все и пошло не так. Техдир, по сути, должен был выступать тем самым техлидом, который бы установил четкие для всех правила и взял на себя ответственность за них. Но ок, он с этим не разбирается (тогда спрашивается, а какой это нафиг техдир, ну да ладно). Значит эту задачу должен был взять следующий по цепочке - тимлид. Споры и обсуждения это хорошо и полезно, архитекторы должны вовлекать других в подобных большие вопросы, но в конечном итоге надо в какой-то момент твердо сказать - делаем так то так то потому то потому то.
Предварительно менеджер и техдир (и тимлид, раз он тут архитектор главный стал) таки должны были обрисовать план, зачем это бизнесу надо. Какие конкретно метрики это улучшит. Нужно ли реально было все переделывать или достаточно было рефакторинга и подумать немного про архитектуру.
Ну и конечно же, монолиты, в зависимости конечно от размера, обычно "душат". Отколупливают изолированный функционал в новые сервисы, а новый функционал сразу пишут в отдельных сервисах. Иначе "бэкэнд 2.0" может никогда так и не уйти в продакшен.
МС это все же не столько про распределение работы между командами. Это тоже важно и одно из полезных следствий такой архитектуры, но в первую очередь исходят из доменной специфики. Если какие-то сервисы никаким образом между собой не связаны, но им надо быть раздельными. Иначе получаются такие микромонолиты из не связанной бизнес логики, что тоже можно сказать антипаттерн. Потом людей станет больше и чего с этим делать? Либо вообще не начинать сервисы пилить, либо уж делать их корректно. Самое главное это держать каждый сервис в ответственности одной команды.
Я бы сказал "как из пушки по воробьям" здесь некорректная характеристика. Скорее nginx это менее подходящее решение на сегодня, когда есть лучшие альтернативы. Основные проблемы nginx (по крайне опенсорса его варианта, а не всяческих надстроек и платных решений, которые вокруг него предлагает F5. Там может быть все это решено) происходят из его возраста. У него нет нормального хот релоада, API, service discovery, мониторинга, интеграций. Всех тех фич, которые обычно вкладывают в определение cloud-native. Все это нужно в микросервисных архитектурах, где инфраструктура очень динамично меняется и статичный характер nginx создает много боли. Его так или иначе приходится обкладывать каким-нить control plane'ом, чтобы нормально его интегрировать.
Ну допустим, да. И сколько там будет RPS? 100-200? Это все еще смешные нагрузки и не удивительно, что референс архитектура гитлаба не просит много железа. Они там конечно демократично довольно оценивают потребности на 1к, но все равно сильно много ему не нужно. Десяток другой гигов оперативы, десяток ядер процессора и будет бегать как миленький.
Все конечно сильно зависит от количества билдов еще. Раннеры могут намного больше сожрать, чем весь гитлаб.
Так и есть, но отчасти. Их проблема, что они пытаются на двух стульях усидеть. Часть их контента смихуечки. Часть - полноценные серьезные обзоры новых продуктов. За последние их и пинают сейчас.
Все усугубляется еще тем, что у них далеко не один канал+WAN шоу еще
Именно. Он делает тонны контента, но сомнительного качества. Это не только слова gamer nexus, которые в индустрии является наверное лидерами в плане качества и точности тестов. Это слова и сотрудников LTT, которые жалуются на слишком высокий темп публикации видео, из-за чего страдает качество.
И вот только сейчас, обосравшись несколько раз, они наконец-то сняли это видео с извинениями и приступили к работе над внутренними процессами. Линуса даже собственная жена под поезд кинула в этом видео
del
Если отдельный модули исполняются на разных машинах, то это, по определению, уже не монолит. Монолит это именно что огромный клубок кода, который компилится хер знает сколько. Это все естественно разбито на модули, библиотеки. Используются билд кэши и прочие оптимизации, чтобы инкрементальный билд в большинстве случаев эту проблему сгладил, если у нас компилируемый язык какой-то. Но по итогу это все равно огромная пачка бинарей, которая деплоится и запускается целиком на одной машине.
Разработка именно что отличается кардинально между этими подходами. Именно по этой причине во многом микросервисы рождаются из масштабов не только приложения, но и команды.
Так что это у вас скорее какие-то странные понятия монолита и микросервисов.
Современные ОС и так, по сути, микросервисные. Кругом службы, которые переплетены между собой IPC механизмами. Уж какие-нить macOS и iOS точно. Там на mach ports и всяческих надстройках над ними вроде XPC держится буквально все.
Можно Кэмерона послушать. Специалистам катастрофа была очевидна. Проект изначально был нерабочим и не реализуемым, а чтобы протолкнуть его побыстрее в прод они проигнорировали все проверки и сертификации. Это называется жулики. Техническая грамотность как раз там была на дне.
В этом вся и беда материала их корпуса. В отличии от металла, он медленно разрушается и в один прекрасный момент просто схлопывается. Именно так и произошло, а их акустические датчики полная ерунда. В их аппарате именно что были критически дефекты, которые и привели к катастрофе. Стоял лишь вопрос "когда"
И ради чего все эти подробности? Замечательно, что мы тут с вами прекрасно разбираемся, как все работает внутри, только это не имеет ни малейшего отношения к сабжу.
Статья про кафку, которая работает на уровне абстракции TCP сокета. Приложению абсолютно плевать что и как там на физическом уровне, хоть там голубиной почтой пакеты идут через несколько континентов. На уровне приложения все так, как я написал - как байты были посланы, так они и придут. Все, на этом можно поставить точку. И именно поэтому первый кейс в статье лютый бред, который можно натянуть только на кейс с несколькими TCP сокетами. Опять же, клиенты по-моему так не делают. Они открывают один сокет до каждого брокера.
Должно и гарантируется. Если рассматривать кейс с одним соединением, на первой картинке нарисован полный бред. Неважно совершенно какими маршрутами полетят пакеты. Стэк их в любом случае соберет в том порядке, в котором они были посланы.
С точки зрения клиента гарантия все равно сохраняется - как байты были посланы, так они и придут. Поэтому на первой картинке с разными маршрутами пакетов нарисована полная глупость. Она работает только если до одного брокера открывается несколько соединений, что помоему клиенты кафки не делают
Он то есть. Проблема в том, что это ручное действие. Т.е. нужен либо человек, который будет бегать эти сигналы посылать. Либо тот самый control plane.
А в остальном, по всем пунктам именно это я и имел ввиду.
Архитектура приложения и размер команды связаны чуть менее чем никак. Это ортогональные вопросы совершенно.
Это уже другой вопрос вообще. Я писал конкретно про "Никогда не встречал ситуации, где количество микросервисов превышает количество разработчиков". В этом ничего плохого я не вижу, и какие лучшие практики микросервисной архитектуры это нарушает тоже.
А то, что вы описываете, конечно ничего в этом плохого нет. Модульный монолит нынче модная штука. Лучше или хуже это микросервисов зависит от конкретного кейса.
Вот где-то здесь все и пошло не так. Техдир, по сути, должен был выступать тем самым техлидом, который бы установил четкие для всех правила и взял на себя ответственность за них. Но ок, он с этим не разбирается (тогда спрашивается, а какой это нафиг техдир, ну да ладно). Значит эту задачу должен был взять следующий по цепочке - тимлид. Споры и обсуждения это хорошо и полезно, архитекторы должны вовлекать других в подобных большие вопросы, но в конечном итоге надо в какой-то момент твердо сказать - делаем так то так то потому то потому то.
Предварительно менеджер и техдир (и тимлид, раз он тут архитектор главный стал) таки должны были обрисовать план, зачем это бизнесу надо. Какие конкретно метрики это улучшит. Нужно ли реально было все переделывать или достаточно было рефакторинга и подумать немного про архитектуру.
Ну и конечно же, монолиты, в зависимости конечно от размера, обычно "душат". Отколупливают изолированный функционал в новые сервисы, а новый функционал сразу пишут в отдельных сервисах. Иначе "бэкэнд 2.0" может никогда так и не уйти в продакшен.
МС это все же не столько про распределение работы между командами. Это тоже важно и одно из полезных следствий такой архитектуры, но в первую очередь исходят из доменной специфики. Если какие-то сервисы никаким образом между собой не связаны, но им надо быть раздельными. Иначе получаются такие микромонолиты из не связанной бизнес логики, что тоже можно сказать антипаттерн. Потом людей станет больше и чего с этим делать? Либо вообще не начинать сервисы пилить, либо уж делать их корректно. Самое главное это держать каждый сервис в ответственности одной команды.
Я бы сказал "как из пушки по воробьям" здесь некорректная характеристика. Скорее nginx это менее подходящее решение на сегодня, когда есть лучшие альтернативы. Основные проблемы nginx (по крайне опенсорса его варианта, а не всяческих надстроек и платных решений, которые вокруг него предлагает F5. Там может быть все это решено) происходят из его возраста. У него нет нормального хот релоада, API, service discovery, мониторинга, интеграций. Всех тех фич, которые обычно вкладывают в определение cloud-native. Все это нужно в микросервисных архитектурах, где инфраструктура очень динамично меняется и статичный характер nginx создает много боли. Его так или иначе приходится обкладывать каким-нить control plane'ом, чтобы нормально его интегрировать.
Для меня да. Офисные машины у разрабов обычно мощнее. Я мыслю больше с точки зрения on-premise виртуального кластера, где гитлаб это капля в море.
Вот под раннеры реально приходилось пожирнее виртуалки поднимать с десятками ядер и гигов оперативы.
Это уже несколько за пределами нормальных нагрузок. Теоретически, с этим должны бороться лимиты на дифы, которые в гитлабе есть.
Ну допустим, да. И сколько там будет RPS? 100-200? Это все еще смешные нагрузки и не удивительно, что референс архитектура гитлаба не просит много железа. Они там конечно демократично довольно оценивают потребности на 1к, но все равно сильно много ему не нужно. Десяток другой гигов оперативы, десяток ядер процессора и будет бегать как миленький.
Все конечно сильно зависит от количества билдов еще. Раннеры могут намного больше сожрать, чем весь гитлаб.
Откуда там десятки? До 1к юзеров гитлаб будет спокойно бегать на средненькой виртуалке, больше ему не нужно.