По мнению Altexsoft . Четырнадцать лет назад облачные технологии начали внедряться в ИТ. Рынок должен был быстро меняться, так как каждый год приносил новые подходы к разработке приложений. Во-первых, предприятия в основном использовали подход IaaS (инфраструктура как услуга). Это требовало аренды серверов и переноса инфраструктуры в облака, но командам все еще приходилось заниматься настройкой серверов. Затем произошло постепенное прекращение работы сервера вручную, и появился PaaS (Platform-as-a-Service). Поставщики PaaS предложили более полный стек приложений, например, операционные системы и базы данных для работы в облаке и управления ими от поставщика. Но этого было недостаточно.
Пропустив несколько этапов разработки Backend-as-a-Service , в 2014 году мы наконец-то оказались без сервера. Безсерверный или FaaS (Function-as-a-Service) представляет новый подход к разработке приложений. Короче говоря, FaaS – это форма бессерверных вычислений, в которой используется инфраструктура, полностью управляемая поставщиком, для загрузки функций и их запуска на основе платы за запрос. В отличие от других подходов к облачным вычислениям, безсерверный процесс полностью абстрагирует разработчиков от серверов и позволяет им сосредоточиться на бизнес-логике.
Преимущества безсерверной архитектуры
Бессерверная архитектура, несмотря на свою популярность, не подходит для каждой компании или продукта, так как это подход, который лучше всего подходит для конкретного набора вариантов использования. Таким образом, перечисленные преимущества использования без сервера могут различаться, поскольку они зависят от типа поставщика (открытый или общедоступный) и стека предлагаемых услуг без сервера. Но, как правило, однозначные преимущества безсерверной архитектуры:
Более низкие затраты и масштабируемость . Есть несколько причин, почему дешевле запускать ваше приложение на основе FaaS. По сравнению с традиционным подходом это снижает затраты на эксплуатацию и обслуживание сервера. По сравнению с другими типами облачных вычислений большинство поставщиков FaaS работают по модели ценообразования с оплатой за запрос. Это означает, что вы платите только за время, в течение которого была вызвана функция, и за количество вызовов. Кроме того, вы можете выделить определенный объем памяти и ЦП для функции и масштабировать ее по мере необходимости вверх и вниз.
Ускоренная разработка и внедрение. Вместо написания монолитной структуры FaaS предлагает более гибкую альтернативу. Разработчики могут писать код для набора функций вместо всего монолитного приложения и загружать биты кода на сервер. Это делает всю структуру легко исправлять, обновлять и добавлять новые функции.
Снижение затрат на человеческие ресурсы. Отсутствие серверов означает не привлекать инженеров DevOps для обслуживания или покупки конкретного оборудования.
Высокая доступность и автоматическое масштабирование. Функция становится активной, когда клиентская сторона запрашивает ее. Функция также может запускаться после нескольких запросов, но по-прежнему отключаться, когда она не нужна. С ростом трафика сервис автоматически масштабирует ресурсы, выделенные для определенной функции. Такой подход делает FaaS высокодоступным и обеспечивает бесперебойную работу при больших нагрузках.
Фокус на бизнес-потребностях. Абстрагирование разработчиков от серверной работы позволяет вашей команде сосредоточиться на бизнес-логике вашего приложения.
Обзор поставщиков серверной архитектуры
В 2018 году список поставщиков серверной архитектуры увеличился, так как новые игроки выходили на рынок в течение двух предыдущих лет. Провайдеры можно разделить на основные и второстепенные группы. Основную группу составляют крупнейшие публичные облачные провайдеры безсерверной архитектуры. В этой статье мы сравним основных игроков и упомянем некоторые альтернативы им.
AWS Lambda. Предложение FaaS, которое принадлежит Amazon Web Services, было представлено в 2014 году. С момента его выпуска Lambda стала синонимом того, что означает безсерверный, удерживая позицию лидирующего продукта на рынке с самым широким спектром доступных услуг. Вероятно, наиболее известным примером публичного внедрения без серверов является Netflix .
Функции Azure от Microsoft. Сервис запущен в 2016 году, чтобы конкурировать с AWS Lambda. Функции Azure предлагают набор услуг, аналогичный Amazon, с акцентом на семейство языков и инструментов Microsoft. Одним из примеров использования функций Azure является «Я был Pwned» .
Облачные функции Google (GCF) . Один из четырех крупнейших Google выпустил свое решение только в 2017 году. Служба GCF раньше отставала от Azure и Lambda, но в течение 2018 года Google удалось исправить предыдущие ошибки, о чем свидетельствуют примечания к выпуску GCF .
Все упомянутые провайдеры предлагают аналогичные услуги, которых достаточно для запуска приложения в управляемой инфраструктуре. Они также предлагают достаточные возможности, чтобы получить все преимущества концепции FaaS, но могут работать по-другому. Чтобы определить лучший вариант для вас, давайте сравним доступные сервисы, используя следующие критерии:
- Модели ценообразования и фактуры выставления счетов
- Поддерживаемые языки программирования
- Типы триггеров функций
- Продолжительность исполнения на запрос и параллелизм
- Методы развертывания
- Методы мониторинга и регистрации
Сравнение основных поставщиков FaaS
Модели ценообразования и фактуры выставления счетов
Как упоминалось ранее, большинство поставщиков FaaS используют модель ценообразования с оплатой за запрос, которая является довольно рентабельной. Чтобы рассчитать стоимость вашего приложения, существуют службы, которые достаточно точно прогнозируют ваши потенциальные расходы. Но у каждого провайдера есть свой инструмент расчета:
Lambda предлагает бесплатный уровень, который включает 1 миллион запросов и 400 000 ГБ-секунд вычислительного времени в месяц. Все запросы, превышающие лимит бесплатного уровня, оплачиваются по 0,00001667 долл. США / ГБ с, что является самой низкой ценой на рынке. В реальной практике бесплатный уровень позволяет запускать ваше приложение достаточно долго, прежде чем начнется биллинг. Выделенные ресурсы (память и ЦП) выставляются как единое целое, поскольку они растут пропорционально. Дополнительные расходы могут быть получены в результате использования других сервисов AWS в вашей функции Lambda.
Azure оплачивается так же, как Lambda, с разницей в 0,000016 ГБ в секунду, но уровень бесплатного доступа идентичен. Затраты на большие нагрузки в Azure немного ниже, чем у Lambda, и равны Lambda для средней нагрузки. Но Microsoft предпочитает выставлять счета за потребленную память, а не за выделенную.
Azure также предлагает более низкие цены на использование Windows и SQL, что вполне логично. Таким образом, выбор между ними зависит от среды, которую вы используете, больше, чем расходы, которые вы несете.
Уровень бесплатного пользования GCF – 2 миллиона запросов в месяц с теми же 400 000 ГБ-с, и $ 0,0000004 за запрос после него, включая сетевой трафик. Учитывая длительность выполнения функции и количество запросов, расходы с Google Cloud Functions заметно выше. Что касается ресурсов, GCF отличается, потому что они выставляют счета за выделенную память и процессор отдельно.
Подводя итог, можно сказать, что AWS Lambda предлагает среднюю цену, в то время как Azure может варьироваться в затратах, в зависимости от используемого процессора и памяти. Но для сред Windows Azure предлагает самую низкую цену.
Поддержка языков программирования
Поставщик FaaS является общедоступным облаком, что означает, что вы запускаете свое приложение в управляемой среде, и каждый поставщик предлагает поддержку для разных языков.
Lambda охватывает широкий спектр языков программирования, включая среду выполнения Node.js, Python, Java и скомпилированные для него языки, а также языки .NET (C #, Visual Basic и F #).
Функции Azure, очевидно, сосредоточены на семействе языков Microsoft и перечисляют JavaScript и скомпилированные для него языки, среду выполнения Node.js, C #, F #, Python, PHP, Bash, Batch и PowerShell.
Облачные функции Google раньше поддерживали только JavaScript, но было объявлено, что многие другие языки проходят бета-тестирование. Так что в долгосрочной перспективе у службы GCF есть шанс поспеть за другими крупными поставщиками. Но, на данный момент, это не похоже на надежный выбор.
Azure и Lambda поддерживают больше языков, чем другие провайдеры, а Google только что объявил о большем количестве языков в будущем.
Типы триггеров
Крупные поставщики предлагают различные настраиваемые и динамические типы триггеров, которые можно использовать для вызова функции. Триггеры предоставляются с помощью других облачных сервисов, которые есть у каждого поставщика. Как правило, все основные поставщики поддерживают запланированный вызов функции, вызовы по требованию и интеграцию с другими облачными службами соответственно. Вы можете найти более подробную информацию в пользовательской документации каждого провайдера.
Lambda и Azure предлагают типы триггеров, настроенные через API. Для AWS это API-шлюз для триггеров API, файловый триггер через Amazon S3 и динамический триггер, выполняемый через DynamoDB . Azure предлагает веб – API инициирующего, запланированный вызов и тип триггеров выполняются с другими службами Microsoft, Azure Event Hub и Azure Storage .
Сервис GCF предоставляет список основных поддерживаемых триггеров и дополнительных триггеров в своей документации . Основная особенность типов триггеров GCF заключается в том, что ваше приложение может быть интегрировано с любыми сервисами Google, поддерживающими облачные ответные реакции Pub / Sub или HTTP.
Таким образом, если выбрать поставщика на основе методов запуска, лучшим выбором будет Azure или Lambda, поскольку они предлагают больше типов и интеграцию со своими облачными сервисами. GCF занимает третье место, если вам нужно запускать функции через сервисы Google.
Время выполнения и параллелизм
Другим важным аспектом, относящимся к вызову функции, является время, отведенное для активации функции, и параллелизм. Параллелизм означает параллельное выполнение различных функций за определенный период времени.
Лямбда ограничивает скорость одновременного выполнения до 1000 выполнений за раз с максимальным временем выполнения 15 минут. Параллельность может быть настроена для всей учетной записи или для отдельной функции.
Azure предлагает неограниченную скорость параллелизма в одном приложении, но ограничивает максимальное время выполнения для одной функции до 5 минут и 10 минут в качестве обновления.
GCF допускает неограниченное количество вызовов для типа триггера HTTP, что является хорошим вариантом. Что касается других методов запуска, параллелизм такой же, как предлагает Lambda, по 1000 выполнений за раз. Время выполнения одной функции ограничено 60 секундами, но может быть увеличено до почти 9 минут. Важно отметить, что AWS Lambda считает параллельные функции в одной учетной записи, а GCF делает то же самое в рамках проекта. Это означает, что в AWS вы можете запустить только одну функцию с 1000 одновременных вызовов, в то время как в GCF можно запускать несколько функций с одним и тем же параллелизмом.
Итак, если вы хотите, чтобы производительность ваших функций была плавной, между Lambda, GCF и Azure нет критических различий. Но если вы сосредоточены на долгом обращении Lambda будет лучшим выбором.
Методы развертывания
Кажется, нет разницы в методах развертывания у разных поставщиков. В общем случае для развертывания в безсерверной среде разработчик будет использовать безсерверный. yml для настройки функций или внесенных в него изменений. Затем код ваших функций упаковывается в Zip-файлы и отправляется на сервер.
Lambda будет обновлять каждую отдельную функцию вашего приложения, в то время как службы Azure, GCF, как правило, анализируют без сервера. yml через плагин и загружать ресурсы с разницей в порядке.
Мониторинг и регистрация
Мониторинг необходим для бессерверных вычислений, поскольку вся инфраструктура управляется поставщиком. Итак, чтобы увидеть, что именно происходит с вашим приложением, и применить метрики, каждая служба должна предлагать инструменты мониторинга / ведения журнала. Это позволяет вам просматривать ресурсы, выделенные и используемые, обнаруживать ошибки, отслеживать журналы и т.д.
Amazon выпустила собственный инструмент – CloudWatch – для своей службы Lambda, которая помогает наблюдать за вызовами функций и журналами. Но CloudWatch подвергся критике за его ограниченную функциональность, учитывая тот факт, что это платный сервис. Есть также Microsoft Monitor , Stackdriver от Google.
Еще одним сервисом Amazon является X-Ray , распределенная система трассировки для различных сервисов AWS. Похоже, что он работает хорошо, но его основная цель – мониторинг микросервисных приложений , а не функций. Для мониторинга безсерверного приложения существуют также сторонние опции:
- Dashbird – это бесплатный сервис для мониторинга AWS, который предлагает дополнительные функции для CloudWatch и более удобный интерфейс.
- OpenTracing – это независимая от производителя служба мониторинга, но не инструмент. Служба должна быть настроена для определенного поставщика. OpenTracing поддерживает 9 языков: Go, JavaScript, Java, Python, Ruby, PHP, Objective-C, C ++ и C #.
- Thundra не была выпущена, но она уже доступна в бета-версии. Основная особенность сервиса заключается в том, что он будет фокусироваться на JavaScript, а также будет предоставлять функции мониторинга и ведения журналов, основанные на опыте использования AWS X-Ray, и интегрироваться с ним.
Как показывает сравнение, все основные поставщики стековых серверов предлагают относительно равные услуги инфраструктуры. Функции AWS Lambda и Azure по-прежнему являются наиболее полными и разнообразными сервисами для работы. Таким образом, выбор зависит больше от среды, в которой вы хотите работать, поддержки языков программирования и сообщества.