Облачная архитектура и XaaS

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

Может быть, вы уже слышали что-нибудь о некоторых из следующих возможностей: IaaS, PaaS, SaaS, DaaS, FaaS, DBaaS. Возможно, вы даже использовали некоторые из них, не зная названия применяемой концепции.

Итак, давайте поговорим об облаке в контексте веб-приложений.

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

Микросервисная. Бэкэнд разделен на подмножества (в основном это зависит от размера приложения, но обычно от 10 до 80) микросервисов, которые могут быть развернуты на разных физических серверах, каждый микросервис должен отражать бизнес-функцию, например, аутентификацию, платежи и т.д.

Функциональная (по событию). В отличие от монолита и микросервисов, выполняются только в течение нескольких секунд, когда в этом есть необходимость; Примером может служить AWS Lambda, написанная на es7:

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

Это общий акроним, означающий любые решения aaS.

База данных как услуга ⸺ это платформа, на которой размещается база данных, обеспечивающая резервное копирование, кластеризацию и высокую доступность. Самыми популярными DBaaS являются Amazon Aurora, Amazon DynamicDB, mLab, IBM Cloudant и MongoDB Atlas.

Инфраструктура как услуга ⸺ это самый низкий уровень из всех XaaS. Это дает нам большие возможности, но требует сложной настройки. IaaS предоставляет виртуальную машину, которую мы должны поддерживать. Разница между IaaS и наличием физической серверной комнаты в том, что нам не нужно покупать какие-либо физические компьютеры, и у нас могут быть серверы в разных частях мира. Однако по сравнению с другими XaaS, IaaS сложнее поддерживать, и для этого требуется хороший инженер DevOps, который настраивает виртуальные машины для эффективной и безопасной работы.

Платформа как услуга ⸺ это простой способ развернуть приложение с использованием определенной технологии (например, Node.js, Ruby, PHP, Python, Java, .NET). Самые популярные платформы - Heroku и Google App Engine.

Как правило, вам не нужно настраивать CI (непрерывную интеграцию). Просто нажмите коммит, он распознает, что приложение находится в Node.js, и запустит npm install (вы можете добавить дополнительные команды в сценарий postinstall, который запускается NPM после установки зависимостей) и npm start. Если приложение написано на Ruby, оно будет запускать установку пакета и аналогично для других сред.

Главный недостаток ⸺ это не гибкость, потому что невозможно установить собственные системные зависимости (например, из apt-get), и вы можете использовать только одну из доступных технологий.

Еще один недостаток ⸺ данные небезопасны. Если, например, вы используете Heroku как Paas и mLab как DBaaS, доступ к вашим данным будет иметь не только mLab, но и Heroku, потому что вы никогда не знаете, какой код на самом деле выполняется на сервере. Может быть, что кроме вашего кода, они добавляют свои собственные промежуточные программы, чтобы что-то регистрировать.

Программное обеспечение как услуга предоставляет готовое программное обеспечение, такое как библиотеки NPM / GEM, но оно не требует от нас какого-либо развертывания / обслуживания сервера.

Простым примером является почтовое приложение, такое как SparkPost или SendGrid. Все, что нам нужно сделать, это отправить в браузере HTTP-запрос с адресом отправителя электронной почты, адресом получателя, темой электронной почты, содержимым электронной почты и т. д. С другой стороны, без такого инструмента нам пришлось бы настроить SMTP-сервер и масштабировать его, по мере роста количества писем.

Другие примеры: Google Apps (например, Google Drive), DropBox и Slack ⸺ эти приложения могут использоваться в повседневных задачах, но они также имеют большие возможности интеграции. Помимо уже существующего SaaS, некоторые компании (например, SAP) предлагают писать новые SaaS по запросу.

Данные как услуга похожи на SaaS, их можно даже рассматривать как подмножество SaaS. В частности, это API (обычно HTTP), который возвращает некоторые данные, например курсы валют, спортивные результаты или прогнозы погоды.

Что такое самый большой DaaS? Вероятно, Facebook, собирающий много данных и предоставляющий их для приложений Facebook. Другими популярными DaaS являются Google Maps, Google Translate API или AccuWeather.

Список полезных DaaS будет в следующей статье, подписывайтесь.

Функциональность как услуга ⸺ даже проще, чем PaaS. Как следует из названия, сервис основан на функциях, которые могут запускаться заданным событием, поэтому это архитектура, основанная на событиях. Уровень простоты настолько высок, что это называется бессерверная архитектура. Разработчик просто пишет функцию, и ему не нужно задумываться о таких темах, как развертывание, ресурсы сервера, масштабируемость, потому что FaaS автоматически масштабируется. Таким образом, выставление счетов основывается на реальном потреблении, а не на заявленных потребностях в ресурсах.

Наиболее ярким примером является AWS Lambda, но есть и другие, такие как Google Cloud Functions, Microsoft Azure Functions, Iron.io и Webtask.io.

Один из самых больших недостатков FaaS ⸺ поддерживаемые технологии. Доступных технологий даже меньше, чем с PaaS. Например, AWS Lambda поддерживает .NET, Java, Node.js и Python, Microsoft Azure Functions поддерживает .NET, Java, Node.js и PHP, тогда как Google Functions поддерживает только Node.js. Итак, как вы могли заметить, ни один из самых популярных FaaS не поддерживает Ruby в отличие от PaaS (например, Heroku).

Разделим функции по особенностям Microsoft Azure Functions:

Как видите, с помощью FaaS мы можем реализовать любой алгоритм (смотрите полнота Тьюринга), потому что мы можем обрабатывать HTTP-запрос, мы можем отправить другой HTTP-запрос и, более того, мы можем обрабатывать время и события очереди.

Единственные ограничения касаются поддержки определенных технологий, например, провайдер FaaS не поддерживает протокол MQTT, поэтому для этого требуется приложение, которое преобразует MQTT в HTTP, или другой формат, поддерживаемый в FaaS, или нам нужна конечная часть системы, которая взаимодействует с человеком (веб-приложение, мобильное приложение или настольное приложение) или физической средой (робот, проверяющий погодные условия, принтер, лампочка) ⸺ все это может быть построено в архитектуре FaaS, но требует некоторых дополнений за пределами мира FaaS .

Функции можно комбинировать с микросервисами, поэтому мы можем соединить FaaS с PaaS, но также можно построить весь бэкэнд на FaaS (с некоторыми ограничениями на технологии, используемые на стороне бэкэнда).

Однако давайте обсудим еще один недостаток ⸺ мы пишем код, который работает на определенном FaaS (например, функции Microsoft Azure), поэтому переход на другой FaaS (например, функции Google) может потребовать переписывания даже половины кода, написанного как функции FaaS. С другой стороны, переход от одного PaaS к другому относительно проще.

XaaS даже больше, чем вы можете себе представить:

Как видите, многие из XaaS могут даже иметь один и тот же акроним, и одно может быть подмножеством другого. Сложный вопрос, какой XaaS следует использовать в том или ином проекте и конкретной ситуации. Я полагаю, что в то же время разные инженеры DevOps могли бы выбрать совершенно разные решения. Мой любимый подход: создать архитектуру, ориентированную на микросервисы в PaaS, потому что она просто сочетает в себе гибкость и простоту.

Конечно, мы должны облегчить себе жизнь, используя некоторые внешние SaaS, такие как интеграции SparkPost или Slack, и некоторые внешние DaaS, чтобы легко получать данные, такие как текущие курсы обмена валют. Более того, мы можем основать некоторую (5% ~ 20% в зависимости от наших потребностей) часть нашей системы на FaaS, простые функции без сохранения состояния, которые соединяют несколько служб, поэтому использование FaaS просто сэкономит время на развертывании и мониторинге.

Я надеюсь, что эта статья поможет вам выбрать правильный XaaS (или несколько из них одновременно) в вашем проекте.