#микросервисы #мысливслух #капитаночевидность #собеседование

На собеседование на позицию "системного аналитика" я в очередной раз сказала фразу, что наша WMS система имеет микросервисную архитектуру. И почувствовала непонимание со стороны соискателя.

И вцелом это конечно печально, что соискатель даже не прочитал описание вакансии и заранее не пошёл в интернет читать про микросервисы. Я наверное слишком добрая и на пальцах рассказала, про микросервисы. А образы типов архитектур чаще всего показываю в виде красивого непрактичного замка и индийских трущоб :) За что спасибо каналу softer. Жаль пандемия немного затормозила митапы, которые у https://t.me/softer_ru были более, чем полезные) Вот делюсь с вами столь прекрасными фото и описанием :)

#материал #микросервисы #ITаналитик

Снова про микросервисную архитектуру!)
Наконец-то я нашла вменяемое объяснение зачем нужно аналитику понимать и уметь рассказать реализацию микросервисной архитектуры. Плюс, спасибо Максиму Цепкову за супер аналогию микросервисов и маленьких гномиков)))

Что микросервис - это гномик, который может делать только одно действие и дальше передавать другому гномику. И с такой аналогией становится понятнее, как и что работает и масштабируется. Запись выступления есть открытая, для разработчиков и архитекторов, немного сложный материал, но ценный и качественный с историей развития языков разработки.

Так вот нафига понимать архитектуру? Иногда могут возникать пути развития архитектуры и масштабирования решения совсем разные. И как и что реализовать, и какое решение выбрать напрямую влияет на бизнес, и если разработка принимает решение без бизнеса, то можно и клиентов потерять, и на лояльность повлиять. А чтобы бизнес принял решение, нужно объяснять на пальцах в чем проблема и как реализуется архитектура. И тут нас сцену выходят гномики)

Я честно скажу, что не объясняла бизнесу микросервисную архитектуру на примере гномиков. Но почему задача не для нашей команды, или почему всё так сложно, приходилось объяснять, рассказывая через предметную область. Что вот эта часть наша, а вот эта нет, и это другая команда.

Про "гномиков" , которые обслуживают интернет-магазин можно посмотреть в районе 23 минуты видео)))

https://youtu.be/AkUMSyapP6E

P. S. Update
Есть ещё запись выступление Максима Цепкова на последней конференции Analyst days https://www.youtube.com/watch?v=7EHlFbaME_U&list=PL_XScYmjXxkcj_fsacjXWnYsKtTIWdQ2M&index=5&ab_channel=VladislavOrlikov

#мысливслух #микросервисы #soa #рассуждения #моемнение #тенденции #мирвокруг

SOA архитектура и микросервисы. SOA никому не нужна?

Возник небольшой у меня холивар на тему того, что SOA архитектура вместе с шинными решениями умирают, а точнее они преобразовались в микросервисы, взяли основу в том, что каждый микросервис должен быть независмый и нет смысла смотреть в сторону SOA с централизацией обмена данными через шину.

По факту всё подряд называют микросервисами. И какая там под капотом архитектура уже и не разобраться. То что я вижу на практике это гибрид, и с моей точки зрения это нормально. Когда в больших кровавых Enterprise решениях есть и монолит, и SOA, и микросервисы, и микрофронтенды. Шинные решения отлично защищают внешние границы айти ландшафта, вот тебе и управление сертификатами, и администрирование каналов связи, и централизация сбора данных для BI, тем более soap и гос сервисы предъявляют требования коннекта к ним по безопасному каналу.
А вот тебе и внутренность системы на микросервисах. Одно с другим нормально живёт вместе. Тут конечно больше вопрос к архитекторам, которые говорят, что есть только путь, чтобы стать им))

Но к сожалению, когда я слышу микросервисы для меня это равно бардак. Мало где я встречала процесс работы с артефактами и с описанием решения на таком уровне, чтобы можно было этим гибко управлять, также гибко, как и изменениями микросервисов.
Вопрос зрелости процессов, решений и самих систем тут скорее определяющий. Возможно ли сделать какой-то компонент так, чтобы потом его не трогать и не изменять? На практике я видела как наш функционал прожил лет 10, просто переписывался и переносился с одной платформы на другую.

С микросервисами работа с предметной областью, грамотная нарезка сервисов действительно вопрос квалификации сотрудников. И вечный вопрос для меня, во-первых, почему когда говоришь айти директору, что команда не понимает нюансы микросервисной архитектуры, но её разрабатывает, и надо бы прочитать курс и как-то синхронизировать понимание, это вызывает недоумение. А второй момент, почему фактически "хирургу" разрешают резать, при условие, что он не знает где печень?
Я наивная, у меня в голове структура такая, что сначала пойду поучусь, узнаю, что и как, получу диплом, а потом уже пойду плавать. Хотя вот дядя Есенина его выбросил в озеро и Сергей Есенин выплыл, ну камон 21 век же)) Зачем нам губить таланты!
Понимаю ответ менеджеров - у нас есть сроки, бюджет, нам нужны ресурсы, кого нашли, того и взяли, нет времени на обучение. Ну да, бразильская система в деле https://youtu.be/s_HItWKBLl4

Может тогда и не нужны микросервисы? И монолит, и рядом шины, и SOA в помощь. Хайпануть перед молодежью? Похоже в наши турбулетные времена это начинает уходить на второй план.

Текущая культура микросервисов провоцирует зоопарк технологий. Каждый участник команды хочет применить свою технологию, и мы говорим, не проблема, давай. И тогда приходится поддерживать весь процесс - написания, поддержки и итог, микросервис перестаёт быть простым.

Распределенная систем это микросервис, сделать хороший интеграционный тест невозможно, для таких систем. Мы пишем как бы это протестировать, но это не бесплатно.

Ещё мы думаем, что программист инженер с высшим образованием, он же умный и он любой трюк может поддержать. Но это не так, мы можем определять только те смыслы, которые годами сформировались. А вот у нас новое, а человек годами с монолитом работал. И для нового ему нужны месяцы - чтобы разобраться, и годы чтобы начать работать.

Микросервисы не прощают плохие архитектурные решения, хаки, растёт тех долг. Не можем копит тех долг, может возникнуть ситуация, когда через пару недель не будет работать наш микросервис.

Микросервисы - это круто! Нам дали деньги и залили на миллионы рпс, проекты ценой огромных инвестиций в том числе в обучение людей. Как мы с этим кодом будем работать - это проблема. В огромных компаниях оно хорошо работает. И вот нам говорят, давайте сделаем микросервисы, но распил монолита не будет проще. Микросервисы не могут быть заменой монолита, ибо добавляют новый уровень сложности. Например, Вася говно кодил в монолит, и потом всё встало, а в микросервисах можно их изолировать. Микросервисы вот оно круто. Да, но нет.

Проблема сложности ПО. Когда выбираем архитектору, языки, тулинги, это все не бесплатно. Наш мозг это не бесплатно и нужно время чтобы научиться думать о больших штуках.

В монолите есть архитектурные границы. Культура в микросервисах, та что есть сейчас не даёт нам простоту.

Код стоит писать так, чтобы он рассказывал историю без вас, как суфлера. Если вы думаете нужны ли вам стандарты создания кода - нужны, делайте!
Нужен большой опыт тим лидов и архитекторов.
Когнитивная сложность монолита и микросервисов разная для сеньора и джуна.

#CodeFest14 #микросервисы #доклад #ГригорийПетров