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

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

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

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

Узкие места, касающиеся вопросов поставки

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

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

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

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

Но есть и еще одна модель, которая может неплохо работать в наших интересах.

Семейственный открытый код

А что, если мы приложили максимум усилий, но так и не смогли найти способа, исключающего применение нескольких общих сервисов? В таком случае вполне определенный смысл может иметь правильное внедрение модели семейственного открытого кода.

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

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

Роль кураторов