Serverless Framework решения для многооблачных решенийServerless Framework multicloud solutions

В этой статье описывается, как группа разработки коммерческих программных продуктов Майкрософт (CSE) сотрудничает с глобальной розничной торговлей для развертывания высокодоступного бессерверного решения на основе облачных платформ Azure и Amazon Web Services (AWS) с помощью Serverless Framework.This article describes how the Microsoft Commercial Software Engineering (CSE) team partnered with a global retailer to deploy a highly-available serverless solution across both Azure and Amazon Web Services (AWS) cloud platforms, using the Serverless Framework.

В бессерверных вычисленияхпоставщик облачных вычислений динамически выделяет ресурсы микрослужб для выполнения кода и только расходы за используемые ресурсы.In serverless computing, the cloud provider dynamically allocates microservices resources to run code, and only charges for the resources used. Бессерверные вычисления абстрагирует код приложения от реализации инфраструктуры, развертывания кода и рабочих аспектов, таких как планирование и обслуживание.Serverless computing abstracts app code from infrastructure implementation, code deployment, and operational aspects like planning and maintenance.

Как и в случае с другими службами, каждый поставщик облачных служб имеет собственную бессерверную реализацию, и клиентам трудно использовать другого поставщика без существенного воздействия на операционные ресурсы и затраты.As with other services, each cloud provider has its own serverless implementation, and it's difficult for customers to use a different provider without considerable operational impact and costs. Потенциальные клиенты могут просмотреть эту ситуацию, чтобы ослабить свои преимущества и гибкость.Potential customers may view this situation as weakening their bargaining position and agility. Блокировка поставщика — одна из самых крупных препятствий в области внедрения облачных облаков.Vendor lock-in is one of the greatest obstacles to enterprise cloud adoption.

Serverless Framework с открытым исходным кодом — это универсальный облачный интерфейс для разработки и развертывания бессерверных вычислительных решений в рамках поставщиков облачных служб.The open-source Serverless Framework is a universal cloud interface for developing and deploying serverless computing solutions across cloud providers. Открытые и общие интерфейсы API для бессерверных функций помогают поставщикам, клиентам и партнерам создавать решения для разных облаков для лучших служб.Open-sourcing and common APIs for serverless functions help providers, customers, and partners build cross-cloud solutions for best-of-breed services. Serverless Framework сокращает барьеры до внедрения в облако, устраняя проблемы избыточности поставщика и кросс-облачного поставщика.The Serverless Framework reduces barriers to cloud adoption by addressing the problems of vendor lock-in and cross-cloud provider redundancy. Клиенты могут оптимизировать свои решения на основе затрат, гибкости и других факторов.Customers can optimize their solutions based on cost, agility, and other considerations.

CSE и группа разработчиков Azure совместно переписали интерфейс командной строки , поддерживающий новые функции Azure, такие как функции Premium, управление API и KeyVault.CSE and the Azure product team collectively rewrote the Serverless CLI to support new Azure Functions features like Premium Functions, API Management, and KeyVault. Интерфейс командной строки с бессерверной подготовкой к развертыванию Гитопс в Azure и AWS.The Serverless CLI now provides a standard interface for GitOps deployment to both Azure and AWS. Группа также разработала бессерверную многооблачную библиотеку, которая предоставляет нормализованный API среды выполнения для развертывания бессерверных приложений в AWS и Azure.The team also developed the Serverless Multicloud Library, which provides a normalized runtime API to deploy serverless apps to both AWS and Azure.

Такая схема обеспечивает высокий уровень доступности с активной и активной отработкой отказа между несколькими облачными платформами в отличие от активной и пассивной отработки отказа.This design provides high availability with active-active failover between multiple cloud platforms, as opposed to active-passive failover. Если служба одного поставщика облачных служб становится неработоспособной или недоступна, это решение может перенаправлять запросы на другую облачную платформу.If the service of one cloud provider becomes unhealthy or unavailable, this solution can reroute requests to another cloud platform.

Этот проект соответствует следующим техническим целям:This project met the following technical goals:

  • Создайте кросс-отраслное решение.Create a cross-industry solution.
  • Используйте многооблачную библиотеку без сервера для поддержки независимого от облака API-интерфейса, который взаимодействует с микрослужбами везде, где они развернуты.Use the Multicloud Serverless Library to support a cloud-agnostic API that interfaces with microservices wherever they are deployed.
  • Поддерживают рабочий процесс Гитопс CI/CD для разработки, тестирования и развертывания на всех поддерживаемых облачных платформах.Support a GitOps CI/CD process workflow for development, testing, and deployment on all supported cloud platforms.
  • Используйте доступ на основе API с помощью облачного шлюза с проверкой подлинности и балансировки нагрузки между облачными платформами с помощью шлюза в качестве маршрутизатора.Use API-based access via an authenticated cloud gateway, and load balance between cloud platforms by using the gateway as a router.

Другие потенциальные преимущества использования Serverless Framework включают:Other potential benefits of using the Serverless Framework include:

  • Предотвращение или сокращение блокировки поставщикаPrevention or reduction of vendor lock-in
  • 40 – 60 +% сокращения кода во время разработки с использованием многооблачной библиотеки40-60+% code reduction during development by using the Multicloud Serverless Library
  • Разработка лучших решений, объединяющих разные службы облачных поставщиковDevelopment of best-of-breed solutions that combine different cloud providers' services
  • Устранение большинства требований к сложности и обслуживанию платформы и инфраструктурыElimination of most platform and infrastructure complexity and maintenance requirements
  • Более простой общий доступ к данным, сравнение производительности и затрат, а также возможность использования специальных предложенийEasier data sharing, performance and cost comparisons, and ability to take advantage of special offerings
  • Высокая доступность "активный — активный"Active-active high availability

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

  • Создавайте клиентские приложения для нескольких платформ, используя независимый от облака API-интерфейс из многооблачной библиотеки без сервера.Write client-side applications for multiple platforms by using a cloud-agnostic API from the Serverless Multicloud Library.
  • Развертывание набора функциональных микрослужб в бессерверной платформе на нескольких облачных платформах.Deploy a collection of functional microservices in a serverless framework to multiple cloud platforms.
  • Используйте независимое от облака приложение на облачных платформах, не зная или не волнует, на какой платформе размещается эта платформа.Use a cloud-agnostic app across cloud platforms without knowing or caring which platform is hosting it.

ArchitectureArchitecture

Архитектура с многооблачными серверами

  • Пользовательское приложение может поступать из любого источника, способного войти в облако.The user app can come from any source capable of logging into the cloud. В этой реализации пользователь входит в приложение шлюза, которое выполняет балансировку нагрузки запросов 50-50 между облаками Azure и AWS.In this implementation, the user logs into a gateway app that load balances requests 50-50 between the Azure and AWS clouds.
  • Любой ответ также проходит через шлюз диспетчера API, который отправляет его в приложение-запрашивающее.Any response also routes through the API Manager gateway, which then sends it to the requestor app.

Serverless FrameworkThe Serverless Framework

Это решение использует Serverless Framework, доступное из бессерверных, Inc. Бесплатная версия Serverless Framework включает интерфейс командной строки, дополнительные подключаемые модули и ограниченные службы мониторинга.This solution uses the Serverless Framework, available from Serverless, Inc. The free version of the Serverless Framework includes a CLI, additional plugins, and limited monitoring services. Выпуск Pro включает в себя операционные возможности в облаках, например расширенные функции мониторинга и оповещения.The Pro edition features operational capabilities across clouds, such as enhanced monitoring and alerts. Платформа поддерживает Node.js и языки Python, а также AWS и облачные узлы Azure.The framework supports Node.js and Python languages, and both AWS and Azure cloud hosts.

Чтобы использовать Azure с Serverless Framework, вам потребуется:To use Azure with the Serverless Framework, you need:

  • Node.js для упаковки микрослужбNode.js, to package microservices
  • Функции Azure для предоставления функциональных возможностей, сравнимых с другими облачными платформамиAzure Functions, to provide functionality comparable to other cloud platforms
  • Serverless Framework для поддержки развертывания и мониторинга в облакеThe Serverless Framework, to support multicloud deployment and monitoring
  • Бессерверная многооблачная Библиотека, которая предоставляет нормализованные API среды выполнения для разработчиковThe Serverless Multicloud Library, to provide normalized runtime APIs for developers
  • Подключаемый модуль бессерверных функций Azure для поддержки развертывания в облаке.The Azure Functions Serverless Plugin, to support multicloud deployment. Изначально этот подключаемый модуль не был использован для проверки четности с помощью сравнимого подключаемого модуля AWS лямбда-выражения и был расширен для этого проекта.This plugin wasn't initially up to parity with the comparable AWS Lambda plug-in, and was extended for this project.

На следующем рисунке показан конвейер обработки.The following figure shows the processing pipeline. Уровни по промежуточного слоя представляют любые промежуточные функции, необходимые перед достижением обработчика.The middleware layers represent any intermediate functionality needed before reaching the handler.

Конвейер обработки в многооблачной обработке

Независимые от облака APICloud-agnostic APIs

Бессерверная реализация на каждой платформе поддерживает отдельные функции как микрослужбы, по одному на каждый функциональный узел виртуальной машины и выполняет обработку по мере необходимости.The serverless implementation on each platform supports individual functions as microservices, one to each functional VM node, and executes processing as needed. Каждая AWS лямбда-функция имеет соответствующую функцию функций Azure.Each AWS Lambda function has a corresponding Azure Functions function. Независимая от сервера многооблачная библиотека строится аналогичным микрослужбам из облака в независящие от облака нормализованные REST API , которые клиентские приложения могут использовать для взаимодействия с любой из платформ.The Serverless Multicloud Library builds analogous microservices from either cloud into a cloud-agnostic normalized REST API that client apps can use to interface with either platform. Так как абстрактный уровень API предоставляет код для адресации соответствующих микрослужб для каждой платформы, транзакции не требуют преобразования.Because the abstracted API layer provides code to address the corresponding microservices for each platform, transactions don't need translation. Независимый от облака интерфейс позволяет пользовательским приложениям взаимодействовать с облаком, не зная и не волнует, к какой облачной платформе они обращаются.The cloud-agnostic interface lets user apps interact with the cloud without knowing or caring which cloud platform they're accessing.

Эта концепция показана на схеме ниже.The following diagram illustrates this concept:

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

CI/CD с ГитопсCI/CD with GitOps

Основное задание Serverless Framework заключается в абстракции всех проблем инфраструктуры, связанных с развертыванием приложения в облаке.A primary job of the Serverless Framework is to abstract away all the infrastructure concerns of deploying an app to the cloud. Используя подход на основе манифеста, Serverless Framework может справиться со всеми проблемами развертывания, что позволяет автоматизировать развертывание по мере необходимости для поддержки Гитопс.Using a manifest-based approach, the Serverless Framework can deal with all deployment issues, allowing deployment to be automated as needed to support GitOps.

Хотя этот первоначальный проект использовал ручное развертывание, он реалистично реализует управляемые манифестом сборки, тесты и развертывания в или в облаках.Although this initial project used manual deployments, it's realistic to implement manifest-driven serverless builds, tests, and deployments within or across clouds. Этот процесс может использовать рабочий процесс разработчика Гитопс: создание из Git, использование шлюза контроля качества для тестирования и оценки и отправка бессерверных решений в оба поставщика облачных служб.This process can use a GitOps developer workflow: building from Git, using quality gates for test and evaluation, and pushing serverless solutions onto both cloud providers. Выполнение всех развертываний с использованием Serverless Framework, начиная с начала проекта, является наиболее эффективным способом продолжения.Performing all deployments using the Serverless Framework from the beginning of the project is the most efficient way to proceed.

Диспетчер APIAPI manager

Диспетчер API может быть существующим или пользовательским приложением.The API Manager can be an existing or custom application. ™Диспетчер API апижее в этой реализации действует только в качестве маршрутизатора, чтобы обеспечить балансировку нагрузки 50-50 транзакций между двумя облачными платформами и было недостаточно загружено для своих возможностей.The Apigee™ API Manager in this implementation acted only as a router to provide a 50-50 transaction load balance to the two cloud platforms, and was underutilized for its capabilities.

Диспетчер API-интерфейсов должен иметь возможность:The API Manager must be able to:

  • Развертываться внутри или вне облачной платформы по мере необходимостиBe deployed inside or outside a cloud platform as needed
  • Маршрутизация сообщений на обе облачные платформы и обратноRoute messages to and from both cloud platforms
  • Регистрация запросов трафика для координации асинхронного трафика сообщенийLog traffic requests to coordinate asynchronous message traffic
  • Запросы и ответы ретрансляции, использующие общие REST API от и к пользовательскому приложениюRelay requests and responses using the common REST API from and to the user application
  • Отслеживайте работоспособность облачных развертываний бессерверных платформ, чтобы проверить их возможность получения запросов.Monitor the health of both cloud serverless framework deployments to validate their ability to receive requests
  • Автоматическое выполнение проверок работоспособности и доступности на каждой облачной платформе для поддержки маршрутизации и обеспечения высокого уровня доступностиPerform automated health and availability checks on each cloud platform, to support routing and high availability

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

  • Другие языки, такие как Python, могут реализовать решение, если они поддерживаются в бессерверных реализациях облачных платформ, AWS лямбда-выражения и функции Azure в этом случае.Other languages such as Python could implement the solution, as long as they're supported by the serverless implementations of the cloud platforms, AWS Lambda and Azure Functions in this case. Этот проект использовал Node.js для упаковки микрослужб, поскольку клиент был знаком с Node.js, а AWS и платформами Azure поддерживают ее.This project used Node.js to package the microservices, because the customer was comfortable with Node.js, and both AWS and Azure platforms support it.

  • Решение может использовать любую облачную платформу, поддерживающую Serverless Framework, а не только Azure и AWS.The solution can use any cloud platform that supports the Serverless Framework, not just Azure and AWS. В настоящее время Serverless Framework сообщает о совместимости с восемью различными поставщиками облачных служб.Currently, the Serverless Framework reports compatibility with eight different cloud providers. Единственное предостережение — убедиться, что элементы, поддерживающие многооблачную архитектуру или ее эквиваленты, доступны на целевых облачных платформах.The only caveat is to ensure that the elements that support the multicloud architecture or its equivalent are available on the target cloud platforms.

  • Диспетчер API в этой первоначальной реализации действует только как маршрутизатор, чтобы обеспечить баланс нагрузки 50-50 транзакций между двумя облачными платформами.The API Manager in this initial implementation acted only as a router to provide a 50-50 transaction load balance to the two cloud platforms. Диспетчер API может включать в себя другую бизнес-логику для конкретных сценариев.The API Manager could incorporate other business logic for specific scenarios.

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

  • Эта статья не описывает решения по обеспечению безопасности, хотя первоначальное развертывание включало их.This article doesn't describe security solutions, although the initial deployment included them. Существует множество возможных решений безопасности, зависящих от платформы, и эта платформа должна соответствовать любому разумному решению.There are many possible security solutions, some platform dependent, and this framework should accommodate any reasonable solution. Проверка подлинности пользователя является минимальным предполагаемым обеспечением безопасности.User authentication is the minimum security assumed.

  • Поскольку трудно выявление различий между AWS и функциональными предложениями, не предназначенными для работы с сервером Azure, на ранних этапах следует сосредоточиться на сопоставлении функций, доступных на каждой облачной платформе, и идентификации необходимых требований к преобразованию.Because it's difficult to articulate the differences between AWS and Azure serverless functional offerings, early effort should focus on mapping the functions available on each cloud platform and identifying necessary transformation requirements. Из этой информации можно разработать независимый от платформы API.You can develop a platform-agnostic API from this information.

  • Использование решения с открытым исходным кодом может привести к возникновению рисков из-за долгосрочного обслуживания и поддержки с помощью любого программного обеспечения с открытым кодом.Using an open-source solution may introduce risks, due to long-term maintenance and support challenges with any open-source software.

  • В бесплатной Serverless Framework мониторинг ограничен главным образом административной панелью мониторинга.In the free Serverless Framework, monitoring is limited primarily to the administrative dashboard. Мониторинг обычно предоставляется в платном корпоративном предложении.Monitoring is usually available in the paid enterprise offering. В настоящее время бессерверные подключаемые модуля функций Azure не включают в себя подходящие для наблюдения или мониторинга и требуют изменений для реализации этих возможностей.Currently, the Azure Functions Serverless Plugin doesn't include provisions for observability or monitoring, and would need modification to implement these capabilities.

  • Это решение может использовать метрики для сравнения производительности и затрат между облачными платформами, что позволяет клиентам эффективно оптимизировать использование на облачных платформах.This solution could use metrics to compare performance and costs between cloud platforms, enabling customers to seamlessly optimize usage across cloud platforms.

Развертывание решенияDeploy the solution

Традиционное развертывание со синей зеленой средой разрабатывает и развертывает приложение в двух отдельных, но идентичных средах, синих и зеленых, повышая доступность и уменьшая риски.A traditional Blue-Green Deployment develops and deploys an app to two separate but identical environments, blue and green, increasing availability and reducing risk. Синяя среда обычно является рабочей средой, которая обычно обрабатывает динамический трафик, а зеленая среда — развертывание отработки отказа по мере необходимости.The blue environment is usually the production environment that normally handles live traffic, and the green environment is a failover deployment as needed. Как правило, конвейер CI/CD автоматически развертывает синие и зеленые среды в пределах одной облачной платформы.Typically, the CI/CD pipeline automatically deploys both blue and green environments within the same cloud platform. Эта конфигурация считается конфигурацией " активный — пассивный ".This configuration is considered an active-passive configuration.

В решении с несколькими облаками развертывание с помощью синего зеленого цвета Реализовано на обеих облачных платформах.In the multicloud solution, blue-green deployment is implemented in both cloud platforms. В бессерверном сценарии два повторяющихся набора микрослужб развертываются для каждой облачной платформы, одна из которых является рабочей средой, а другая — средой отработки отказа.In the serverless case, two duplicate sets of microservices are deployed for each cloud platform, one as the production environment and the other as the failover environment. Эта установка "активный — пассивный" в каждой облачной платформе снижает риск того, что эта платформа будет отключена, увеличится ее доступность и обеспечит высокий уровень доступности для многооблачной Active-активной среды.This active-passive setup within each cloud platform reduces the risk that this platform will be down, increasing its availability, and enabling multicloud active-active high availability.

Развертывание "активный — активный" сине-зеленый

Второе преимущество развертывания с помощью синего зеленого цвета заключается в возможности использовать развертывание отработки отказа на каждой облачной платформе в качестве тестовой среды для обновлений микрослужб, прежде чем выпускать их в рабочее развертывание.A secondary benefit of blue-green deployment is the ability to use the failover deployment on each cloud platform as a test environment for microservices updates, before releasing them to the production deployment.