Amazon и Microsoft, крупнейшие мировые поставщики облачных технологий, считают, что люди должны забыть про управление виртуальными машинами или оплате простоя оборудования. Аргументируя это тем, что безсерверные вычисления обеспечивают неограниченный масштаб и высокую доступность для любой компании в мире, от небольших стартапов до транснациональных корпораций.
AWS Lambda впервые внедрила модель приложения «Функция как услуга» (FaaS) в 2014 году. С помощью Faas небольшой фрагмент кода будет реализован в виде файла ZIP и связан с определенным типом события.
Безсерверная модель существует с 2014 года, и каждый крупный поставщик облачных услуг представил свою собственную версию FaaS: Azure, Google Cloud, IBM Cloud и другие. Хотя основная идея всех предложений одинакова, между этими реализациями есть много различий.
Десять основных отличий между функциями AWS Lambda и Azure:
1. Хостинг-планы
Проще говоря, у AWS есть один способ выполнить модель без сервера: развернуть ее на AWS Lambda. Стратегия Amazon заключается в том, чтобы эта услуга охватывала как можно больше клиентских сценариев, от увлекательных сайтов до систем обработки данных на уровне предприятия.
Microsoft использует другой подход. Они отделили концепцию модели программирования от функций Азур и операционной модели без сервера. С помощью сервера можно развернуть свои функции в полностью управляемом плане потребления с оплатой за использование. Тем не менее, можно использовать другие варианты хостинга для запуска того же кода:
- План обслуживания приложений обеспечивает предсказуемую оплату в час, но ограничивает автоматическую масштабируемость.
- Премиум план (предварительный просмотр) обеспечивает зарезервированную емкость и гибкое масштабирование в сочетании с расширенными сетями при более высокой стоимости.
- Docker Container может работать где угодно на автономной инфраструктуре.
- Основанная на Kubernetes событийная архитектура (KEDA, экспериментальная): предоставляет функции Kubernetes, работающие в любом облаке или локально.
- План потребления имеет наименьшие накладные расходы на управление и не имеет компонента с фиксированной стоимостью, что делает его наиболее безсерверным вариантом хостинга в списке.
2. Конфигурируемость
При использовании модели AWS нужно определить максимальное выделение памяти, которое должно быть от 128 МБ до 3 ГБ. Мощность процессора и стоимость функций пропорциональны выделенной памяти. Чтобы определить оптимальный размер, нужно немного поэкспериментировать, в зависимости от профиля нагрузки. Независимо от их размера все экземпляры работают на Amazon Linux.
С другой стороны, план потребления приложений Azure универсален для всех. Он поставляется с 1,5 ГБ памяти и одним низкопрофильным виртуальным ядром. Вы можете выбрать между Windows и Linux в качестве основной операционной системы.
План Azure Functions Premium включает несколько экземпляров, до 14 ГБ памяти и четыре виртуальных ЦП. Тем не менее, вы должны платить фиксированную почасовую оплату за зарезервированные мощности.
3. Языки программирования
- AWS Lambda изначально поддерживает код JavaScript, Java, Python, Go, C #, F #, PowerShell и Ruby.
- Функции Azure имеют среды выполнения для JavaScript, Java, Python, C #, F # и PowerShell (предварительный просмотр). В Azure отсутствуют Go и Ruby.
4. Модели программирования
Специфика зависит от времени выполнения, но в целом AWS Lambda имеет простую модель программирования. Код получает объект JSON в качестве входных данных и может возвращать другой JSON в качестве выходных данных. Тип события определяет схему тех объектов, которые задокументированы и определены в языковых SDK.
Функции Azure имеют более сложную модель, основанную на триггерах и ссылках. Код может иметь неограниченное количество входных и выходных ссылок для поиска или отправки дополнительных данных во время обработки. Например, функция, запущенная через HTTP, также может считывать документ из базы данных Azure Cosmos и отправлять сообщение в очередь, все это делается декларативно путем привязки конфигурации.
Детали реализации различаются в зависимости от языка выполнения. Система привязки обеспечивает дополнительную гибкость, но она также приносит некоторую сложность, как с точки зрения API, так и конфигурации.
5. Расширяемость
Одним из недостатков всех услуг FaaS является ограниченный набор поддерживаемых типов событий. Например, если вы хотите запустить приложения из раздела Kafka, вам не повезло и в AWS, и в Azure.
Другие аспекты серверных приложений более настраиваемы. AWS Lambda определяет концепцию уровней: механизм распространения для библиотек, пользовательские среды выполнения для поддержки других языков и другие зависимости.
Функции Azure включают в себя открытые расширения привязки, поэтому сообщество может создавать новые типы привязок и добавлять их в приложения функций.
6. Параллелизм и изоляция
Обе службы могут запускать несколько (возможно, тысяч) исполнений одной и той же функции одновременно, каждая из которых обрабатывает одно входящее событие.
AWS Lambda всегда резервирует один экземпляр для одного выполнения. Каждое выполнение имеет свой собственный пул памяти и циклов процессора. Поэтому производительность полностью предсказуема и стабильна.
Функции Azure назначают несколько одновременных выполнений одному и тому же виртуальному хосту. Если одно выполнение простаивает в ожидании ответа от сети, другие исполнения могут использовать ресурсы, которые в противном случае были бы потрачены впустую.
Однако ресурсоемкие платформы могут конкурировать за пул общих ресурсов, что снижает общую производительность и время обработки.
7. Стоимость
Безсерверное ценообразование основано на модели оплаты за использование. Обе услуги состоят из двух компонентов: плата за звонок и дополнительная плата в ГБ. Последняя является метрикой, которая сочетает в себе время выполнения и потребление памяти.
Более того, цена обеих услуг практически одинакова: $ 0,20 за миллион запросов и $ 16 за ГБ * с (16,67 $ за AWS). Один миллион выполнений, каждый длиной 100 мс и занимающий 1 ГБ памяти, стоит менее двух долларов.
Тем не менее, есть некоторые различия в деталях:
AWS Lambda взимает плату за полный объем выделенной памяти, а функции Azure измеряют фактическое среднее потребление памяти для выполнения.
Если выполнения функций Azure совместно используют экземпляр, стоимость памяти не взимается несколько раз, а распределяется между выполнениями, что может привести к заметному снижению цены.
Обе службы взимают не менее 100 мс и 128 МБ за каждое выполнение. AWS округляет время до ближайших 100 мс, а Azure округляет до 1 мс.
8. Интеграция HTTP
AWS Lambda требовала, чтобы Amazon API Gateway слушал HTTP-трафик, что стоило огромных дополнительных затрат. Недавно Amazon представила интеграцию с Elastic Load Balancing, которая может быть более экономичной для сценариев с высокой нагрузкой. Тем не менее, цена указана в час, поэтому требуется здравый смысл.
Функции Azure поставляются с интегрированной конечной точкой HTTP, и эта интеграция не требует дополнительных затрат.
9. Производительность и масштабируемость
AWS Lambda на рынке дольше, чем Azure Functions, и специализируется на моделях с одним хостингом. Хотя в отрасли нет общепринятых эталонных тестов, многие утверждают, что AWS Lambda лучше для быстрого масштабирования и обработки больших рабочих нагрузок для веб-API и приложений на основе очередей. Эффект задержки запуска – холодный запуск – также менее важен для Lambda.
10. Оркестры
Бессерверные модели приложения – это наноуслуги: небольшие блоки кода выполняют только одну команду. Вопрос о том, как создавать большие приложения и системы из этих небольших элементов, остается открытым, но некоторые модели макетов уже существуют.
Сервера имеют специальные службы управления рабочими процессами: пошаговые функции AWS и логические приложения Azure. Очень часто они используются в качестве этапов в этих рабочих процессах, что позволяет им оставаться независимыми в решении важных проблем.
Кроме того, Azure Durable Functions – это библиотека, предоставляющая код абстракции для организации рабочего процесса. Она оснащена несколькими моделями для объединения многих функций сервера в долгосрочные потоки со статусом. Библиотека обеспечивает надежную и прозрачную связь и управление статусами, сохраняя при этом простоту API.