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

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

Ограниченные контексты и структуры команд

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

Осиротевшая служба?

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

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

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

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

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