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

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

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

Так что же со всем этим делать?

Итак, все доказательства, как анекдотические, так и эмпирические, указывают на то, что организационная структура оказывает сильное влияние на характер (и качество) создаваемых нами систем. Но как это понимание сможет нам помочь? Рассмотрим несколько различных организационных ситуаций и разберемся, какое влияние каждая из них может оказать на конструкцию систем.

Адаптация к направлениям обмена данными

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

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

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

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

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

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