Три вебинара о микросервисах

3msa16, 18 и 23 октября 2018 г. Я проведу серию вебинаров под незатейливым названием «Три вебинара о микросервисах». По законам жанра мне следовало бы написать несколько захватывающих историй, заканчивающихся словами: присоединяйтесь к нашему мини-курсу. Причем истории эти могут быть разные для аналитиков, архитекторов, разработчиков, людей, которые занимаются эксплуатацией, руководителей ИТ-проектов, менеджеров продуктов. Я попробую это сделать и начну с разговора о том: зачем вообще обсуждать тему микросервисов. Разработчики уже несколько лет назад сообразили, что правильным ответом на вопрос об архитектуре решения является: микросервисная. Часто, разговор заказчика и потенциального поставщика так и выглядит:

— Какова архитектура вашего решения? – проникновенным тоном интересуется заказчик.
— Микросервисы… — уверенно отвечает потенциальный поставщик, немного смущенный простым вопросом, ответ на который, практически, очевиден.
— И сколько у вас микросервисов? – слегка разочаровавшись правильным ответом интересуется заказчик.
— Более полусотни! – с усиливающейся уверенностью в голосе отвечает поставщик.

Часто на этом разговор об архитектуре заканчивается. Ну а о чем еще говорить? Нет, безусловно, если заказчик знаком с темой микросервисов и читал, например, статью Microservices a definition of this new architectural term он может поинтересоваться используемыми технологическими стеками или задать совсем уж каверзный вопрос: «а какие business capabilities реализованы отдельными микросервисами?» Скорее всего на этот вопрос поставщик не сумеет ответить и диалог прервется. Я ни разу не видел, чтоб разработчик, заявляющий свою приверженность микросервисной архитектуре, достал бы в ходе обсуждения функциональную карту в формате archimate capability map и стал бы рассказывать, как они выбирали наиболее подходящие технологии для реализации каждой новой бизнес-функции.

Я предлагаю другой формат дискуссии и другой набор вопросов для обсуждения. Первое, на что на мой взгляд необходимо обратить внимание – требования к инфраструктуре. Как ваш потенциальный поставщик собрался развертывать микросервисы? Он принесет с собой Docker, Kubernetes, какой-нибудь Service Mesh (не пугайтесь, пожалуйста, этих слов) и попросит у вас сервера для подключения их в кластер или же он рассчитывает на вашу инфраструктуру? Скорее всего он вообще об этом пока не думал и увлекательное упражнение по созданию такой, не самой простой среды, вам предстоит непосредственно перед запуском решения.

Или другой не менее важный вопрос. Представьте себе, что решение уже внедрено. Готовые компоненты развернуты, что-то кастомизировано по вашим требованиям, баги поправлены, акты подписаны, в общем – всё работает! Вряд ли такая ситуация продлится долго. Наверняка кто-то из бизнеса прибежит со словами: сделайте мне новую фичу, пожалуйста… Это срочно! Поставщик, о существовании которого вы уже стали немного забывать, уже стоит на пороге с контрактом на развитие приложения, протягивая вам waterman или parker. Слово рефакторинг витает в воздухе, заполняя собой всю комнату, настолько плотно, что становится тяжело дышать. Вы смотрите на приписанный к сумме контракта ноль (справа) и, почему-то, не очень хотите его подписывать. Давайте разбираться. В ходе проекта никто не спросил у поставщика как подключить к системе новые микросервисы, разработанные собственными силами или заказанные другому поставщику; где те самые заветные API, которые следует реализовать для появления к системе нового компонента, переопределения бизнес-логики обработки команд, создания новых форм отображения данных. Но разве не для того мы выбираем микросервисную архитектуру, чтоб развивать функционал решения без переработки уже запущенных компонент?

Третий важный момент: масштабируемость, отказоустойчивость, автоматизация эксплуатационных операций, автоматическое восстановление и прочая антихрупкость. Реализация продекларированных характеристик Design for failure и Infrastructure automation, вызывающих ехидную улыбку у вашего системного администратора. Будто бы система сама будет устанавливать патчи и обновления, проводить плановые работы и масштабироваться при росте нагрузки в публичное облако. Ага, щас! После успешного завершения проекта приложение, в лучшем случае, будет сыпать алерты в систему мониторинга и забивать логи ошибками. Реалистичный сценарий – поток инцидентов сформируют недовольные сотрудники и клиенты и с каждым из них еще надо будет кропотливо поразбираться — где и что именно произошло. В общем обсуждать какие эксплуатационные операции, как и зачем будут автоматизированы надо в ходе проекта. Лучше в самом начале, одновременно с разговором о функциональных сценариях, реализуемых для пользователей.

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

В общем, присоединяйтесь: https://mxsmirnov.timepad.ru/event/812488/

Или нет?! Ведь наверняка я сумел рассказать только небольшой процент того, что вас действительно интересует. Так что лучше, сначала задайте свой вопрос в объявлении на FB  или комментариях к этому сообщению и лишь потом регистрируйтесь

  1. Немного не в кассу, но иногда хочется вступить с тобою в дискуссию в телеграме, но там это сделать никак нельзя. И пространство коммуникации исчезает 😦

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

    1. Ну, нормально, бывает! Архитекторы (вернее, как меня недавно научили: архитекторА, с ударением на последний слог) одного из предыдущих заказчиков добавили к8s в типовые требования на закупку ИТ-решения. Теперь оно так и всем поставляется

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s