29 мая в 15:00 MSK приглашаю на очередной бесплатный вебинар по микросервисам. В марте этого года на CUSTIS Meetup: Микросервисы в Enterprise я рассказывал о том, что ажиотаж по поводу микросервисов в корпоративном ИТ несколько стих и даже предложил вариант ответа на вопрос: «Почему?». Вернее, даже три причины, объединенные общим заголовком: «Барьеры микросервисной архитектуры». И в качестве главного барьера я посетовал на непонимание того, что же такое микросервисы значительной частью айтишного и околоайтишного сообщества. В принципе, в этом нет ничего необычного. Архитектурный стиль RESTful тоже мало кто понимает, но это не особо мешает создавать более-менее нормальные программные интерфейсы.
С микросервисами похожая история. Заложенные в микросервисной архитектуре подходы существенно повлияют на корпоративные ИТ. Но случится это не сейчас и не завтра, а в более долгосрочной перспективе(потому, что преодоление барьеров требует времени). При этом, основное изменение произойдет в операционной модели деятельности ИТ-подразделения. Новый архитектурный стиль заставит нас по-другому формировать проектные команды, распределять функционал между системами и рисовать сами границы систем.
Это довольно важно, потому как не смотря на наличие таких практик, как agile и devops внятных подходов к ответу на вопрос: какой именно команде разработке поручить ту или иную задачу — до сих пор нет. Мы продолжаем мыслить парадигмой «монолитной архитектуры». Когда появляется новая задача архитектор либо бросает её во внутрь существующего приложения и разработчики, порефакторив свой big ball of mud, как-то её там реализуют, либо создает новое приложение(и новую команду разработки), которое с большой болью будет потом интегрироваться в существующий ИТ-ландшафт.
В связи с этим, одной из основных тем вебинара станет разговор о принципе MonolithFirst и о том, как он помогает провести реновацию обновление унаследованных приложений. О том, почему пора отказываться от многолетних проектов замены одной плохой информационной системы на другую и как это сделать при помощи микросервисов.
И конечно, мы отдельно поговорим о том, что же такое микросервис, каковы критерии его микросервисности и каким из девяти характеристик он обязательно должен удовлетворять.
Регистрация: https://mxsmirnov.timepad.ru/event/490992/
Вопросы можно предварительно задать в группе Telegram: Архитектура ИТ-решений или в чате в ходе трансляции.
Ссылки на похожие сообщения:
- Cloud-Native Application Architectures
- Докеры, контейнеры и прочие микросервисы. Как DevOps меняет жизненный цикл ПО
- [r]evolutionary architecture
PS: С учетом накладок с рассылкой уведомлений перед предыдущим событием, ссылку на планируемый вебинар по Микросервисной архитектуре Вы получите сразу же после регистрации
Барьеров существенно больше трех.
Хозяева SOA решили, что микросервисы это совсем не архитектура, а набор технических решений – см. https://www.linkedin.com/feed/update/urn:li:activity:6266622261210411008/
Технари считают что REST обязателен – но это не так https://blog.poki.com/from-monolith-to-microservices-b16bae1d6c9d
Руководители от ИТ предполагают, что при переходе на микросервисы надо все переписать, но это не так – см. комментарии к https://www.linkedin.com/pulse/beauty-microservices-maturity-model-alexander-samarin
Ну и слайд №14 https://www.slideshare.net/MxSmirnov/ss-76013596 то же вызывает недоумения: какие процессы — вычислительные или бизнесовые? почему дополнительные экземпляры обязательно staleless?
Часто забывают о: 1) SRP, 2) том, что микросервисы предназначены для реализации целых приложений и 3) том, что бывают микросервисы, собранные из других микросервисов.
Отдельная «зона» умолчания – это то, что при переходе на микросервисы и для полного использования их потенциала надо постепенно перестраивать практический весь ИТ департамент по BizDevOps и с другими архитектурными «мозгами».
Thanks,
AS
Александр, спасибо за комментарий! По поводу первой ссылки об Microservices Maturity Model https://www.ibm.com/developerworks/community/blogs/Marc/entry/Microservices_Maturity_Model даже и не знаю что сказать. Я бы просто проигнорировал эту активность уважаемой компании IBM. Еще во времена SOA такого было слишком много
На 14 слайде речь идет, конечно, о процессах, запущенных на сервере, которые мы видим посредством команды «ps -ax». Это про первое свойство микросервисов из статьи Фаулера: «Componentization via Services» сказанное другими словами.
Максим, спасибо за разъяснения.
Тогда «дополнительные экземпляры» — это threads или «computing processes»?
В принципе — processes. Хотя, судя по всему, в термин «независимое развертывания» люди будут вкладывать и многие другие варианты
Да, согласен.
Я тут парочку постов добавил к свой коллекции о микросервисах — http://improving-bpm-systems.blogspot.ch/search/label/%23microservices — может сгодится.