Создание микросервисов

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

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

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

Конкретный пример: RealEstate.com.au

Основной бизнес компании REA связан с недвижимостью. Но он включает несколько различных аспектов, каждый из которых работает как отдельное направление бизнеса (LOB). Например, в одном направлении бизнеса занимаются сделками с жилой недвижимостью в Австралии, в другом — коммерческой недвижимостью, а третье может иметь отношение к одной из внешних бизнес-задач компании REA. У этих направлений бизнеса имеются IT-команды (или подразделения) поставки, причем у некоторых направлений может существовать только одно подразделение, а у самого крупного их четыре. Итак, на направлении жилой недвижимости несколько команд занимаются созданием сайта и перечня услуг, чтобы позволить людям просматривать собственность. Бывает, что специалисты переходят из одной команды в другую, но обычно долго определенное направление бизнеса не покидают, гарантируя тем самым компетентность в данной части бизнес-области. Это, в свою очередь, способствует общению между различными заинтересованными лицами и командой, поставляющей им те или иные функции программных средств.

Ожидается, что каждое подразделение внутри направления бизнеса несет ответственность за весь жизненный цикл создаваемых им сервисов, включая создание, тестирование и выпуск, поддержку и даже вывод из эксплуатации. Основная команда службы поставок выдает рекомендации и указания этим командам, а также разрабатывает инструментарий, помогающий выполнять их задачи. Ключевым положением является культура автоматизации, и в REA широко используется AWS как основная составляющая, повышающая автономность команд. Порядок работы всего этого механизма показан на рис. 10.1.

С работой бизнеса увязывается не только организация поставок. Увязывание распространяется и на архитектуру. Примером могут послужить методы интеграции. Внутри направления бизнеса все сервисы вольны обмениваться данными друг с другом любым подходящим для них способом в соответствии с решениями подразделений, выполняющих роль их кураторов. Но весь обмен данными между направлениями бизнеса предписано вести путем обмена пакетами в асинхронном режиме, что является одним из немногих железных правил весьма небольшой архитектурной команды. Этот обмен данными, имеющий более общий характер, соответствует такому же разностороннему обмену данными, который практикуется и между различными частями бизнеса. Благодаря настоятельному требованию ведения пакетного обмена между направлениями каждому направлению бизнеса предоставляется широкая степень свободы действий и самоуправления. Им разрешено удалять свои сервисы по собственному усмотрению, и пока они могут поддерживать пакетную интеграцию с другими частями бизнеса и с заинтересованными лицами, никого это волновать не будет.

Рис. 10.1. Общее представление о структуре организации Realestate.com.au и ее команд, а также об увязке с архитектурой