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

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

В связи с этим стоит также заметить, что, основываясь как минимум на наблюдении авторов ранее упомянутого отчета Exploring the Duality Between Product and Organizational Architectures, можно сказать: если организация, создающая систему, имеет менее крепкие связи (к примеру, она состоит из географически разобщенных команд), то создаваемые этой организацией системы будут, как правило, иметь более модульную структуру и поэтому, будем надеяться, обладать меньшей связанностью. Поддерживать в географически разбросанной организации тенденцию получения более тесной интеграции за счет того, что одна команда владеет сразу несколькими сервисами, очень трудно.

Владение сервисом

Что я подразумеваю под владением сервисом? В общем смысле это означает, что команда, владеющая сервисом, несет ответственность за внесение изменений в этот сервис. Команда должна иметь возможность свободно проводить реструктуризацию кода по собственному усмотрению, если только эти изменения не нарушат условий использования сервисов. Для многих команд права владения распространяются на все аспекты сервиса, от исходных требований до создания, развертывания и сопровождения приложения. Эта модель особенно широко распространена при работе с микросервисами: небольшой команде намного легче владеть небольшим сервисом. Возросший уровень владения приводит к росту автономности и скорости поставки. Когда одна команда отвечает за развертывание и сопровождение, это означает, что у нее есть стимул создавать сервисы, которые потом можно будет легко развернуть, то есть опасения насчет «перебрасывания чего-нибудь через забор» развеиваются, когда это что-то просто некому перебрасывать!

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

Побудительные мотивы для создания общих сервисов

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

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

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

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

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

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