Поскольку облачные платформы, инфраструктура и инструментарий быстро развивались с момента первой публикации «Двенадцати факторов», а масштабные облачные миграции и развертывания сформировали сообщество разработчиков программного обеспечения, появилась расширенная методология под названием Cloud Native. Приложения Cloud Native (или просто облачные приложения) контейнеризованы, сегментированы на микросервисы и предназначены для динамического развертывания и эффективного запуска такими системами оркестровки, как Kubernetes.
Какие приложения считаются Cloud Native?
Для эффективного развертывания, запуска и управления в облачном приложении должны быть реализованы несколько основных методов Cloud Native. Например, приложение Cloud Native должно:
- Предоставлять конечную точку проверки работоспособности, чтобы системы контейнеризации и оркестровки могли проверять состояние приложения и реагировать соответствующим образом.
- Постоянно публиковать данные логов и телеметрии, которые будут храниться и анализироваться такими системами, как Elasticsearch и Prometheus.
- Корректно обрабатывать ошибки, чтобы система оркестровки могла восстановиться, перезапустив или заменив приложение новой копией.
- Не требовать вмешательства человека для запуска и начала работы.
Чтобы стимулировать распространение основных методов Cloud Native, а также поддержку и продвижение растущего Cloud Native Landscape, под эгидой Linux Foundation был создан фонд Cloud Native Computing Foundation (CNCF), который призван способствовать росту и развитию высококачественных проектов (например, Kubernetes). Среди других проектов, которые поддерживает CNCF, – Prometheus (система мониторинга и база данных временных рядов, часто развертываемая вместе с Kubernetes) и FluentD (сборщик данных и логов, часто используемый для реализации распределенного логирования в больших кластерах).
Облачное хранилище на 1 ТБ бесплатно НАВСЕГДА | НОВЫЙ СПОСОБ 2021
Согласно текущей документации CNCF определяет три базовых свойства, которые лежат в основе приложений Cloud Native:
- Упаковка приложений в контейнеры: контейнеризация.
- Динамическое планирование этих контейнеров: контейнерная оркестровка.
- Архитектуры программного обеспечения, которые состоят из нескольких небольших слабо связанных и независимо развертываемых сервисов: микросервисы.
Масштабирование с помощью Kubernetes на примере Snappy
Чтобы продемонстрировать преимущества реализации базовых методов Cloud Native, включая контейнеризацию и архитектуру микросервисов, мы рассмотрим простой пример: приложение для обмена фотографиями под названием Snappy, которое предоставляет базовые функции загрузки и обмена фотографиями между пользователями через веб-интерфейс.
В этой серии статей мы модернизируем Snappy таким образом:
В этом монолитном приложении для обмена фотографиями Snappy мы видим: сначала веб-интерфейс, управление фотографиями и бизнес-функции управления объединяются в единую кодовую базу, где эти отдельные компоненты активируют друг друга посредством вызовов функций. Затем создается кодовая база, она тестируется и разворачивается как единое целое, которое можно масштабировать как горизонтально, так и вертикально.
Как создать свое облачное хранилище Windows?
По мере того, как количество пользователей Snappy растет, а само приложение масштабируется, кодовая база постепенно становится чрезвычайно большой и сложной. Хотя изменения кода и исправления ошибок могут быть незначительными, все монолитное приложение необходимо пересобрать и снова развернуть, что приведет к замедлению итерации. Кроме того, если какой-либо отдельный подкомпонент станет узким местом приложения, весь монолит нужно масштабировать как единое целое.
Источник: www.8host.com
Из чего строят Cloud Native приложения в 2023 году
В этом материале мы поговорим об особенностях Cloud Native приложений и какую роль играет Kubernetes в этом подходе.
Все больше разработчиков выбирают микросервисную архитектуру уже на стадии проектирования, а монолиты методично распиливают. Это длительная и непростая работа, поэтому разработчики стараются еще на стадии проектирования определиться с архитектурой.
«Классический» цикл разработки монолитных приложений неизбежно сталкивается с рядом проблем:
- Сложно часто выпускать релизы из-за трудностей с компиляцией и добавлением в текущий билд. Это ведет к накоплению технического долга.
- Во время пиковых нагрузок приложениям не хватает вычислительной мощности или ширины канала, что сказывается на качестве сервиса и приводит к потере клиентов. Проблемы с балансировкой нагрузки заслуживают отдельного материала.
- Приложение написано на старой версии языка программирования или сам язык не подходит под актуальные задачи. Только часть команды понимает, как это поддерживать, поэтому сотрудники становятся незаменимыми.
Cloud Native предлагает другую парадигму создания и развития приложений. В ней приложение можно легко обновлять без ущерба для клиента.
По этой причине все больше компаний отказываются от монолита в процессе или изначально создают приложения с учетом особенностей облачной архитектуры. Это сложный процесс, поэтому некоторые зависают в процессе рефакторинга. О том, почему индустрия пришла к микросервисам и контейнерам, можно почитать здесь.
Путь к Cloud Native
В 2015 году на заре становления Cloud Native появилась классификация приложений по степени готовности к облаку.
- Cloud Ready. Приложению не требуется постоянный доступ к диску, оно контейнеризировано, а управление с внешними сервисами осуществляется за счет конфигов. Есть возможность подключить сторонние службы.
- Cloud Friendly. Приложение 12 факторов. Здесь появляется горизонтальное масштабирование за счет ресурсов облачной платформы.
- Cloud Resilient. Решения, построенные так, что увеличение нагрузки или отказ отдельных компонентов не приведет к недоступности сервиса.
- Cloud Native. Микросервисная архитектура, при проектировании используется принцип API-first.
Теперь за развитием нативного подхода к созданию приложений присматривает целое сообщество — Cloud Native Computing Foundation или CNCF.
Cloud Native как ландшафт
Сообщество определяет Cloud Native как подход для создания и запуска приложений в динамических средах (все типы облаков), который обязательно использует контейнеры, service mesh, микросервисы и неизменяемую IT-инфраструктуру (immutable infrastructure). В таком подходе к управлению развертыванием сервисов и ПО на IT-ресурсах компоненты заменяются, а не изменяются. Приложение или услуги фактически развертываются заново при каждом изменении.
Cloud Native — это больше, чем просто регистрация в облачных сервисах и запуск приложений.
Для эффективного деплоя, запуска и управления в облачном приложении должны быть реализованы несколько основных принципов Cloud Native.
Кластеры с поддержкой GPU
Создайте кластер Kubernetes за несколько кликов.
Ключевые признаки облачных приложений
- Контейнеризация и оркестрация.
- Следование практикам CI/CD.
- Масштабируемость ресурсов в зависимости от нагрузки.
- Отказоустойчивость и быстрое автоматическое восстановление в случае глобального сбоя.
- Наличие систем мониторинга состояний и производительности.
Среди прочих признаков Cloud Native сообщество отмечает высокий уровень автоматизации и возможность вносить значительные изменения с минимальными усилиями. Это облегчает деплой и, как следствие, увеличивает количество релизов. Все эти вводные данные указывают на то, что CNCF пока доверяет работу с контейнерами только Kubernetes, который сочетает все вышеперечисленное.
Например, внедрение Kubernetes помогло Adidas проводить релизы 3-4 раза в день, вместо недельных запусков.
Впрочем, эксперты сообщества регулярно обновляют карту сервисов, в которой собраны все необходимые компоненты для использования в клиентских приложениях.
Большая часть проектов относится к OpenSource-решениям и маркируется разными статусами в зависимости от того, на какой стадии находится проект.
Получается, любое приложение может быть 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 Native
Внедрение контейнеров постоянно растет. Предприятия переносят свои рабочие нагрузки с физических или виртуальных машин в контейнеры для оптимального использования ресурсов. Однако управление несколькими контейнерами в облачной среде не самый простой процесс, а если контейнеров будет тысяча?
В 2018 году Kubernetes первым получил статус Graduated Project (завершенный проект) в терминологии CNCF. Процесс развития K8s во много повлиял и на саму среду, изменив способы масштабного развертывания программного обеспечения, методы работы и взаимодействие корпораций с крупными проектами с открытым исходным кодом.
Сейчас «выпускников» CNCF уже 18, а Kubernetes представляет собой основу для всего ландшафта, поэтому все чаще можно встретить понятие Kubernetes Native как ориентацию разработки на работу с контейнерами и микросервисами.
COSI и Kubernetes Native 1.25
Объектное хранение данных в последние годы набирает популярность в качестве альтернативы файловым системам и блочному устройству.
Рабочие нагрузки, которые используют тома 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 в инфраструктуру. Непрерывность достигается за счет того, что разработчики делают это без участия администратора инфраструктуры.
Сокращение времени и усилий. С помощью K8s компания может добиться непрерывной интеграции CI/CD, оптимизации модульного тестирования и доставки с нулевым временем простоя за счет автоматизации внедрения кода.
Оптимизация расходов. Контейнерная архитектура на базе Kubernetes позволяет отказаться от дорогостоящей инфраструктуры и сосредоточиться на производстве собственного продукта. Нагрузка распределяется внутри группы нод, которые состоят из более доступных серверов.
Эта же система используется для мониторинга использования ресурсов и состояния контейнеров, а также для перезапуска и масштабирования по мере необходимости.
Заключение
Kubernetes можно считать сердцем всего подхода Cloud Native, поскольку технология аккумулирует все основные положения подхода.
Чтобы отладить процесс масштабирования и автоматизации, можно использовать Managed Kubernetes.
Почему в такой модели использовать K8s проще:
- Провайдер организует и отвечает за доступность кластера.
- Провайдер разрабатывает и предоставляет инструменты для работы с K8s (например, terraform-провайдер).
- Провайдер предоставляет экосистему сервисов, которые интегрированы друг с другом. Например, образы можно хранить в Container Registry.
Источник: selectel.ru
Разработка ориентированных на облако приложений .NET для Azure
Обновления книги и вклад сообщества см. в журнале изменений.
Подразделение Microsoft Developer Division, команды разработки .NET и Visual Studio
Подразделение корпорации Майкрософт
One Microsoft Way
Redmond, Washington 98052-6399
Все права защищены. Запрещается полное или частичное воспроизведение или передача настоящей книги в любом виде или любыми средствами без письменного разрешения издателя.
Эта книга предоставляется на условиях «как есть» и выражает взгляды и мнения автора. Взгляды, мнения и сведения, содержащиеся в этой книге, включая URL-адреса и другие ссылки на веб-сайты, могут изменяться без уведомления.
Некоторые приведенные в книге примеры служат только для иллюстрации и являются вымышленными. Все совпадения с реальными наименованиями, людьми и любыми другими предметами являются непреднамеренными и случайными.
Microsoft и товарные знаки, перечисленные на странице «Товарные знаки» на сайте https://www.microsoft.com, являются товарными знаками группы компаний Майкрософт.
Mac и macOS являются товарными знаками Apple Inc.
Логотип Docker с изображением кита является зарегистрированным товарным знаком Docker, Inc. Используется с разрешения.
Все другие наименования и логотипы являются собственностью своих законных владельцев.
Роб Веттор (Rob Vettor) , главный архитектор по инновациям в сфере облачных приложений, MTC (Технологический центр Майкрософт) — thinkingincloudnative.com, Майкрософт
Стив Смит (Steve Smith) , преподаватель и разработчик программного обеспечения, Ardalis.com
Участники и рецензенты:
Цезарь де ла Торре (Cesar De la Torre) , старший менеджер программ, команда .NET, корпорация Майкрософт
Ниш Анил (Nish Anil) , старший менеджер программ, команда .NET, корпорация Майкрософт
Джереми Ликнесс (Jeremy Likness) , старший менеджер программ, команда .NET, корпорация Майкрософт
Сесил Филлип (Cecil Phillip) , старший советник по облачной разработке, корпорация Майкрософт
Самит Гош (Sumit Ghosh) , главный консультант в Neudesic
Майра Вензел (Maira Wenzel) , менеджер программ, команда .NET, корпорация Майкрософт
Дэвид Пайн (David Pine), старший разработчик содержимого, разработка документации по .NET, корпорация Майкрософт
Версия
В это руководство включены сведения о версии .NET 6 и о дополнительных обновлениях, связанных с тем же «поколением» технологий (т.е. технологий Azure и сторонних производителей), к которому относится выпуск .NET 6.
Кому необходимо это руководство
Это руководство предназначено главным образом для разработчиков, руководителей отделов разработки и архитекторов, желающих научиться создавать приложения, ориентированные на облако.
Побочной аудиторией являются лица, принимающие решения технического характера, которым нужно определить, использовать ли ориентацию на облако при создании своих приложений.
Как использовать это руководство
Это руководство начинается с определения ориентации на облако и представляет эталонное приложение, созданное с применением принципов и технологий ориентации на облако. Помимо этих первых двух глав, оставшаяся часть книги поделена на главы, касающиеся большинства ориентированных на облако приложений. Вы можете перейти к любой из этих глав, чтобы узнать о подходах ориентации на облако.
- Данные и доступ к ним
- Модели связи
- Масштабирование и масштабируемость
- Устойчивость приложения
- Мониторинг и работоспособность
- Идентификация и безопасность
- DevOps
Руководство доступно как в формате PDF, так и в Интернете. При необходимости вы можете порекомендовать этот документ членам своей команды или отправить им ссылку на его интернет-версию, чтобы они были в курсе этих аспектов. В большинстве этих вопросов важную роль играет понимание базовых принципов и шаблонов, а также компромиссов, связанных с соответствующими решениями. Цель этого документа заключается в том, чтобы предоставить командам и их руководителям сведения, необходимые для принятия взвешенных решений по архитектуре, разработке и размещению приложений.
Отправить отзыв
Эта книга и примеры постоянно дополняются, поэтому мы ждем ваших отзывов. Если у вас есть комментарии о том, как можно улучшить эту книгу, используйте раздел отзывов в нижней части любой страницы, созданный на основе проблем GitHub.
Источник: learn.microsoft.com