Что такое Cloud Native?

Остановите то, что вы делаете, и попросите своих коллег определить термин Cloud Native. Есть хороший шанс, что вы получите несколько различных ответов.

Начнем с простого определения:

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

Cloud Native Computing Foundation предоставляет официальное определение:

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

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

Cloud native — это скорость и гибкость. Бизнес-системы перестают просто обеспечивать бизнес-возможности и становятся инструментами стратегического преобразования, которые ускоряют динамику бизнеса и способствуют росту. Очень важно немедленно вывести новые идеи на рынок.

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

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

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

Основные принципы облачной собственной среды

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

Рис. 1-3. Основные столпы облачно-ориентированных решений

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

Облако

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

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

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

Модель обслуживания сырьевых товаров отличается. Вы подготавливаете каждый экземпляр в виде виртуальной машины или контейнера. Они идентичны и назначают системный идентификатор, например Service-01, Service-02 и т. д. Вы масштабируете, создавая дополнительные экземпляры (масштабирование вширь). Никто не замечает, когда экземпляр становится недоступным.

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

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

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

Современный дизайн

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

Приложение Twelve-Factor

Широко приемлемая методология создания облачных приложений — это Twelve-Factor приложение. В нем описывается набор принципов и методик, которые разработчики следуют созданию приложений, оптимизированных для современных облачных сред. Особое внимание уделяется переносимости между средами и декларативной автоматизации.

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

В следующей таблице описана методология Twelve-Factor.

В книге «За пределами Twelve-Factor App» автор Кевин Хоффман подробно освещает каждый из исходных 12 факторов (написанных в 2011 году). Кроме того, он обсуждает три дополнительных фактора, которые отражают современный дизайн облачных приложений.

Мы будем ссылаться на многие из 12+ факторов в этой главе и на протяжении всей книги.

Платформа Azure с продуманной архитектурой

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

Microsoft Well-Architected Framework предоставляет набор руководящих принципов, которые можно использовать для улучшения качества облачной рабочей нагрузки. Структура состоит из пяти столпов архитектурного совершенства.

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

Микрослужбы

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

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

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

• Каждая из них разрабатывается автономно и может быть развернута независимо.

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

• Каждый выполняется в собственном процессе и взаимодействует с другими, используя стандартные протоколы связи, такие как HTTP/HTTPS, gRPC, WebSockets или AMQP.

• Они объединяются, чтобы создать приложение.

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

Рис. 1-4. Архитектура монолитов против микросервисов

Обратите внимание, как микрослужбы способствуют принципу процессов из приложенияTwelve-Factor, описанного ранее в главе.

Фактор 6 указывает: "Каждая микрослужба должна выполняться в собственном процессе, изолированная от других запущенных служб".

Почему микрослужбы?

Микрослужбы обеспечивают гибкость.

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

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

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

Отличное справочное руководство по пониманию микрослужб — микрослужбы .NET: архитектура для контейнерных приложений .NET. Книга подробно описывает дизайн и архитектуру микрослужб. Это дополнение к эталонной архитектуре микрослужб полного стека, доступной для бесплатной загрузки от Майкрософт.

Разработка микрослужб

Микрослужбы можно создавать на любой современной платформе разработки.

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

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

.NET поддерживается корпорацией Майкрософт и сообществом .NET на GitHub.

Проблемы микрослужб

Хотя распределенные микрослужбы на основе облака могут обеспечить огромную гибкость и скорость, они представляют множество проблем:

коммуникация

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

Как серверные микрослужбы взаимодействуют друг с другом? Можно ли разрешить прямые HTTP-вызовы, которые могут увеличить связь и повлиять на производительность и гибкость? Или вы можете рассмотреть возможность отсоединения обмена сообщениями с технологиями очередей и разделов?

Обмен данными рассматривается в разделе " Шаблоны обмена данными на основе облака ".

устойчивость

Архитектура микрослужб перемещает систему из процесса в внепроцессное сетевое взаимодействие. Что происходит в распределенной архитектуре, когда служба B не отвечает на сетевой вызов от службы A? Или что происходит, когда служба C временно недоступна и другие службы, вызывающие ее, становятся заблокированными?

Устойчивость рассматривается в разделе о устойчивости на основе облака .

Распределенные данные

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

Распределенные данные рассматриваются в разделе "Шаблоны данных на основе облака ".

Секреты

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

Подробности о секретах раскрываются в безопасности, ориентированной на облако.

Управление сложностью с помощью Dapr

Dapr — это распределенная среда выполнения приложения с открытым кодом. Благодаря архитектуре подключаемых компонентов она значительно упрощает инфраструктуру распределенных приложений. Он предоставляет динамический клей, который связывает ваше приложение с предварительно созданными возможностями и компонентами инфраструктуры, предоставляемыми в среде выполнения Dapr. На рисунке 1-5 показан Dapr с высоты 20 000 футов.

рис. 1-5. Дапр на высоте 20 000 футов.

В верхней строке рисунка обратите внимание, что Dapr предоставляет пакеты SDK для конкретных языков для популярных платформ разработки. Dapr версии 1 включает поддержку .NET, Go, Node.js, Python, PHP, Java и JavaScript.

Хотя языково-специфические SDK расширяют возможности разработчика, Dapr является платформо-независимым. Внутри модель программирования Dapr открывает доступ к функциональным возможностям через стандартные протоколы связи HTTP/gRPC. Любая платформа программирования может вызывать Dapr через собственные API HTTP и gRPC.

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

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

В нижней строке выделена переносимость Dapr и разнообразие сред, в которых Dapr может работать.

Заглядывая вперед, Dapr имеет потенциал, чтобы иметь глубокое влияние на разработку облачных приложений.

Контейнеры

В любой беседе о облачной среде естественно услышать термин контейнер. В книге Cloud Native Patterns автор Корнелия Дэвис отмечает, что "Контейнеры являются важным фактором облачного программного обеспечения". Cloud Native Computing Foundation помещает контейнеризацию микрослужб в качестве первого шага в путеводителе Cloud-Native Trail Map — руководство для предприятий, начинающих свое облачное путешествие.

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

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

На рисунке 1–6 показаны три различных микрослужбы, каждая из которых содержит собственный контейнер, все запущенные на одном узле.

Рис. 1-6. Несколько контейнеров, работающих на хосте контейнеров

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

Обратите внимание, насколько хорошо модель контейнера принимает принцип зависимостей из приложенияTwelve-Factor.

Фактор 2 указывает, что "Каждая микрослужба изолирует и упаковывает свои собственные зависимости, охватывая изменения, не влияя на всю систему".

Контейнеры поддерживают рабочие нагрузки Linux и Windows. Облако Azure открыто принимает оба. Интересно, что это Linux, а не Windows Server, который стал более популярной операционной системой в Azure.

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

Почему контейнеры?

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

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

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

Оркестрация контейнеров

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

На рисунке 1–7 показаны задачи управления, которые оркестраторы контейнеров автоматизируют.

Рис. 1-7. Что делают оркестраторы контейнеров

В следующей таблице описаны распространенные задачи оркестрации.

Обратите внимание, как оркестраторы контейнеров принимают принципы удаления и параллелизма из приложенияTwelve-Factor.

Фактор №9 указывает, что "Экземпляры служб должны быть временными, предпочтение отдается быстрым запускам для повышения возможностей масштабирования и корректным завершениям работы для поддержания системы в правильном состоянии". Контейнеры Docker вместе с оркестратором по сути удовлетворяют этому требованию.

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

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

Вы можете разместить собственный экземпляр Kubernetes, но затем вы будете отвечать за подготовку ресурсов и управление ими, что может быть сложным. Облако Azure предоставляет Kubernetes в качестве управляемой службы. Служба Azure Kubernetes (AKS) и Azure Red Hat OpenShift (ARO) позволяют полностью использовать функции и возможности Kubernetes в качестве управляемой службы, не устанавливая и поддерживая ее.

Оркестрация контейнеров подробно описана в статье "Масштабирование Cloud-Native приложений".

Резервные службы

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

На рисунке 1–8 показаны многие распространенные службы поддержки, которые используют облачные системы.

Рис. 1-8. Общие службы резервного копирования

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

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

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

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

Фактор 4 указывает, что службы резервного копирования должны предоставляться через адресируемый URL-адрес. Это различает ресурс от приложения, что позволяет ему быть взаимозаменяемым".

Фактор №3 указывает, что "Сведения о конфигурации перемещаются из микрослужбы и внешне обрабатываются с помощью средства управления конфигурацией вне кода".

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

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

В заключении, вспомогательные службы также способствуют принципу без сохранения состояния из приложенияTwelve-Factor, о котором шла речь ранее в главе.

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

Службы резервного копирования рассматриваются в шаблонах данных на основе облака и шаблонах обмена данными на основе облака.

Автоматизация

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

Введите общепринятую практику инфраструктуры в виде кода или IaC.

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

Автоматизация инфраструктуры

Такие инструменты, как Azure Resource Manager, Azure Bicep, Terraform из HashiCorp и Azure CLI, позволяют декларативно выполнять скрипт облачной инфраструктуры. Имена ресурсов, местоположения, вместимости и секреты параметризованы и динамичны. Скрипт версионируется и добавляется в систему управления версиями в качестве артефакта вашего проекта. Вы вызываете скрипт для подготовки согласованной и воспроизводимой инфраструктуры в системных средах, таких как QA, промежуточная и рабочая.

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

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

Автоматизация развертываний

Приложение Twelve-Factor, описанное ранее, вызывает отдельные шаги при преобразовании завершенного кода в работающее приложение.

Фактор #5 указывает, что "Каждый выпуск должен обеспечить строгое разделение между этапами сборки, выпуска и запуска. Каждый из них должен быть помечен уникальным идентификатором и поддерживать возможность возврата.

Современные системы CI/CD помогают выполнить этот принцип. Они предоставляют отдельные этапы сборки и доставки, которые помогают обеспечить согласованный и качественный код, доступный пользователям.

На рисунке 1–9 показано разделение во время процесса развертывания.

Рис. 1-9. Этапы развертывания в конвейере CI/CD

На предыдущем рисунке обратите особое внимание на разделение задач:

1. Разработчик создает функцию в своей среде разработки, итерируя то, что называется "внутренним циклом" кода, запуска и отладки.
2. По завершении этот код отправляется в репозиторий кода, например GitHub, Azure DevOps или BitBucket.
3. При отправке запускается этап сборки, который преобразует код в двоичный артефакт. Работа реализуется с конвейером непрерывной интеграции (CI ). Он автоматически создает, тестирует и упаковает приложение.
4. Этап выпуска программного обеспечения выбирает бинарный объект, применяет сведения о конфигурации внешнего приложения и окружающей среды и создает устойчивый релиз. Выпуск развертывается в указанной среде. Работа реализуется с конвейером непрерывной доставки (CD ). Каждый выпуск должен быть идентифицирован. Вы можете сказать: "Это развертывание выполняется в выпуске 2.1.1 приложения".
5. Наконец, выпущенная функция выполняется в целевой среде выполнения. Выпуски являются неизменяемыми, что означает, что любое изменение требует создания нового выпуска.

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

Инфраструктура как код и автоматизация развертывания, а также GitHub и Azure DevOps подробно рассматриваются в DevOps.