Было бы неплохо, на мой скромный, рассказать какое место SA занимает в EA, за что и перед кем отвечает. И хотелось бы все же понять, где для вас границы между solution и system?
Уважаемый, не в защиту кровавого энтерпрайса, но бывают кейсы и когда hr ни при чем. Как человек, который часто видит процесс с другой стороны в разных компаниях, могу сказать что бывает кейс когда техлид, в команду которого идет прием, начинает динамить hr-а с ответом. Типа чувак ничего, но «можно всех посмотреть». А это «всех посмотреть» затягивается на месяцы иногда. И потом hr-у просто неловко становится звонить через пару месяцев кандидату :) Так что если вас прямо интересует место и нет ответа — возможно это хороший знак, долбайте и будьте настырным с hr-ом.
Мне кажется, вы слишком экстраполируете свой опыт :) Да, я тоже больше полагаюсь на импровизацию, тезисы у меня как правило буквально 1-2 слова на каждую мысль. Но есть и ребята, которые расписывают достаточно детально все ветки повествования, в зависимости от реакции, вопросов. И уверенность что они все предусмотрели положительно сказывается на качестве выступления. Мой опыт подсказывает мне один универсальный совет в части публичных выступлений — больше выступлений и больше экспериментов с их техникой, целевой аудиторией, задачами выступления :)
Один из плюсов (микро)сервисов — экономия на железе при прочих равных, даже если не брать гибкие скейлинги в облаках.
На мой взгляд, все же больше. Помимо резервирования мощности для скейлинга, там еще реализация интеграционной обвязки, превращение stateful в стейтлесс, да и сама оркестрация и непростой мониторинг и аудит.
По людям тоже спорно. На разработку большинства микросервисов (не архитектуры, самих сервисов) можно как раз брать менее квалифицированных спецов — они архитектурно не смогут нарушить изоляцию модуля, с одной стороны, а, с другой, для некритических частей можно брать более дешевый стек в целом. Грубо, не писать всё приложении на C++ с ассемблерными вставками из-за того, что один модуль очень требователен к производительности, f только этот модуль на нём, а остальное на PHP :)
Тут скорее история про опыт людей работы в командах изолированных сервисах и их «софт скиллз». Если вы возьмете команду монолита и рассадите их по модулям, то первый же релиз скорее всего будет ужасен. Взаимное возлагание вины за баги, непонимание общей картины как оно должно работать. «С моей стороны пуля вылетела...».
Честно говоря, не понимаю почему столько копий ломается на эту тему. Не соглашусь с автором статьи что MSA это не про архитектуру — на мой взгляд вполне себе архитектурный стиль. Другое дело что это если взять тот же togaf, то этот стиль влияет прямо на 1 домен архитектуры предприятия.
В целом же прежде чем что-то менять и имплементировать, надо подумать зачем. Микросервисы это довольно дорого как по ресурсам железа, так и по людям. Спецов по классическому подходу гораздо больше, чем ребят, реально хорошо сделавших микросервисы в проме. Развернутый на 1 ноуте кластер кубера с 2-3 тестовыми сервисами не в счет :)
Да, с развитием контейнеризации и оркестрации сделать правильный msa стало более реально. Но всегда перед тем как что-то делать надо задать себе вопрос «в чем профит?». Правильных ответов на мой взгляд 2: «Без msa вот прям никак не будет работать» и «так дешевле. Я все-все просчитал и так дешевле». В остальных случаях вы должны понимать что скорее всего реализуете свои амбиции и жажду знаний за счет работодателя.
Уважаемые, во-первых, это статья переводная, не надо шеймить автора. Он нигде не пишет что на 100% разделяет позицию автора.
Во-вторых, перевод довольно качественный, на хорошем ресурсе — я надеялся что пустого «троллинга» будет поменьше. Изначальный автор статьи привел удобные ему примеры — ок, оппонируйте, приведите свои доводы.
В целом на мой взгляд блокчейн уже прошел точку хайпа ru.wikipedia.org/wiki/Gartner#%D0%A6%D0%B8%D0%BA%D0%BB_%D1%85%D0%B0%D0%B9%D0%BF%D0%B0, надеюсь спустя пару лет появятся действительно хорошие инструменты на блокчейне. Пока же многие позабыли философию блокчейна (тут я солидарен с г-ном Бутериным) и погнались за легким баблом.
P.S. Спасибо ребятам из Райфа за хорошие материалы, вот правда :)
А я честно говоря не услышал призывов выжечь SOA и ESB из ландшафта. Если вам подходит классический вариант с ESB — почему бы не продолжать использовать его? Продиктовано это скиллами вашей команды, видением или легасевостью ландшафта — это уже вопрос вне рамок темы :) Да и кто мешает применять разные арх. стили в разных слоях? Райф это банк, в банках есть Бэк слой где монолиты не только превалируют, но и зачастую оправданы.
На мой взгляд, статья для вводной вполне годная, хотя возможно стоило бы обозначить вначале целевую аудиторию. Планируется ли описание примера внедрения MSA в Райфе? :)
Все верно, вопрос в «хранилище». И тут как правило разделяют сессионный кэш и кэш данных, которые обычно поднимаются в канал из бэков. Про сессионный понял, а вот к вопросу про остальные данные — какого рода эта БД? Если обычная реляционка, то нет ли проблем со скоростью обработки запросов и локах, если в одну таблицу собираются данные из нескольких систем-источников?
Спасибо за ваши комментарии.
И на первый и на второй вопрос ответ, кмк: OGG + in memory data grid. SLA в 3-4 секунды вполне дозволительный зазор в данном случае. Но да, штука дорогая. Ввод и сопровождение нового in-house бэка в ландшафт в данный момент может казаться дешевле, но на горизонте 3-5 лет ответ останется тем же? :)
Спасибо за статью, интересный пример. Но часть решений вызывает, конечно вопросы :) Зачем делать новый бэк в данном случае? Почему все таки не процессинг будет мастером по остатку? Почему не поднимать данные из других бэков через какой нибудь кэшовый слой? Зачем в этот же новый бэк запихивать комиссии? Логичней имхо или в единый каталог продуктовый их запихивать, или вести в ИС, которая мастер по договору клиента (если тарифы предполагают индивидуальность).
На мой взгляд, все же больше. Помимо резервирования мощности для скейлинга, там еще реализация интеграционной обвязки, превращение stateful в стейтлесс, да и сама оркестрация и непростой мониторинг и аудит.
Тут скорее история про опыт людей работы в командах изолированных сервисах и их «софт скиллз». Если вы возьмете команду монолита и рассадите их по модулям, то первый же релиз скорее всего будет ужасен. Взаимное возлагание вины за баги, непонимание общей картины как оно должно работать. «С моей стороны пуля вылетела...».
В целом же прежде чем что-то менять и имплементировать, надо подумать зачем. Микросервисы это довольно дорого как по ресурсам железа, так и по людям. Спецов по классическому подходу гораздо больше, чем ребят, реально хорошо сделавших микросервисы в проме. Развернутый на 1 ноуте кластер кубера с 2-3 тестовыми сервисами не в счет :)
Да, с развитием контейнеризации и оркестрации сделать правильный msa стало более реально. Но всегда перед тем как что-то делать надо задать себе вопрос «в чем профит?». Правильных ответов на мой взгляд 2: «Без msa вот прям никак не будет работать» и «так дешевле. Я все-все просчитал и так дешевле». В остальных случаях вы должны понимать что скорее всего реализуете свои амбиции и жажду знаний за счет работодателя.
Во-вторых, перевод довольно качественный, на хорошем ресурсе — я надеялся что пустого «троллинга» будет поменьше. Изначальный автор статьи привел удобные ему примеры — ок, оппонируйте, приведите свои доводы.
В целом на мой взгляд блокчейн уже прошел точку хайпа ru.wikipedia.org/wiki/Gartner#%D0%A6%D0%B8%D0%BA%D0%BB_%D1%85%D0%B0%D0%B9%D0%BF%D0%B0, надеюсь спустя пару лет появятся действительно хорошие инструменты на блокчейне. Пока же многие позабыли философию блокчейна (тут я солидарен с г-ном Бутериным) и погнались за легким баблом.
P.S. Спасибо ребятам из Райфа за хорошие материалы, вот правда :)
И на первый и на второй вопрос ответ, кмк: OGG + in memory data grid. SLA в 3-4 секунды вполне дозволительный зазор в данном случае. Но да, штука дорогая. Ввод и сопровождение нового in-house бэка в ландшафт в данный момент может казаться дешевле, но на горизонте 3-5 лет ответ останется тем же? :)