Наташа Косинова. Варю айти СУП
2.27K subscribers
51 photos
3 videos
8 files
306 links
Я системный аналитик, тимлид, ментор, тренер и автор айти курсов. Работаю в айти сфере с 2006 года. Мой канал про айти, без лапши успешного успеха. Варю айти СУП здорового человека)

Мои услуги:
https://nkosinova.taplink.ws

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

На собеседование на позицию "системного аналитика" я в очередной раз сказала фразу, что наша 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 в помощь. Хайпануть перед молодежью? Похоже в наши турбулетные времена это начинает уходить на второй план.