Изменить

Многооблачные решения с Serverless Framework

Функции Azure

В этой статье описывается, как команда коммерческого программного обеспечения Майкрософт (CSE) сотрудничала с глобальным розничным продавцом для развертывания высокодоступного бессерверного решения на облачных платформах Azure и Amazon Web Services (AWS) с помощью бессерверной платформы.

Архитектура

Схема, показывающая многооблачную бессерверную архитектуру.

Скачайте файл Visio этой архитектуры.

Поток данных

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

Компоненты

Serverless Framework

В этом решении используется бессерверная платформа, доступная от Serverless, Inc. Бесплатная версия бессерверной платформы включает cli, дополнительные подключаемые модули и ограниченные службы мониторинга. В версии Pro доступны операционные возможности в облаках, например расширенные функции мониторинга и оповещения. Платформа поддерживает Node.js и Python, а также облака AWS и Azure.

Чтобы использовать Azure с Serverless Framework, вам потребуется:

  • Node.js для упаковки микрослужб.
  • Функции Azure для предоставления функциональных возможностей, сравнимых с другими облачными платформами.
  • Serverless Framework для поддержки мультиоблачного развертывания и мониторинга.
  • Serverless Multicloud Library для предоставления разработчикам нормализованных API среды выполнения.
  • Подключаемый модуль Функций Azure для Serverless для поддержки мультиоблачного развертывания. Изначально этот подключаемый модуль по функциональности уступал аналогичному подключаемому модулю AWS Lambda и был доработан для этого проекта.

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

Схема, демонстрирующая конвейер многооблачной обработки.

Независимые от облака API

Бессерверная реализация на каждой платформе поддерживает отдельные функции как микрослужбы, по одной на каждый функциональный узел виртуальной машины, и выполняет обработку по мере необходимости. У каждой функции AWS Lambda есть аналог в Функциях Azure. Serverless Multicloud Library преобразует аналогичные микрослужбы из обоих облаков в нормализованные REST API, не зависящие от облака, которые клиентские приложения могут использовать для взаимодействия с любой платформой. Так как абстрактный уровень API предоставляет код для обращения к соответствующим микрослужбам для каждой платформы, транзакции не требуют преобразования. Независимый от облака интерфейс позволяет пользовательским приложениям взаимодействовать с облаком, не зная, какую платформу они используют.

Эта концепция представлена на схеме ниже:

Схема, демонстрирующая не зависящий от облака API.

CI/CD с GitOps

Основная задача Serverless Framework — избавить разработчиков от забот, связанных с инфраструктурой, при развертывании приложения в облаке. Используя подход на основе манифеста, бессерверная платформа может решать все проблемы с развертыванием, что позволяет автоматизировать развертывание по мере необходимости для поддержки GitOps.

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

Диспетчер API

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

Диспетчер API должен иметь возможность:

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

Альтернативные варианты

  • Другие языки, такие как Python, могут реализовать решение, если они поддерживаются в бессерверных реализациях облачных платформ. В данном случае — AWS Lambda и Функции Azure. В этом проекте использовался Node.js для упаковки микрослужб, поскольку у клиента был опыт работы с Node.js и его поддерживают платформы AWS и Azure.

  • Решение может использовать любую облачную платформу, поддерживающую Serverless Framework, а не только Azure и AWS. В настоящее время Serverless Framework сообщает о совместимости с восемью различными поставщиками облачных служб. Однако следует убедиться, что элементы, поддерживающие мультиоблачную архитектуру или ее эквиваленты, доступны на целевых облачных платформах.

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

Сведения о сценарии

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

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

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

CSE и группа разработчиков Azure совместно переписали интерфейс Serverless CLI, чтобы он поддерживал новые возможности Функций Azure, такие как Функции уровня "Премиум", Управление API и Key Vault. Serverless CLI теперь предоставляет стандартный интерфейс для развертывания GitOps в Azure и AWS. Группа также разработала мультиоблачную библиотеку Serverless Multicloud Library, которая предоставляет нормализованный API среды выполнения для развертывания бессерверных приложений в AWS и Azure.

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

Этот проект соответствует следующим техническим целям:

  • Создание решения для нескольких отраслей.
  • Создание Multicloud Serverless Library для поддержки независимого от облака API, который взаимодействует с микрослужбами в месте их развертывания.
  • Поддержка рабочего процесса GitOps CI/CD для разработки, тестирования и развертывания на всех поддерживаемых облачных платформах.
  • Используйте доступ на основе API через облачный шлюз с проверкой подлинности и распределяйте нагрузку между облачными платформами с помощью шлюза в качестве маршрутизатора.

Другие потенциальные преимущества использования Serverless Framework:

  • Предотвращение или сокращение зависимости от поставщика
  • Сокращение кода на 40–60 % во время разработки благодаря Multicloud Serverless Library.
  • Разработка лучших решений, объединяющих разные службы поставщиков облачных служб.
  • Упрощение платформы и инфраструктуры и их обслуживания.
  • Упрощение обмена данными, сравнение цены и производительности, а также возможность использования специальных предложений.
  • Высокий уровень доступности по модели "активный – активный"

Потенциальные варианты использования

  • Написание клиентских приложений для нескольких платформ с использованием независимого от облака API из Multicloud Serverless Library.
  • Развертывание набора функциональных микрослужб на бессерверной структуре на нескольких облачных платформах.
  • Использование независимого от облака приложения на разных облачных платформах.

Рекомендации

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

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

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

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

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

Развертывание этого сценария

Традиционное сине-зеленое развертывание подразумевает разработку и развертывание приложения в двух отдельных, но идентичных средах, синей и зеленой, чтобы повысить доступность и сократить риски. Синяя среда обычно является рабочей средой, которая обрабатывает текущий трафик, а зеленая среда — развертыванием для отработки отказа при необходимости. Как правило, конвейер CI/CD автоматически развертывает синие и зеленые среды в пределах одной облачной платформы. Эта конфигурация называется активный — пассивный.

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

Схема, показывающая сине-зеленое развертывание

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

Дальнейшие действия