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

Нам хочется, чтобы наши сервисы были практичными. Хочется, чтобы код был высокого качества и сам сервис проявлял некую последовательность при сборе всего в общее целое. Мы также хотим убедиться в том, что изменения, вносимые сейчас, не затруднят внесение намечаемых на будущее изменений сверх допустимого. Это означает, что внутри нашей организации необходимо применять те же схемы, которые используются в обычном открытом коде, то есть выделить группу надежных исполнителей (основную команду) и ненадежных исполнителей (людей, не входящих в команду предлагающих изменения).

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

Хорошие контролеры проделывают в связи с этим большой объем работы, общаясь непосредственно с теми, кто вносит предложения, и поощряя их хорошие поступки. Плохие контролеры могут воспользоваться своим положением для демонстрации власти над другими или ведения мировоззренческих сражений вокруг произвольных технических решений. Будучи свидетелем обеих форм поведения, хочу сказать только одно: в любом случае на это тратится определенное время. Когда кураторы позволяют ненадежным исполнителям отправлять свои изменения в ваш исходный код, вам нужно решить, стоит ли беспокоиться об издержках на использование контролера — о том, может ли основная команда заняться чем-нибудь более полезным, чем проверка исправлений или изменений.

Зрелость

Чем менее стабильным или зрелым является сервис, тем труднее будет позволять людям, которые не входят в основную команду, присылать исправления или изменения. Пока не сформируется основа сервиса, команда может не знать, как отличить хорошее от плохого, и поэтому стремиться к тому, чтобы узнать, на что должно быть похоже дельное предложение. На этом этапе сервис подвергается значительным изменениям.

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

Инструментарий

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

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

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

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