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

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

Слишком большие трудности разбиения на части

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

Команды разработки функций

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

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

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

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

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

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

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

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