Бро, на тебя вся надежда! Потому что после перехода со Spotify на Яндекс.Музыку я поседел в некоторых местах и мой лексикон обогатился новыми фельдиперстовыми регулярными выражениями. Не подкачай, родненький!
Помню, в начале 2000-х тоже реализовали нечто подобное. У нас не было куберов и докеров, но были 1С Бухгалтерия и 1С Торговля, и " мы решили сделать так, чтобы они общались между собой. Тем самым мы заложили основу микросервисной архитектуры".
Все слишком поверхностно, в каждом пункте плюсов\минусов крайне спорные утверждения, а от словосочетания "эвентная архитектура" испытываешь мини-оргазм. Боюсь, что эту статью я бы не рекомендовал "чайникам", только хуже себе сделают.
Добавлю. После Spotify просто не понимаешь, как в Я.Музыке до сих пор нет простых радостей меломана - сортировки в плейлистах, папок, отображения плейлистов не картинками, а списком (а их реально сотни могут быть), и т.д. Не говоря уже о том, что приложение на ПК настолько убого, что даже переставить плейлисты местами нельзя, надо идти в браузер. Пишешь в технический чат - там отсылают на форум, мол, эти задачи уже в бэклоге, голосуйте на здоровье за их разработку, и будет вам счастье. Радостный идешь на форум, оказывается, эти задачи там в бэклоге уже 3 (три!) года висят. Но за неимением альтернатив, будем плакать и жрать этот кактус, куда деваться...
До сих пор помню Perfect Day и Cristal Ship с альбома Thank You, хотя последний раз слушал его лет 20 назад. А Lay Lady Lay до сих пор в подборке крутится, любимое исполнение этой песни. А оказывается, худший альбом всех времен ))
Почему-то упор в статье сделан на масштабируемости, хотя микросервисная архитектура обладает и другими не менее весомыми плюсами по отношению к монолитам: отказоустойчивость, быстрый выкат фич (TTM) и исправление багов, CI/CD, и т.д. А так получается как-то однобоко.
Разработчик тоже, в общем-то, передаст и транслятор. С вербальных требований заказчика в машинный код. К чему этот сарказм, непонятно, каждый выполняет свою работу, которая необходима для полноценного функционирования бизнеса.
Верное замечание. Архитектор все-таки развивается, как и инженер, но чисто теоретически, на практику, как вы верно заметили, ни времени, ни сил не остается. Поэтому от «реальности» он, может, и не отдаляется, возможности современных технологий представляет, но лопату в руки уже вряд ли возьмет.
Если каждое приложение может быть запущено во множественном числе, будет ли применение оркестратора сервисов типа k8s? Каким образом планируется service discovery, балансировка сервисов, и т.д.? Где api gateway для публичных api, что планируется использовать в качестве system bus? Смотря на картинку архитектуры возникает много вопросов.
Было бы хорошо еще добавить в статье, что 1С — это монолит, и обладает всеми монолитными минусами, в то время, как прогрессивное человечество запрыгивает на микросервисную платформу.
В документациях по микросервисной архитектуре для сложных сущностей рекомендуют делать микросервисы-витрины, которые агрегируют данные из микросервисов-сущностей и предоставляют их потребителям.
Кажется, что решить эту проблему можно, если сделать над сервисами-сущностями отдельный “слой” сервис, которые инкапсулируют в себя всю логику. Но обычно это тоже плохо заканчивается. Потому что тогда сервисы-сущности становятся сервисами-хранилищами, т.е. вся бизнес-логика из них вымывается, кроме хранения.
Этот отдельный слой называется хореограф или оркестратор, паттерн типа Саги и т.д. Все верно, его задача — реализовывать бизнес-логику и манипулировать данными из микросервисов-хранилищ (забирая из через API). Что в этом автор увидел плохого, непонятно.
Пример. Для менеджера, который работает с наполнением товарной номенклатуры, главными фичами будут возможность удобно добавлять товар, удалять, менять и просматривать. Нагрузки немного, если разделить в отдельные сервисы чтение и изменение, мы от такого разделения ничего не получим, кроме проблем, когда придется делать в сервисах согласованные изменения.
А зачем в данном примере что-то разделять? CQRS надо использовать только там, где это необходимо.
Все это здорово и правильно, поддерживаю двумя руками.
Но необходимо учитывать, что часть вакансий (возможно, даже, бОльшая) создана для того, чтобы решить какие-то конкретные проблемы организации «здесь и сейчас», а не через 1-2-5 лет. Соответственно, и специалист им необходим для этого с конкретными знаниями конкретных технологий «здесь и сейчас».
В плане перехода программистов в менеджеры меня всегда интересовал один момент. В подавляющем большинстве случаев (статистики, правда, нет, это субъективное мнение) программисты являются интровертами, которым проще играть умом и решать задачи, нежели общаться с человечеством. С другой стороны, чтобы выполнять компетенции менеджера, необходимо обладать экстравертными способностями: с удовольствием общаться с людьми, не бояться стрессовых разговоров, находиться в состоянии неопределенности (результаты не зависят от тебя, а зависят от команды), играть эмоциями, и т.д. Выработать абсолютно противоположные черты своего характера невозможно, можно только пытаться соответствовать образу и каждый день играть непривычную тебе роль. Что делает человека чуточку менее счастливым.
Возможно, оставаться профессионалом в той области, к которой есть предрасположенность, не так уж и плохо.
Вы используете какой-нибудь архитектурный репозиторий для моделей, или рисуете каждую из них "на коленке" и потом в confluence связываете url-ами?
Бро, на тебя вся надежда! Потому что после перехода со Spotify на Яндекс.Музыку я поседел в некоторых местах и мой лексикон обогатился новыми фельдиперстовыми регулярными выражениями. Не подкачай, родненький!
Помню, в начале 2000-х тоже реализовали нечто подобное. У нас не было куберов и докеров, но были 1С Бухгалтерия и 1С Торговля, и " мы решили сделать так, чтобы они общались между собой. Тем самым мы заложили основу микросервисной архитектуры".
Все слишком поверхностно, в каждом пункте плюсов\минусов крайне спорные утверждения, а от словосочетания "эвентная архитектура" испытываешь мини-оргазм. Боюсь, что эту статью я бы не рекомендовал "чайникам", только хуже себе сделают.
Добавлю. После Spotify просто не понимаешь, как в Я.Музыке до сих пор нет простых радостей меломана - сортировки в плейлистах, папок, отображения плейлистов не картинками, а списком (а их реально сотни могут быть), и т.д. Не говоря уже о том, что приложение на ПК настолько убого, что даже переставить плейлисты местами нельзя, надо идти в браузер. Пишешь в технический чат - там отсылают на форум, мол, эти задачи уже в бэклоге, голосуйте на здоровье за их разработку, и будет вам счастье. Радостный идешь на форум, оказывается, эти задачи там в бэклоге уже 3 (три!) года висят. Но за неимением альтернатив, будем плакать и жрать этот кактус, куда деваться...
До сих пор помню Perfect Day и Cristal Ship с альбома Thank You, хотя последний раз слушал его лет 20 назад. А Lay Lady Lay до сих пор в подборке крутится, любимое исполнение этой песни. А оказывается, худший альбом всех времен ))
В документациях по микросервисной архитектуре для сложных сущностей рекомендуют делать микросервисы-витрины, которые агрегируют данные из микросервисов-сущностей и предоставляют их потребителям.
Этот отдельный слой называется хореограф или оркестратор, паттерн типа Саги и т.д. Все верно, его задача — реализовывать бизнес-логику и манипулировать данными из микросервисов-хранилищ (забирая из через API). Что в этом автор увидел плохого, непонятно.
А зачем в данном примере что-то разделять? CQRS надо использовать только там, где это необходимо.
Но необходимо учитывать, что часть вакансий (возможно, даже, бОльшая) создана для того, чтобы решить какие-то конкретные проблемы организации «здесь и сейчас», а не через 1-2-5 лет. Соответственно, и специалист им необходим для этого с конкретными знаниями конкретных технологий «здесь и сейчас».
Возможно, оставаться профессионалом в той области, к которой есть предрасположенность, не так уж и плохо.