Вебинар: Микросервисная архитектура. Обновление монолитных приложений

29 мая в 15:00 MSK приглашаю на очередной бесплатный вебинар по микросервисам. В марте этого года на CUSTIS Meetup: Микросервисы в Enterprise я рассказывал о том, что ажиотаж по поводу микросервисов в корпоративном ИТ несколько стих и даже предложил вариант ответа на вопрос: «Почему?». Вернее, даже три причины, объединенные общим заголовком: «Барьеры микросервисной архитектуры». И в качестве главного барьера я посетовал на непонимание того, что же такое микросервисы значительной частью айтишного и околоайтишного сообщества. В принципе, в этом нет ничего необычного. Архитектурный стиль RESTful тоже мало кто понимает, но это не особо мешает создавать более-менее нормальные программные интерфейсы.

С микросервисами похожая история. Заложенные в микросервисной архитектуре подходы существенно повлияют на корпоративные ИТ. Но случится это не сейчас и не завтра, а в более долгосрочной перспективе(потому, что преодоление барьеров требует времени). При этом, основное изменение произойдет в операционной модели деятельности ИТ-подразделения. Новый архитектурный стиль заставит нас по-другому формировать проектные команды, распределять функционал между системами и рисовать сами границы систем.

Это довольно важно, потому как не смотря на наличие таких практик, как agile и devops внятных подходов к ответу на вопрос: какой именно команде разработке поручить ту или иную задачу – до сих пор нет. Мы продолжаем мыслить парадигмой «монолитной архитектуры». Когда появляется новая задача архитектор либо бросает её во внутрь существующего приложения и разработчики, порефакторив свой big ball of mud, как-то её там реализуют, либо создает новое приложение(и новую команду разработки), которое с большой болью будет потом интегрироваться в существующий ИТ-ландшафт.

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

И конечно, мы отдельно поговорим о том, что же такое микросервис, каковы критерии его микросервисности и каким из девяти характеристик он обязательно должен удовлетворять.

Регистрация: https://mxsmirnov.timepad.ru/event/490992/

Вопросы можно предварительно задать в группе Telegram: Архитектура ИТ-решений или в чате в ходе трансляции.

Ссылки на похожие сообщения:

PS: С учетом накладок с рассылкой уведомлений перед предыдущим событием, ссылку на планируемый вебинар по Микросервисной архитектуре Вы получите сразу же после регистрации

Вебинар: Микросервисная архитектура. Обновление монолитных приложений: 5 комментариев

  1. Барьеров существенно больше трех.

    Хозяева 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

    1. Александр, спасибо за комментарий! По поводу первой ссылки об Microservices Maturity Model https://www.ibm.com/developerworks/community/blogs/Marc/entry/Microservices_Maturity_Model даже и не знаю что сказать. Я бы просто проигнорировал эту активность уважаемой компании IBM. Еще во времена SOA такого было слишком много

      На 14 слайде речь идет, конечно, о процессах, запущенных на сервере, которые мы видим посредством команды “ps -ax”. Это про первое свойство микросервисов из статьи Фаулера: “Componentization via Services” сказанное другими словами.

      1. Максим, спасибо за разъяснения.

        Тогда “дополнительные экземпляры” – это threads или “computing processes”?

Добавить комментарий для AS Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *