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

История гласит, что, когда Мелвин Конвей отправил свою статью на эту тему в журнал Harvard Business Review, редакция ее не приняла, заявив, что его утверждение ничем не подкреплено. Я же наблюдал подтверждение этой теории на практике во многих различных ситуациях настолько часто, что принял ее за истину. Но вам не нужно принимать мои слова на веру: после того как Конвей вывел эту теорию, в данной области был проделан большой объем работы. Для изучения взаимосвязанности организационной структуры и создаваемой ею системы проведен целый ряд исследований.

Организации со слабыми и сильными связями

В исследовании Exploring the Duality Between Product and Organizational Architectures (Harvard Business School) Алан Маккормак (Alan MacCormack), Джон Руснак (John Rusnak) и Карлисс Болдуин (Carliss Baldwin) рассмотрели несколько различных программных систем, которые были приблизительно классифицированы как созданные организациями со связями, имеющими либо слабый, либо сильный характер. Думаю, что в организациях с сильными связями коммерческий продукт обычно подкрепляется четкой выверенностью целей и представлений, а организации со слабыми связями хорошо представлены распределенными сообществами, разрабатывающими продукты с открытым кодом.

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

Windows Vista

Компания Microsoft, изучая влияние своей организационной структуры на качество конкретного продукта, а именно Windows Vista, провела собственное эмпирическое исследование. В частности, исследователи проанализировали несколько факторов с целью определения надежности отдельно взятого компонента системы[4]. После изучения ряда показателей, включая такой часто используемый показатель качества, как сложность кода, они пришли к выводу, что показатели, связанные с организационной структурой, оказались статистически наиболее значимыми оценками.

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

Netflix и Amazon

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

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

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

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

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

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