Микросервисы. От архитектуры до релиза E-Book

Ронни Митра

• Herausgeber: Питер
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Russisch

Seitenzahl: 376

Veröffentlichungsjahr: 2023

Beschreibung

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

Leseprobe

Ронни Митра, Иракли Надареишвили

Микросервисы. От архитектуры до релиза

Переводчик С. Черников

Ронни Митра, Иракли Надареишвили

Микросервисы. От архитектуры до релиза. — СПб.: Питер, 2023.

ISBN 978-5-4461-1884-7

© ООО Издательство "Питер", 2023

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

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

Ронни Митра

Лукасу, родившемуся вскоре после того, как мы начали работать над этой книгой. Его улыбки придали мне сил закончить этот труд в разгар глобальной пандемии. Моей жене Ане за ее поддержку и моим замечательным студентам из Университета Темпл в Филадельфии, которые любезно «протестировали» ранние версии многих материалов книги.

Иракли

Предисловие

Десять лет назад команда архитекторов программного обеспечения ввела термин «микросервисы», определяя эволюционировавший стиль архитектуры программного обеспечения (ПО). С тех пор было выпущено множество курсов, видеороликов и книг, посвященных микросервисам. Фактически в 2016 году мы стали соавторами книги Microservice Architecture (https://learning.oreilly.com/library/view/microservice-architecture/9781491956328) — вводного руководства по микросервисам.

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

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

Для кого эта книга

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

Что вам понадобится

Поскольку сфера применения микросервисов довольно велика, мы используем ряд различных инструментов и методов. Если вы решите опробовать примеры из книги, то установите следующие инструменты и платформы или оформите подписку на них:

• Docker;

• Redis;

• MySQL;

• GitHub;

• GitHub Actions;

• Terraform;

• Amazon Web Services;

• kubectl;

• Helm;

• Argo CD.

Инструкции о том, где и как получить эти инструменты, мы представим в соответствующих разделах.

Условные обозначения

В этой книге используются следующие условные обозначения.

Курсив

Курсивом выделены новые термины.

Моноширинный шрифт

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

Моноширинный жирный шрифт

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

Моноширинный курсив

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

Шрифт без засечек

Используется для обозначения URL, адресов электронной почты, названий кнопок, названий клавиш и их сочетаний, элементов интерфейса.

Этот рисунок указывает на совет или предложение.

Этот рисунок указывает на общее замечание.

Этот рисунок указывает на предупреждение.

Использование примеров кода

Дополнительный материал (примеры кода, упражнения и т.д.) можно скачать здесь: https://oreil.ly/MicroservicesUpandRunning.

Если у вас есть технический вопрос или проблема, касающиеся примеров кода, то, пожалуйста, напишите на электронную почту [email protected].

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

Мы рекомендуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание авторов, издательства и ISBN.

За получением разрешения на использование значительных объемов программного кода из книги обращайтесь по адресу [email protected].

Благодарности

Мы хотели бы поблагодарить наших редакторов Мелиссу Поттер и Дебору Бэкер, а также команду O’Reilly, без которой мы никогда не закончили бы книгу. Спасибо Питу Ходгсону, Крису О’Деллу, Лоринде Брэндон, Джей Пи Моргенталю, Майку Андерсену и Дэвиду Батленду за вдохновение и содержательные отзывы. И наконец, мы хотели бы поблагодарить компании Capital One и Publicis Sapient за поддержку, которую они оказали, позволив нам воплотить нашу идею в жизнь.

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Глава 1. Навстречу архитектуре микросервисов

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

В последнее время популярность создания программного обеспечения в виде микросервисов резко возросла. В начале 2010-х годов термин «микросервисы» был введен для описания нового стиля архитектуры ПО. Приложения, реализованные в этом стиле, создаются с помощью небольших независимых компонентов, которые работают вместе. С тех пор темпы внедрения стиля микросервисов резко возросли. Стартапы, крупные и мелкие компании изучают и внедряют микросервисные архитектуры. Растущая экосистема инструментов, сервисов и решений в данной области свидетельствует о ее широкой популярности. Когда мы писали эту книгу, специалисты Allied Market Research (https://oreil.ly/cugsz) предсказали, что мировой рынок микросервисных архитектур вырастет до 8,07 млрд долларов США в 2026 году с нынешних 2,07 млрд долларов США. Такие цифры указывают на большой интерес к микросервисам и их широкое внедрение.

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

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

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

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

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

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

Что такое микросервисы

Не существует общепринятого официального, канонического определения микросервисов. Хорошей отправной точкой является статья Джеймса Льюиса и Мартина Фаулера о микросервисах 2014 года (https://oreil.ly/guhCP). Авторы описывают микросервисы как:

«подход к разработке единого приложения в виде набора небольших сервисов, работающих в отдельных процессах и взаимодействующих с применением упрощенных механизмов. [...] построенных вокруг бизнес-потребностей и развертываемых независимо с помощью полностью автоматизированного механизма».

Суть статьи Льюиса и Фаулера — в описании набора из девяти характеристик, которыми обладают микросервисы. Список начинается с основной микросервисной характеристики: компонентное представление с помощью сервисов, что означает разбиение приложения на более мелкие сервисы. От него авторы переходят к широкому спектру возможностей. Они обосновывают необходимость организационного и управленческого проектирования с учетом особенностей организации, связанных с бизнес-потребностями и децентрализованным управлением. Авторы намекают на DevOps и методы гибкой разработки, когда внедряют автоматизацию инфраструктуры и продукты, а не проекты. В дополнение авторы определяют несколько ключевых принципов архитектуры, таких как умные конечные точки и тупые каналы (smart endpoints and dumb pipes), проектирование с учетом сбоев и эволюционное проектирование.

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

Для сравнения предлагаем еще одно определение микросервисов из книги Microservice Architecture, написанной Иракли Надареишвили, Ронни Митрой, Мэттом Макларти и Майком Амундсеном (O’Reilly) (https://learning.oreilly.com/library/view/microservice-architecture/9781491956328).

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

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

Это всего лишь два примера из множества определений микросервисов. Большинство определений в целом схожи, но каждое из них немного отличается по своей направленности.

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

1. Архитектура приложения в основном состоит из машинно-вызываемых «сервисов», доступных в сети.

2. Размеры (или границы) сервисов — важный критерий проектирования, на который влияют факторы времени выполнения, времени разработки и персонала.

3. Программная система, организация и способ работы оптимизированы для достижения цели.

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

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

Сокращение затрат на координацию

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

Следует отметить, что существует множество способов увеличить скорость разработки ПО, и организация программного обеспечения в виде микросервисов — лишь один из вариантов. Например, можно быстро создать систему, выполнив работу поверхностно и накопив «технический долг» (https://oreil.ly/PBMHU), с которым предполагается разобраться позже. Или же можно меньше внимания уделить стабильности и безопасности и просто выпустить свой продукт в мир. В отдельных ситуациях и для некоторых предприятий это разумные подходы.

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

Проблема затрат на координацию

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

Рис. 1.1. Примерная временная шкала сложного проекта с координационными точками соприкосновения

Представьте, что Джейн — руководитель группы, отвечающей за бухгалтерский учет. Ее команда только что закончила спринт и зависит от компонента, который разрабатывается командой, отвечающей за модуль отгрузки, во главе с Тайроном. Поскольку их проектные планы независимы, вполне возможно, что его команда на самом деле не закончила реализацию необходимого компонента. На данный момент у Джейн есть два варианта: либо дожидаться готовности компонента (отдавая приоритет безопасности и жертвуя скоростью) и провести надлежащее интеграционное тестирование, либо положиться на согласованный контракт взаимодействий между ее компонентом и компонентом Тайрона, предполагая, что его команда выпустит обновленную версию компонента точно в срок. Выбрав второй вариант, Джейн сможет работать без остановки, увеличивая скорость работы своей команды, но потенциально ставя под угрозу общую безопасность системы, поскольку интеграционное тестирование не проводилось на самом раннем возможном этапе и было сделано предположение об «удачном пути»1.

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

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

Важно понимать, что работа по созданию хороших микросервисов направлена на минимизацию координации. Создавать сложные распределенные системы, такие как микросервисные архитектуры, непросто, и в моменты сомнений мы всегда должны спрашивать себя: «Решение, с которым я сталкиваюсь, снизит затраты на координацию моих команд или нет?» Правильный ответ будет гораздо очевиднее, если мы рассмотрим решения с точки зрения затрат на координацию.

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

Сложные компромиссы

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

• Длительные циклы обратной связи. Одна из больших проблем — сложность оценки эффективности решений в системе микросервисов. Решения, принимаемые сегодня, могут повлечь проблемы, которые проявятся гораздо позже. Например, на старте вы можете решить использовать общую библио­теку, чтобы упростить реализацию взаимодействий между сервисами. Но со временем может выясниться, что поддержание ее в актуальном состоянии во всех микросервисах и командах оказывается огромной проблемой. Суть в том, что трудно оценить, как повлияет принимаемое вами решение, пока не возникнут сложности. Это затрудняет оценку и выбор вариантов.

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

• Аналитический паралич. Сложность проектируемой системы вкупе с длительными циклами обратной связи обнажает трудности построения микросервисной архитектуры. Решения, которые приходится принимать, имеют большое влияние и трудно поддаются оценке. Это может привести к бесконечным спекуляциям, обсуждениям и оценке архитектурных решений из-за страха создать неправильную систему. Вместо того чтобы создать систему, способную удовлетворить требования бизнеса, мы оказываемся в подвешенном состоянии, пытаясь смоделировать бесконечные последствия нашего выбора. Это состояние широко известно как аналитический паралич. Мешает также наличие в Интернете множества страшных историй, советов в стиле «наклейки на бампер» и противоречивых рекомендаций по созданию микросервисных архитектур.

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

Обучение на практике

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

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

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

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

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

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

Модель приобретения навыков Дрейфуса

Начать обучение, следуя инструкциям, — проверенный и верный путь к приобретению опыта. Согласно статье FiveStage Model of Adult Skill Acquisition Стюарта и Хьюберта Дрейфусов (https://oreil.ly/vs3ao), первый этап включает в себя следование конкретным рекомендациям для получения знаний и наработки собственного опыта.

Модель микросервисов «От архитектуры до релиза»

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

• Структура команды. Мы приступим к работе в главе 2, начав с людей, которые должны участвовать в создании системы микросервисов. Раскроем проблемы эффективного построения команды и назовем главные факторы, влияющие на координацию микросервисов. Кроме того, представим коман­ды, которые будем использовать в наших примерах, и инструмент Team Topologies («Топологии команд»), который поможет их создать.

• Структура микросервисов. После создания команд мы представим в главе 3 SEED(S)-процесс. Этот процесс проектирования позволяет создавать микросервисы, которые удовлетворяют потребности пользователей и потребителей и отличаются удобными интерфейсами и поведением. Затем, в главе 4, мы рассмотрим проблему определения правильных границ для наших микросервисов. Мы также представим некоторые важные концепции предметно-ориентированного проектирования и будем использовать процесс, называемый Event Storming, для выбора «правильного размера» наших сервисов.

• Структура данных. Данные — один из самых сложных аспектов проектирования микросервисов. В главе 5 мы посмотрим, какие свойства данных необходимо учитывать в системе микросервисов, представим концепцию независимости данных и заложим основу архитектуры данных для нашего проекта.

• Облачная платформа. Наша реализация микросервисов будет построена на облачной инфраструктуре. В главе 6 мы представим и реализуем принципы неизменяемой инфраструктуры и инфраструктуры как кода (infrastructure as code, IaC) в качестве основы для инфраструктуры микросервисов. Кроме того, мы представим облачную платформу AWS и создадим конвейер CI/CD на основе GitHub Actions. Затем, в главе 7, с помощью этого конвейера мы спроектируем и реализуем инфраструктуру микросервисов на базе AWS — она будет включать сеть, кластер Kubernetes и средство развертывания GitOps.

• Разработка микросервисов. Настроив инфраструктуру, мы погрузимся в задачи по разработке микросервисов. В главе 8 мы сначала опишем принципы и инструменты, необходимые для достижения успеха. Затем в главе 9 реализуем два независимых разнородных микросервиса для нашего приложения.

• Релиз и внесение изменений. В главе 10 мы соберем все вместе и развернем один из созданных нами микросервисов на облачной платформе. Для этого воспользуемся набором технологий, включая DockerHub, Kubernetes, Helm и Argo CD. Наконец, после выпуска рассмотрим систему в целом в главе 11.

Разработанная нами модель основана на пяти руководящих принципах, входящих в манифест «Приложение двенадцати факторов» (https://12factor.net). Если вам интересно, можете прочитать о руководящих принципах нашей модели в репозитории книги на GitHub (https://oreil.ly/Micro­servicesUpand­Run­ning).

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

Решения, решения...

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

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

Чтобы удовлетворить эту потребность, мы воспользуемся инструментом под названием реестр архитектурных решений (architecture decision record, ADR). Мы точно не знаем, кто изобрел термин ADR и когда он был впервые использован, но идея документирования проектных решений существует давно. Проблема заключается в том, что большинство людей не тратят на это время. По нашему опыту, ADR — чрезвычайно полезный инструмент, позволяющий прояснить принимаемые решения.

Каждая запись в реестре решений должна включать четыре важных компонента.

• Контекст. В чем заключается проблема, которую мы пытаемся решить? Какие ограничения имеются? Запись о принятом решении должна давать краткие ответы на эти вопросы. Благодаря этому мы сможем понять обоснование решения и почему его, возможно, потребуется обновить.

• Альтернативы. Решение не является таковым, если нет выбора, который нужно сделать. Хорошая запись о решении должна описывать возможные альтернативы. Это поможет нам лучше понять контекст и «пространство выбора» в момент принятия решения.

• Выбор. В основе решения лежит выбор. Каждая запись решения должна документировать сделанный выбор.

• Влияние. Решения имеют последствия, и записи решений должны доку­ментировать самые важные из них. Какие достоинства и недостатки имеет решение? Как выбор решения повлияет на рабочие подходы или на другие решения?

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

В нашем демонстрационном проекте мы будем использовать формат, называемый упрощенной записью архитектурного решения (light­weight architectural decision record, LADR). Формат LADR, предложенный Майклом Нейгардом (https://oreil.ly/_mVoC), позволяет кратко описать принятое решение. Познакомимся с LADR поближе, создав запись вместе.

Если вы решите работать с другим форматом, отличным от LADR, то воспользуйтесь большим перечнем форматов ADR и шаблонов, которые предлагает Джоэл Паркер Хендерсон (https://oreil.ly/T3Tc-).

Создание упрощенной записи архитектурного решения

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

Записи LADR оформляются на языке разметки Markdown (https://oreil.ly/oRyx0), который обеспечивает элегантный и простой способ написания документации. Самое замечательное в Markdown, что он не затрудняет чтение текста и большинство популярных инструментов знают, как его визуализировать. Например, Confluence, GitLab, GitHub и SharePoint могут представлять текст в формате Markdown и в виде удобочитаемого документа.

Чтобы создать первый документ LADR на основе Markdown, откройте текстовый редактор и создайте новый документ. Первое, что мы сделаем, — определим структуру.

Добавьте следующий текст в свой файл LADR:

# OPM1: Использовать ADRS для документирования решений

## Статус

Принято

## Контекст

## Решение

## Следствия

Это ключевые разделы записи о принятом решении. Символы # в начале строк — это маркеры Markdown, подсказывающие анализатору, что эти строки представляют собой заголовки. Обратите внимание: мы присвоили этому решению название, кратко описывающее его. Кроме того, название решения начинается со странной аббревиатуры OPM1. Это всего лишь краткий код формы, который поможет нам обозначить и понять, к какой части системы относится решение. В данном случае OPM1 указывает, что это первое наше решение и оно связано с операционной моделью (OPerating Model).

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

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

## Контекст

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

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

## Решение

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

* инструменты управления проектами (отвергнуто, поскольку мы бы не хотели устанавливать дополнительные инструменты);

* неформальное ведение записей или сарафанное радио (ненадежно).

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

## Следствия

* Нам потребуется создавать записи решений для ключевых решений.

* Понадобится инструмент для управления файлами записей решений как исходным кодом.

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

Ключевое решение: применять ADR для отслеживания решений

Мы будем создавать записи в реестре ADR для фиксации ключевых решений, принятых при проектиро­вании и создании нашей системы.

Полные версии записей о принятии решений вы найдете в репозитории GitHub для этой книги (https://github.com/implementing-microservices/ADRs).

Резюме

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

Чтобы помочь решить эти проблемы, мы разработали модель микросервисов «От архитектуры до релиза», которая ускорит процесс обучения разработчиков. Рассмотрели аспекты модели и темы, которые обсудим. Наконец, представили концепцию реестра архитектурных решений (ADR), который планируем использовать далее в книге.

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

1От англ. happy path — сценарий по умолчанию, в котором отсутствуют исключительные ситуации или ошибки. — Примеч. пер.

Глава 2. Разработка операционной модели микросервисов

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

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

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

Это и есть тема, которую мы рассмотрим в текущей главе: взаимосвязь между командами и реализациями микросервисов. Далее мы представим инструмент Team Topologies — и к концу главы получим организационную структуру коман­ды, которую сможем использовать как основу для дальнейшего обсуждения.

На самом деле вам необязательно собирать людей и команды, которые мы определим, чтобы следовать нашей модели создания микросервисов «От архитектуры до релиза».

Начнем с того, что обсудим, почему команды и их структура имеют первоочередную важность.

Почему команды и люди важны

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

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

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

Идея о важности структуры и культуры важна и не нова. Мел Конвей красноречиво описал влияние структуры команды на системный проект в своей известной статье How Do Committees Invent? (https://oreil.ly/oRyx0). Всем знаком закон Конвея, который гласит:

«Любая организация проектирует систему (определяемую в широком смысле), которая копирует структуру коммуникаций в этой организации».

Приписывается Фреду Бруксу

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

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

Размер команды

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

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

Билл Гор, соучредитель компании W.L. Gore по производству материалов Gore-Tex, ограничил размер команд в компании в целях сохранения их эффективности. Чтобы добиться этого, он установил обязательное ограничение по размеру: у каждого члена команды должны быть личные отношения (https://oreil.ly/wduQE) друг с другом. Когда команда достигает такого масштаба, что ее участники не знают друг друга, подразделение считается слишком большим.

Антрополог Роберт Данбар в своих исследованиях социального поведения шимпанзе заметил, что размеры групп шимпанзе коррелируют с размером их мозга. Экстраполируя эти результаты на свое понимание человеческого мозга, исследователь определил, каких размеров должны быть команды людей. Число Данбара (https://oreil.ly/-DbyT) определяет, что, исходя из размера нашего мозга, мы можем комфортно поддерживать только 150 стабильных отношений.

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

Возможно, самым известным руководством к формированию команд стало «правило двух пицц» (https://oreil.ly/ccT85), сформулированное генеральным директором Amazon Джеффом Безосом. В нем говорится, что команда должна быть настолько маленькой, чтобы ее можно было накормить двумя пиццами. Хотя конкретные детали о размере пиццы и аппетите участников неясны, такая команда, вероятно, состоит из 5–15 человек. Именно такой диапазон описывает Данбар, и именно в такой команде есть хорошие шансы сохранить эвристику личных отношений, которую описывает Гор.

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

Ключевое решение: размер команд должен быть ограничен

В каждой команде, работающей в нашей системе, должно быть не более восьми человек.

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

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

Мастерство команды

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

Правда в том, что на эти вопросы трудно дать универсальные ответы. Это потому, что люди и культура труда часто являются самой уникальной чертой места, где вы работаете. Например, некоторые компании тратят много денег, чтобы нанять 1 % лучших специалистов в области технологий со всего мира. Другие могут нанимать местных талантов, предполагая их профессиональный рост и обучение на рабочем месте у небольшого количества экспертов. Хорошая структура команды в этих двух случаях, вероятно, будет выглядеть совершенно по-разному.

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

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

Кросс-функциональные команды существуют давно, по крайней мере с 1950-х годов, и впервые появились в страховой компании Northwestern Mutual.

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

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

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

Ключевое решение: должны быть определены принципы членства в команде

Команды должны быть кросс-функциональными и состоять только из тех, кто может повысить ценность результатов, сервисов или продукта команды.

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

Взаимодействие между командами

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

Было бы неплохо, если бы наши команды могли действовать полностью автономно и независимо. Будь у команд свобода принятия решений по проектированию, разработке, тестированию и развертыванию, не было бы никаких «организационных трений», которые замедляли бы работу. Но, по нашему опыту, это непрактичный метод работы.

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

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

Можно построить организацию, которая эффективно обеспечивает независимость и автономию команды за счет самоорганизации. Например, основоположник микросервисов Фред Джордж описал метод, который он называет Programmer Anarchy (https://oreil.ly/C1N0f). В этом случае технические специалисты обладают полной автономией (и ответственностью) в формировании команд, выборе работы и разработке собственных решений. Но, по нашему опыту, большинству корпоративных организаций трудно постоянно придерживаться этого правила.

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

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

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

Ключевое решение: когда определять структуру команд и модели координации

Обсуждать структуру команды и способы координации нужно до проектирования архитектуры системы или микросервисов. Модели команды и способы взаимодействия должны постоянно обновляться и совершенствоваться в течение всего срока службы системы.

Мы поговорим об этом в оставшейся части главы. Но сначала представим полезный инструмент для проектирования моделей команд микросервисов — Team Topologies.

Введение в Team Topologies

Поскольку мы собираемся начать нашу проектную работу, сосредоточившись на командах, нам понадобится способ каталогизации наших решений и информирования о них. Существует множество способов документирования структуры команды. Для создания модели мы используем инструмент проектирования Team Topologies («Топологии команд»).

Team Topologies (https://teamtopologies.com) — подход к проектированию, изобретенный Мэтью Скелтоном и Мануэлем Пейсом. Нам нравится использовать его, поскольку он предусматривает формальный язык для обсуждения структуры команды, позволяя делать особый акцент на том, как команды работают друг с другом.

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

Далее мы рассмотрим различные части подхода топологий команды, начиная с типов команд, которые можем определить.

Тип команды

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

• Команда, ориентированная на поток (потоковая),владеет и управляет модулем системы. Ключевой характеристикой этой команды является постоянное предоставление чего-то, что имеет отношение к бизнес-организации. Потоковая команда — воплощение цитаты (https://oreil.ly/bIwkK) технического директора Amazon Вернера Фогеля об обязанностях команд Amazon: «Ты создал, ты и управляешь». Потоковые команды не распускаются после релиза. Вместо этого они продолжают управлять и внедрять «поток» изменений, улучшений и исправлений в результаты своего труда. Например, команды, работающие с микросервисами, обычно являются потоковыми, поскольку постоянно совершенствуют принадлежащие им сервисы.

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

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

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

Имея представление об этих четырех типах команд, мы можем начать использовать тот тип коммуникации, к которому хотели бы подвести свои команды. Чтобы действительно объяснить нашу структуру команды, мы должны обсудить еще одну часть модели: способы взаимодействия команд. Их мы и рассмотрим далее.

Режимы взаимодействия

Наша цель при проектировании команд для сборки микросервисов — уменьшить объем координации, необходимый для выполнения работы. Типы согласно топологии помогают определить основные характеристики команды. Чтобы действительно понять, как и где можно снизить затраты на координацию, нужно четко сформулировать, как наши команды координируют свои действия друг с другом. Именно здесь и пригодятся режимы взаимодействия согласно топологии команд. В своей книге Скелтон и Пейс обсуждают три режима взаимодействия, которые описывают различные уровни координации.

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

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

• «Все как сервис» (X-as-a-service, XaaS).Иногда сотрудничество команд приобретает характер взаимодействия между потребителем и поставщиком. При таком типе взаимодействия одна команда предоставляет услугу другим командам в организации с минимальным уровнем координации. Обычно такие взаимодействия имеют место, когда команда готовит общий процесс, документ, библиотеку, API или платформу. Взаимодействия типа XaaS, как правило, хорошо масштабируются, поскольку требуют меньшей координации. Они также идеально подходят для команд разработки платформы, но другие типы команд тоже могут использовать этот режим. Например, команда поддержки архитектуры может задокументировать список рекомендуемых шаблонов программного обеспечения и предложить их всем командам, работающим над микросервисами, в модели «Шаблоны как сервис».