Cloud Native или новые веяния в разработке приложений на MS Azure с примерами. Часть 1

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

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

Я занимаюсь построением ИТ-систем в облаке более пяти лет, сейчас работаю в компании Sitecore, которая предоставляет B2B-сервис построения корпоративных порталов в облаке Azure на базе решений Sitecore.

Что общего у таких компаний как Uber, Netflix и Tesla (кроме огромной популярности и космической прибыли)? Они смогли вовремя понять, что залог успеха — скорость, с которой внедряются прогрессивные решения, качественные услуги, которые всегда имеют высокую доступность, масштабирование, открывающее новые перспективы, и переход к использованию мобильных приложений. Всего этого сложно было бы достичь, используя устаревшие методы и процессы, поэтому своевременный переход на облачные приложения (cloud native) сыграл решающую роль и указал вектор развития IT-индустрии в целом на десятилетия вперёд.

Сейчас есть широкий выбор как общедоступных (Amazon Web Services, Google Cloud, Microsoft Azure), так и частных (VMware, vSphere, OpenStack) облачных инфраструктур (public and private cloud infrastructures).

Что такое Cloud Native приложения

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

Определение общее и вызывает много вопросов и противоречий. Давайте разберемся с ключевыми понятиями и почему стоит переходить на Cloud Native приложения? Прежде всего — это несколько ключевых моментов:

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

Все облачные провайдеры, такие как MS Azure, Amazon AWS и Google GCP, всеми силами стараются показать нам преимущества разработки приложений с подходом cloud native. Давайте же рассмотрим примеры и кейсы, которые показывают плюсы данного подхода на примере Azure.

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

Модель облачных услуг и её преимущества с успехом используются в облачных системах.

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

Приведем пару примеров современной инфраструктуры в облаке, которые помогут значительно сэкономить время установки и настройки окружений, сред виртуализации, серверов и т. д. Одним из примеров PaaS-платформы для Microsoft Azure является WebAPPS (App Service). Она позволяет развертывать ваши приложения или устанавливать их непосредственно в облако с использованием кода из Git, используя те же самые возможности по Green-Blue развертыванию, которые идут из коробки. Это означает, что вы можете сразу разворачивать свой код на рабочее окружение и использовать это окружение для своей производственной среды без дополнительной настройки сервера.

Другим примером и вторым компонентом, без которого обычно не обходится ни одно приложение — это базы данных. Вы можете использовать Azure SQL для своей работы и устанавливать, настраивать базу данных в 3-4 клика. При этом нет необходимости тратить время на настройку сервера. Вы быстро получаете готовую базу данных и можете приступать к работе.

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

Какие еще преимущества использования облачных решений и Cloud Native подхода для создания web-приложения

Скорость разработки. Современные языки программирования помогут ускорить разработку. Используйте Node.js, .NET, Java, PHP, Python и Ruby на базе Windows или Linux. Для выделения ресурсов, обновления ОС, балансировки нагрузки, используя управляемые платформы, а также на портале Azure, можно применять готовые шаблоны, что увеличит скорость развертывания (больше вы можете узнать если перейдете по ссылке — ARM templates).

Улучшение продуктивности. Хотите публиковать приложения и вести отладку одним щелчком? Это доступно в Microsoft Visual Studio благодаря интеграции с GitHub, простым подключением к БД, возможностью использовать OSS-пакеты, API-интерфейсы, интеграторы и другие службы с Azure Marketplace. С порталом Azure вы легко можете добавить домены и SSL, настроить прозрачную авторизацию SSO, например авторизоваться в ваших приложениях через Facebook. Также вы можете сразу публиковать своё приложение в Microsoft Azure, прямо из Visual Studio, как показано на скриншоте.

Быстрая доставка изменений. Azure DevOps, Bitbucket и GitHub, позволяют автоматизировать процесс развертывания, благодаря использованию непрерывной интеграции и развертывания (CI/CD). Изменении кода, фиксируются в репозитории, и служба приложений тут же их обновляет. Используя слоты развертывания, можно за секунды выполнить деплой на продуктив или без простоев откатить версию.

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

Мониторинг. Точные аналитические данные о работе приложения позволяют принимать правильные решения. Azure Monitor содержит подробную информацию использования ресурсов, Application Insights наблюдает за работой приложения, временем отклика, и тенденциями.

Application Insights — набор инструментов для анализа данных телеметрии, полученных от веб-приложения. Он имеет набор фильтров, который позволяет удобно анализировать данные. Например, можно узнать, какое количество людей пользовались вашим приложением или какими-то конкретными компонентами, для расчета используются идентификаторы из cookie-файлов браузера. В Application Insights входят такие компоненты:

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

Что является Cloud Native-приложением и какие его основные признаки

Современная архитектура

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

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

Фактор

Описание

API First

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

Telemetry

(Мониторинг)

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

Authentication/ Authorization

(Аутентификация/авторизация)

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

API first

Данный фактор очень важен для всех современных приложений. В наше время бессмысленно разрабатывать свои приложения без внедрения и поддержки запросов со стороны других приложений. Приложения должны взаимодействовать с другими приложениями. Стандартный интерфейс между приложениями — это API-запрос. В Microsoft Azure есть специальный сервер API Gateway.

Что такое API Gateway

Архитектура микросервисов подразумевает общение клиента с разными облачными сервисами, но как он поймет к какому именно ему обращаться?

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

Шлюз API позволяет выполнять различные задачи и решать такие проблемы:

  • Маршрутизация. Шлюз перенаправляет запросы пользователей на одну или несколько служб, таким образом шлюз — это единая точка между клиентом и службами.
  • Агрегирование. Позволяет объединять различные запросы в один. Клиент отправляет один запрос, шлюз распределяет запрос по нескольким сервисам, а затем объединяет отчеты от сервисов и отправляет результат клиенту, что сокращает количество обращений между сервером и клиентом.
  • Разгрузка. Шлюз может выполнять некоторые функции служб. Таким образом, шлюз будет выполнять общую функцию, вместо выполнения ее на каждой службе. Например, шлюз может выполнять функцию авторизации и аутентификации, ограничение по IP, кеширование, брандмауэр, сжатие gzip, обслуживание статики.
  • Реализация технологии шлюза в приложении имеет различные параметры: обратный прокси сервер, входящий контроллер сетки службы, шлюз приложений Azure, управление API Azure.

Telemetry (Мониторинг)

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

В Microsoft Azure есть специальные сервисы Azure Monitor и Application Insights, которые используются для мониторинга основных метрик и ошибок.

Мы уже рассматривали применение Application Insights в статье с крутыми примерами.

Azure AD. Аутентификация/авторизация

Безопасность — главный тренд современных приложений. Для того, чтобы максимально обеспечить безопасность авторизации и аутентификации в приложении вы можете использовать Azure active directory, который позволяет применять enterprise system active directory, используя современный стандарт Oauth 2.0. Этот стандарт позволяет создавать приложения, которые полностью соответствуют реалиям и требованиям рынка в плане безопасности.

В Azure, конечно же, очень хорошо сделана интеграция с Azure Active Directory. Для каждого программного обеспечения разработана инструкция по настройке работы с AD авторизацией. Но даже для Atlassian Cloud, Service Now, Slack, SuccessFactors, Workday, AWS, Alibaba Cloud Service, Google Cloud Platform, Salesforce, SAP Cloud Identity Platform имеют возможность интегрироваться с Azure Active Directory. А также ряд приложений могут использовать единый вход для приложений.

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

Любая современная платформа разработки позволяет создавать микросервисы. Платформа с открытым исходным кодом Microsoft .NET благодаря встроенным функциям хорошо подходит для разработки микросервисов. .NET кроссплатформенна, приложения можно разрабатывать для Windows, MacOS и Linux. Высокопроизводительная .NET технология опережает Node.js и других конкурентов, согласно исследованию TechEmpower входит в десятку производительных платформ и фреймворков.

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

Контейнер — ПО, которое может работать на любом хосте, содержащее зависимости: код, системные библиотеки, среду выполнения, конфиги. Код, зависимости и прочее хранится в двоичном файле, называемом образом контейнера. Образы, в свою очередь, хранятся в реестре контейнеров (библиотеке образов), который может размещаться локально на ПК, в ЦОД или облаке. Пример контейнеров — docker с реестром в Docker hub. В Azure свой реестр контейнеров для образов, он хранит их совместно с облачными приложениями, которые используют контейнеры.

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

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

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

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

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

Основное преимущество контейнеров — это их портативность. Упаковывая приложение в пакет, происходит изоляция микросервиса совместно с необходимыми зависимостями, тем самым позволяя запускать его на любой ИТ-инфраструктуре. Развернуть контейнер можно в любой среде с запущенным Docker.

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

Контейнеры в Azure

Инструментов управления контейнерами в Azure достаточно много, но самыми популярными являются Fabrica и Kubernetes.

Azure Service Fabric можно отнести к категории инструментов для микросервисов, а Kubernetes — в группе «Инструменты для работы с контейнерами».

Некоторые из функций, предлагаемых Azure Service Fabric:

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

С другой стороны, Kubernetes предоставляет следующие ключевые функции:

  • Легкий, простой и доступный
  • Создан для «многооблачного» мира, общедоступного, частного или гибридного
  • Модульная конструкция, позволяющая легко заменять все компоненты.

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

Облачную инфраструктуру можно создать декларативно с помощью Azure CLI, Terraform и Azure Resource Manager (про шаблоны мы уже говорили выше). Динамическими параметрами будут имена, расположение, ресурсы, пароли. Для каждого сценария храниться версии изменений, как артефакт проекта сценарии проверяются в системе контроля версий. Что бы повторить ранее созданную инфраструктуру, необходимо вызвать сценарий, таким образам можно создавать QA, staging и production.

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

Помимо инструментов от самого Microsoft, вы можете также использовать Terraform с Azure Terraform, использование данного инструмента достойно еще одной статьи или книги :)

Вспомогательные сервисы

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

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

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

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

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

По ссылке вы найдете примеры как интегрировать данное решение с Azure AD для аутентификации и авторизации и еще массу примеров использования.

Наример. Платформа для мониторинга. Вам нужен мониторинг вашего приложения? Забудьте про всякие zabbix или nagios — вы можете использовать Azure monitor + Azure Insights и не заморачиваться с установкой и настройкой дополнительных сервисов для мониторинга.

Azure Monitor собирает два типа данных: метрики и журналы. Метрики выражаются в числовом описании показателей системы в конкретный момент времени. По размеру они небольшие и их просто использовать в онлайн-режиме. Журналы хранят больше информации разных типов с набором свойств. В основном, в журналах хранятся данные производительности, но также там есть данные телеметрии, трассировки. Эти данные можно группировать и анализировать.

Автоматизация деплоя

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

Например. Облако Azure включает новую службу CI/CD под названием Azure Pipelines, которая является частью предложения Azure DevOps..

Azure Pipelines — это облачная служба, объединяющая непрерывную интеграцию (CI) и непрерывную доставку (CD). Вы можете автоматически тестировать, собирать и отправлять свой код в тестовую или продуктивную среду. Конвейер определяется в коде в файле YAML вместе с остальным кодом вашего приложения. Он также версируется вместе с вашим кодом и следует той же структуре ветвления. В итоге получаете подтверждение своих изменений через обзоры кода в запросах на перенос и политики сборки ветвей.

Пара слов о Сloud Аgnostic

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

  1. Вы думаете, что будет просто перенести ваше решение на другой cloud? Мой ответ — нет. Я несколько раз принимал участие в миграциях, и даже маленькие инфраструктуры на 1-2 сервиса, 5-10 серверов, построенные на одном облаке, требуют 2-3 месяца на переезд.
  2. Вы используете универсальные компоненты и независимых поставщиков. Пытаясь уйти от vendor lock, добавляете сложность в продукты и уменьшаете скорость разработки в разы. Какой смысл переходить в облако, если вы не используете его преимущества ?
  3. 100% гарантия переезда. Чтобы знать на 100%, что в случае каких-либо проблем переедете на другое облако, вам необходим тестировать переход. Со всеми вытекающими затратами времени и денег.

Итого

Приложения для cloud native:

  • Разработаны как слабо связанные микросервисы, что дает возможность разрабатывать параллельно несколько компонентов на разных языках программирования.
  • Управляются с помощью гибких процессов DevOps. Используют инструменты, которые бесшовно интегрируются с облаком и поддерживают его возможности.
  • Скорость разработки за счет использования готовых компонентов.
  • Скорость установки и настройки инфраструктуры за счет унификации и стандартизации и шаблонов ARM и других средств.
  • Стабильность и минимальная вовлеченность Cloud Ops персонала. Опять же, за счет унификации и стандартизации.
👍НравитсяПонравилось4
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Читал, читал, так и не встретил информацию о стоимости всей этой красоты :)

vendor lock

Как будто это что-то плохое :)
Если же говорить серьезно, то vendor lock встречатется в том или ином виде в 95% случаев. Как только всплывает слово «фреймворк» — welcome to the club

І дійсно залежність від одног опропрієтарного рішення — це нічого особливого

Ой, як так, вендор згортає розробку елемента на якому ми все побудували
І тд і тп

Таке відчуття, що статья написана маркетологом який дуже хоче продати рішення від майка.

Привет, Спасибо за коммент. Нет, :) просто очень тяжело написать просто и понятно на сложную тему, и хотелось показать плюсы со стороны бизнеса.

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

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

Пара слов о Сloud Аgnostic

Мое мнение по этому поводу такое, что если архитектура привязана к конкретному клауду или даже просто к определенной схеме деплоймента — то это плохое решение!
Сама суть ООП подхода в том, что бы абстрагировать интерфейсы от реализации поддерживать полиморфизм. Если ваш код не позволяет поменять одну базу на другую или одну очередь на другую — то он написан не-гибко.
Начнем с банального: как бы не было запланировано деплоить на продакшине — но писать и отлаживать код девелопер должен на своей машине! Он, конечно, может запускать у себя кубернетис — кластер с контейнерами или какие-то эмуляторы облаков. Но, в моем идеальном мире, он должен просто использовать Dependency Injection для всего — и не заморачиваться будет ли вызванный компонент выполняться в том же процессе, или в другом процессе на этой машине, или в контейнере или вообще где-то в облаке.
Для локальной разработки у него просто все поднимется в одном процессе и все коммуникации будут напрямую. Когда код уже готов — можно залить его в облако, разложить на 100 контейнеров и прогнать интеграционные тесты.
По-поводу «разрабатывать прямо в облаке» — еще не видел ни одного клиента (включая тех, у кого свой клауд) кто бы не трекал ресурсы и не ныл что девелоперы накрутили слишком много «на счетчик». Облако — оно денег стоит.

Мое мнение по этому поводу такое, что если архитектура привязана к конкретному клауду или даже просто к определенной схеме деплоймента — то это плохое решение!

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

Для локальной разработки у него просто все поднимется в одном процессе и все коммуникации будут напрямую

Относительно простой сервис на Ажуре ( messaging + persistence). Ты должен поднять у себя на машине|

— Acitve Directory (мы же делаем нормальную аутентификацию) ?
— Azure Keyvault (мы же секьюрно храним секреты) ?
— Azure Service Bus
— Cosmos DB / MS SQL / xxx (самый простой вариант)
— xxx

Как-то дофига усилий получается.

кто бы не трекал ресурсы и не ныл что девелоперы накрутили слишком много «на счетчик». Облако — оно денег стоит.

Всякого рода полиси и бюджеты решают

Подписаться на комментарии