Из чего строят Cloud Native приложения в 2023 году

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

«Классический» цикл разработки монолитных приложений неизбежно сталкивается с рядом проблем: 

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

Cloud Native предлагает другую парадигму создания и развития приложений. В ней приложение можно легко обновлять без ущерба для клиента.

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

Путь к Cloud Native

В 2015 году на заре становления Cloud Native появилась классификация приложений по степени готовности к облаку. 

1. Cloud Ready. Приложению не требуется постоянный доступ к диску, оно контейнеризировано, а управление с внешними сервисами осуществляется за счет конфигов. Есть возможность подключить сторонние службы. 
2. Cloud Friendly. Приложение 12 факторов. Здесь появляется горизонтальное масштабирование за счет ресурсов облачной платформы.
3. Cloud Resilient. Решения, построенные так, что увеличение нагрузки или отказ отдельных компонентов не приведет к недоступности сервиса. 
4. Cloud Native. Микросервисная архитектура, при проектировании используется принцип API-first.

Теперь за развитием нативного подхода к созданию приложений и сервисов присматривает целое сообщество — Cloud Native Computing Foundation или CNCF.

Что такое CNCF

CNCF — это фонд от Linux Foundation, который распространяет open source-компоненты Cloud Native приложений. Платформа появилась в 2015 году, когда все больше компаний перешли на микросервисную архитектуру. Сегодня CNCF помогают развивать такие компании, как Intel, Microsoft, VMware, и Oracle. Фонд поддерживает организации, развивающие проекты вроде Kubernetes, Prometheus и CoreDNS.

Что такое Cloud Native

Сообщество определяет так: Cloud Native — это подход для создания и запуска приложений в динамических средах (все типы облаков), который обязательно использует контейнеры, service mesh, микросервисы и неизменяемую IT-инфраструктуру (immutable infrastructure). В таком подходе к управлению развертыванием сервисов и ПО на IT-ресурсах компоненты заменяются, а не изменяются. Приложение или услуги фактически развертываются заново при каждом изменении.

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

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

Ключевые признаки Cloud Native приложений

• Контейнеризация и оркестрация.
• Следование практикам CI/CD.
• Масштабируемость ресурсов в зависимости от нагрузки.
• Отказоустойчивость и быстрое автоматическое восстановление в случае глобального сбоя.
• Наличие систем мониторинга состояний и производительности.

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

Все эти вводные данные указывают на то, что CNCF пока доверяет работу с контейнерами только Kubernetes, который сочетает все вышеперечисленное. Например, внедрение Kubernetes помогло Adidas проводить релизы от трех до четырех раз в день, вместо недельных запусков.

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

Архитектура Cloud Native: основные атрибуты приложений

Архитектура Cloud Native объединяет компоненты, которые можно использовать для разработки масштабируемых облачных приложений — их же называют атрибутами. Перечислим основные из них.

• Неизменяемость инфраструктуры. Серверы остаются неизменными после развертывания. При масштабировании сервис автоматически переносится на более производительную машину.
• Микросервисы. Приложение состоит из независимых программных компонентов (микросервисов), каждый из которых сосредоточен на определенной задаче.
• API. Работа с микросервисами осуществляется с помощью специального программного интерфейса, который их объединяет и обеспечивает обмен данными.
• Сетка сервиса. У Cloud Native приложения должен быть программный уровень, который управляет связями между микросервисами. Именно сетка сервиса позволяет разработчикам внедрять дополнительные компоненты без написания нового кода и «велосипедов».
• Контейнеры. Базовая вычислительный блок, в который «упаковывают» микросервисы для консолидации. В результате они работают независимо от основной операционной системы.

Преимущества приложений Cloud Native

Отлично — мы разобрались с устройством Cloud Native приложений. Но зачем их строить и почему бизнес переходит для Cloud Native? Выделим основные преимущества.

Ускоренная разработка

Как говорилось выше, один из признаков Cloud Native — высокий уровень автоматизации, который ускоряет разработку и увеличивает количество релизов. Последнее хорошо видно на примере Adidas.

Независимость от платформы

Разработчикам не нужно думать о совместимости оборудования: облачная среда полностью настроена провайдером. Поэтому можно сфокусироваться на бизнес-задачах и высокоуровневой разработке.

Экономичность

Клиент (разработчик) платит только за потребляемые ресурсы — по модели pay-as-you-go. Это позволяет перевести капитальные расходы в операционные, а также сэкономить на содержании инфраструктуры.

Отказоустойчивость

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

Состояния и изоляция

Любое приложение может быть Cloud Native? Чтобы разобрать этот момент, посмотрим на различные типы приложений.

В первую очередь, определим приложения по типу состояний.

→ Stateless. В приложениях такого типа ответ сервера не зависит от какого-либо состояния. Данные о прошлых операциях или ссылки на них не сохраняются. Каждая операция выполняется как первая и единственная. 

Приложения без статического состояния предоставляют одну услугу или функцию. Они используют сеть доставки контента (CDN) и веб-серверы для обработки этих краткосрочных запросов: один запрос — один ответ. 

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

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

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

Во вторую очередь, важно разделять изолированные и связанные приложения. 

→ Изолированные. Не взаимодействуют со сторонними сервисами, например, с платежными системами.

→ Связанные. Используют один или несколько внешних сервисов.

Определение того, является ли приложение Cloud Native, зависит от обоих этих факторов. 

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

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

Cloud Native для всех

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

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

Запасной вариант

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

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

Для решения этой задачи стали появляться многочисленные механизмы оркестрации. Несмотря на сложность администрирования, Kubernetes оказался надежнее и удобнее конкурентных решений. Сравнительный анализ K8s и Docker Swarm можно посмотреть здесь. 

Kubernetes и Cloud Native

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

В 2018 году Kubernetes первым получил статус Graduated Project (завершенный проект) в терминологии CNCF. Процесс развития K8s во много повлиял и на саму среду, изменив способы масштабного развертывания программного обеспечения, методы работы и взаимодействие корпораций с крупными проектами с открытым исходным кодом.

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

Kubernetes Native 1.25 и COSI

Объектное хранение данных в последние годы набирает популярность в качестве альтернативы файловым системам и блочному устройству. 

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

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

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

Цель COSI — стандартизировать использование объектного хранилища, чтобы обеспечить следующие преимущества:

• Самообслуживание — четкое разграничение между администрированием и операциями (DevOps) для обеспечения самообслуживания для DevOps-инженеров.
• Переносимость — нейтральность к поставщикам обеспечивается благодаря переносимости между кластерами Kubernetes и поставщиками Object Storage.
• Переносимость между поставщиками возможна только в том случае, если оба поставщика поддерживают общий datapath-API.
• Kubernetes Native — использование API Kubernetes для предоставления, конфигурации и управления бакетами.

Контроллер COSI определяет три API Kubernetes, предназначенных для управления данными в бакетах:

• Bucket,
• BucketClass,
• BucketClaim.

Кроме этого, есть еще два API для управления доступом к бакетам:

• BucketAccess,
• BucketAccessClass.

В двух словах, Bucket и BucketClaim можно считать аналогичными PersistentVolume и PersistentVolumeClaim соответственно. Аналогом BucketClass в мире файловых/блочных хранилищ является StorageClass. Более подробно об API.

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

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

Как Kubernetes помогает Cloud Native приложениям

Непрерывная доставка CI/CD. Автоматическая сборка и доставка кода из Git в инфраструктуру. Непрерывность достигается за счет того, что разработчики делают это без участия администратора инфраструктуры.

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

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

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

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

Как перейти на Cloud Native

Если вы хотите перейти от монолитной архитектуры к микросервисной и готовы погрузиться в Kubernetes, рекомендуем посмотреть наше практическое занятие. Из него вы узнаете, как создавать современные приложения с использованием PaaS-продуктов: Managed Kubernetes, Container Registry и DBaaS.

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

Заключение

Kubernetes можно считать сердцем всего подхода Cloud Native, поскольку технология аккумулирует все основные положения подхода.

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