Что-то тут разные вещи смешаны, message bus да и вообще EDA подразумевает именно общение сервисов через события. Вот это "Вы также можете отследить любой момент времени и откатить продукт к состоянию на любую дату" совсем не обязательно подразумевается в EDA. Для этого всё-таки должен быть реализован event sourcing, обычно событие удаляется из шины после того как потребитель его обработал и передал acknowledgement о нем.
Проходил/прохожу в 2021, 2020, 2019. в 2019м в MS оставшееся время беседовали об этом с одним из интервьюеров и он посмеялся над этим тоже, сказал что такие задачи они давно дают только людям без опыта, читай студентам, у которых-то и спросить больше нечего. Согласен, есть и люди которые бездумно перенимают то что они считают лучшим. Даже на логику есть куда более адекватные задачи.
Бред. Собеседовался в MS на Software Engineer и дважды в гугл на Software Engineer Manager за последние 3 года. В MS никаких тупых задач для студентов не было, были задачи приближенные к реальному миру и после их решения каждый раз говорили (ну вот примерно вот так у нас хранение прав устроено), в гугле аналогично: только одно собеседование по кодингу из 5 такое на «базовые вещи» и то это не просто «покажи дао алгоритмов» а вот тебе интересная задачи и реши её, а потом мы обсудим её сложность и как можно улучшить.
А про Яндекс сколько лет не проходит одно и тоже: тупой онанизм на алгоритмы и не надо рассказывать что то «ну а как же им еще большой поток неадекватов отсеивать». У FAANG их куда больше и они постоянно улучшают процессы. В прошлом году в гугле код надо было писать в гугл доке (о да, круто, правда?), в этом уже они свой редактор сделали и плюс ввели кроме кодинг еще и код ревью собес для менеджеров.
Это замечательно, но совсем не понятно на чем же зарабатывать? Офис красивый, слов нет, но работать все равно не тянет, потому что не понятно над чем работать-то. Такое ощущение что основная цель офиса — это делать постановочные фото и устраивать некие митапы.
Ага, деплой скрипт, который пойдет все качать, ставить настраивать и тд, и тд. вместо того чтобы просто сделать docker pull и запустить уже собранный образ. Вообще ведь никакой разницы…
Если надо внести изменения, то схема не сильно меняется, вообще даже не меняется. Просто вместо запуска уже собранного контейнера, надо будет перед этим собрать его. Опять-таки без необходимости устанавливать и настраивать все зависимости.
Вот отладка уже другое, докер тут не причем, но и разработчику с другого проекта незачем отлаживать другой проект
Докер ест время на вполне понятный выигрыш. Если у вас одна машина, то он вам не нужен. Если у вас несколько машин, то каждый раз ставить на них все зависимости и производить базовые настройки для запуска приложения — это трэш. Завтра у вас одна машина упала и вы судорожно настраиваете ей замену, а я просто ставлю label на другой и смотрю как Кубер поднимает на ней контейнер за минуту, согласно заданным правилам.
Если разработчику с другого проекта, стэка понадобилось запустить ваш проект, то он просто берет и запускает собранный образ, а не с бубнами и readme тратит время на сборку локально. Это прям доказано уже не один раз на собственном опыте.
Всегда стоит смотреть из каких образов вы наследуетесь, доверять можно только офф хабам, в остальных случаях там может быть неизвестно что. У нас базовый образ node.js 650 метров, если взять на alpine, то еще меньше будет. Переубеждать вы никого не должны, внедрять это должны devops-ы.
У вас какой-то странный взгляд: вы не хотите потратить время чтобы разобраться в чем-то новом, что в итоге вам дальше будет экономить куда больше времени, а уже считаете что это вам ничего не даст. Докер используют далеко не первый год в продакшене, в больших и малых компаниях, все плюсы и минусы его давно известны, надо просто взять и почитать.
Подозреваю что вы что-то делаете не так, что-то лишнее запихиваете в образ, что должно лежать на внешнем volume. Почти любое приложение можно запихнуть в alpine образ, если уж сильно постараться. У нас даже кривые образы, до которых не доходят руки поправить, не выходят за гиг.
У нас вся инфраструктура на кубере, не важно какой именно проект: и телеметрия, и сами проекты и базы данных, и гитлаб и прочее, все в докере (у нас геймдев студия). Кубер относительно сложный в настройке, скорее в него не так легко вкатиться сначала, потом уже становится все сильно проще. То что прям сильно глючный — не могу сказать, но иногда проскальзывают мелкие неприятные моменты, но ни разу не привели к даунтайму. Но дальнейшее удобство от его использование сильно перевешивает это.
Да, я знаю. Но почему-то часть народа до сих пор так думает, что докер это виртуалка со всеми вытекающими минусами. Несколько раз сталкивался с таким мнением
Вы серьёзно? Я вот эти доводы слышу от людей, которые судят про докер потому что увидели что на маке он работает в Virtualbox (ой, докер оверхед создает и тд). Используем докер в продакшене на нескольких десятках машин под Кубером. Более удобного инструмента для масштабирования, деплоя, мониторинга и тд я в жизни не встречал.
Что-то тут разные вещи смешаны, message bus да и вообще EDA подразумевает именно общение сервисов через события. Вот это "Вы также можете отследить любой момент времени и откатить продукт к состоянию на любую дату" совсем не обязательно подразумевается в EDA. Для этого всё-таки должен быть реализован event sourcing, обычно событие удаляется из шины после того как потребитель его обработал и передал acknowledgement о нем.
А про Яндекс сколько лет не проходит одно и тоже: тупой онанизм на алгоритмы и не надо рассказывать что то «ну а как же им еще большой поток неадекватов отсеивать». У FAANG их куда больше и они постоянно улучшают процессы. В прошлом году в гугле код надо было писать в гугл доке (о да, круто, правда?), в этом уже они свой редактор сделали и плюс ввели кроме кодинг еще и код ревью собес для менеджеров.
Если надо внести изменения, то схема не сильно меняется, вообще даже не меняется. Просто вместо запуска уже собранного контейнера, надо будет перед этим собрать его. Опять-таки без необходимости устанавливать и настраивать все зависимости.
Вот отладка уже другое, докер тут не причем, но и разработчику с другого проекта незачем отлаживать другой проект
Если разработчику с другого проекта, стэка понадобилось запустить ваш проект, то он просто берет и запускает собранный образ, а не с бубнами и readme тратит время на сборку локально. Это прям доказано уже не один раз на собственном опыте.
Всегда стоит смотреть из каких образов вы наследуетесь, доверять можно только офф хабам, в остальных случаях там может быть неизвестно что. У нас базовый образ node.js 650 метров, если взять на alpine, то еще меньше будет. Переубеждать вы никого не должны, внедрять это должны devops-ы.
У вас какой-то странный взгляд: вы не хотите потратить время чтобы разобраться в чем-то новом, что в итоге вам дальше будет экономить куда больше времени, а уже считаете что это вам ничего не даст. Докер используют далеко не первый год в продакшене, в больших и малых компаниях, все плюсы и минусы его давно известны, надо просто взять и почитать.