В статье расскажу про serverless computing — «бессерверные вычисления»: зачем это нужно, какие есть Open Source-реализации self-hosted-фреймворков с поддержкой Kubernetes, об их возможностях и ограничениях. Еще поделюсь опытом нашего клиента, который использует одно из таких решений (OpenFaaS). Идея обзора как раз и возникла в процессе изучения этого кейса.
Кратко про serverless computing
Serverless-архитектура — стратегия, ориентированная на дробление продукта на мелкие части и их исполнение в инфраструктуре в качестве самостоятельных единиц: функций. Отсюда и термин FaaS, function-as-a-service. Сторонники serverless-подхода рассматривают его как следующую эволюционную ступень разработки: монолит → микросервисы → функции.
Самый простой пример того, что может легко переехать в serverless, — REST API. Он stateless, то есть зависит только от клиентских данных в запросе. Для расширения функционала API достаточно создать дополнительные мини-приложения (функции) для каждой точки входа и поместить их в некую среду, которая умеет обрабатывать клиентские запросы. В итоге формируется единая система, которая легко масштабируется под нагрузкой и достаточно просто модернизируется.
Из плюсов FaaS-сервисов — простота запуска, динамическое масштабирование worker’ов, которые обрабатывают клиентские запросы, возможность платить только за потребленные ресурсы.
Есть и минусы:
Холодный запуск. При изменении нагрузки требуется некоторое время для запуска или увеличения числа worker’ов.
Stateless only, т.е. невозможность хранить состояние конкретной функции, а это подходит не для всех задач.
Vendor lock и особенности реализации для конкретного облака подразумевают функциональные и — потенциально — финансовые ограничения. К первым можно отнести, например, ограниченное время исполнения функции.
Первопроходцы
Пионером в serverless стала AWS, которая в 2014 году представила платформу Lambda. Несмотря на некогда ограниченный стек языков, Lambda не просто доказала жизнеспособность подхода, но и стала лидером направления. Согласно отчету CNCF State of Cloud Native development, по состоянию на первый квартал 2021-го ее используют 54% респондентов.
В 2016 году Microsoft представила свое решение — Azure Functions (35% респондентов, по данным того же опроса). В 2017-м появился Google Cloud Functions (41% респондентов). Сейчас AWS Lambda, Google Cloud Functions и Azure Functions — это зрелые решения категории production-ready, которые активно используются бизнесом.
Естественно, появились и свободные альтернативы — self-hosted serverless frameworks. Им и посвящен этот обзор.
Self-hosted-решения
Появление serverless-фреймворков, которые можно размещать на произвольной инфраструктуре, удачно совпало с ростом популярности сначала Docker, а потом и Kubernetes. Бум пришелся на 2016—2018 годы. Например, в 2016-м появились Iron Functions, Funktions и OpenFaaS; в 2017-м — Kubeless; в 2018-м — Knative и OpenWhisk.
Self-hosted-фреймворки призваны решить некоторые из минусов hosted-решений вроде vendor lock’а и ограничений на используемые языки программирования. Их также можно использовать на своем «железе».
Технически логика работы self-hosted-фреймворка предполагает, что функция собирается в Docker-образ, после чего она работает на платформе оркестрации в виде контейнера. Это дает универсальность, но в то же время добавляет некоторые ограничения. Например, нивелируется основная идея serverless — быстрое масштабирование: у пользователя всегда должны быть наготове ресурсы, которые можно отдать функциям. Также многие отмечают усложнение разработки и обслуживания по сравнению с микросервисной архитектурой.
Проверку временем прошли не все self-hosted-решения:
Kubeless, Iron Functions, Space Cloud, OpenLambda, Funktion и Fn Project «мертвы» или близки к этому состоянию.
OpenWhisk скорее жив, однако не радовал релизами с ноября 2020-го. Фреймворк мало упоминается, особенно в контексте self-hosted-решения для Kubernetes (его используют 3% среди пользователей serverless по данным отчета CNCF за 2020-й год).
OpenFaaS жив и используется сообществом (10% пользователей).
Knative активно развивается и в целом кажется, что чувствует себя лучше всех (27% пользователей). В ноябре 2021 г. вышла версия 1.0.
Fission регулярно выпускает релизы (последний был 29 декабря 2021 г.), но используется не очень активно (2% пользователей).
Проект Nuclio имеет Open Source-версию, однако в ней нет возможности auto-scaling вообще и scaling в ноль в частности, поэтому в сравнении не участвует.
Посмотрим внимательнее на актуальные фреймворки.
OpenFaaS — «мальчик», который выжил
Один из самых старых проектов, который практически полностью развивается на энтузиазме его создателя — Alex Ellis. Об истории создания фреймворка можно узнать из нашей переводной статьи.
Помимо бесплатной версии OpenFaaS его автор предлагает премиум-подписку и профессиональную поддержку. За прошедшие пять лет проект набрал более 21 000 звезд на GitHub. Интенсивность его разработки несколько снизилась, но она по-прежнему продолжается.
Управляется OpenFaaS через собственную утилиту faas-cli и через веб-интерфейс. С помощью утилиты можно управлять самим OpenFaaS, а также работать с репозиториями функций, создавая-изменяя свои или используя общедоступные.
Внутри Kubernetes-кластера OpenFaaS работает благодаря faas-netes. Это OpenFaaS-провайдер, который обеспечивает взаимодействие OpenFaaS и непосредственно кластера. Также faas-netes может работать в режиме оператора, обслуживающего собственные CRD — Functions. Если режим оператора не включен, OpenFaaS оперирует стандартными объектами, такими как Service и Deployment.
Возможности и преимущества:
Поддерживает разные языки программирования. Можно запускать бинарники (например,
sha512sum) — главное, чтобы они использовали стандартные stdin/stdout.Автомасштабирование — для этого используется Prometheus (сбор метрик) и Alertmanager (который обеспечивает автомасштабирование на основе собранных метрик). Умеет автомасштабировать в ноль (но с оговорками — об этом ниже).
Работает с Docker Swarm и Kubernetes.
Поддерживает Ingress на входе.
Ограничения:
Автомасштабирование: необходимо держать на постоянной основе хотя бы один контейнер с каждой функцией либо ждать запуска контейнера при первом обращении (со всеми вытекающими последствиями).
Не умеет ограничивать ресурсы, потребляемые функциями.
В списке пользователей OpenFaaS есть в том числе известные компании — например, VMware и DigitalOcean.
Knative — перспективный новичок
Изначально Knative запустили в Google при поддержке IBM, Red Hat, VMware и SAP. С октября 2020 года Knative находится в свободном плавании и управляется сообществом. Проект активно развивается: в его разработке участвуют 600+ человек.
Похоже, что в Knative все больше верят крупные вендоры. Red Hat включила поддержку Knative в «коробку» с OpenShift. В ноябре 2021 года Google запросила CNCF добавить Knative в список проектов инкубатора CNCF, но решение до сих пор не принято (есть интересная статья про подоплеку этого дела).
Управляется Knative через консольный клиент kn. С его помощью можно взаимодействовать с CRD проекта: Serving (постоянно живущими сервисами) и Eventing (работающими по запросу).
Внутри кластера фреймворк поддерживается силами Knative operator, который использует Serving и Eventing, чтобы создавать необходимые объекты в Kubernetes — например, Pod’ы.
Возможности и преимущества:
Из коробки полноценно умеет автомасштабировать в ноль. Разработчики утверждают, что практически решили проблему с холодным стартом, функции начинают полноценно работать за 2 с.
Поддерживает разные языки программирования: Node, Java, Python, Ruby, C#, PHP, Go. Есть готовые шаблоны, поэтому можно не возиться с написанием Dockerfile.
На борту есть свой сбор метрик и логов.
Оповещает о событиях в Slack, GitHub и не только.
Умеет ограничивать ресурсы, потребляемые функциями.
Совместим с Google Cloud Run, а значит — возможна простая миграция.
Умеет работать как с постоянно работающими сервисами, так и с событийно-ориентированными.
Ограничения:
Сложная логика автомасштабирования.
Ориентирован на работу только с Kubernetes.
На входе работает с Istio, что может усложнить внедрение. От Istio можно отказаться, однако авторы настоятельно рекомендуют его использовать.
Среди известных пользователей проекта: Puppet, deepc, Outfit7.
OpenWhisk
Фреймворк ранее поддерживала IBM, а теперь — Apache Software Foundation. Аналогично OpenFaaS, проект развивается, но не очень активно. В то же время сама IBM предлагает в своем облаке IBM Cloud Functions, что основывается на наработках проекта OpenWhisk. По данным уже упомянутого отчета CNCF за 2021 год, Functions от IBM выбирают 15 % респондентов, и это почти вдвое больше, чем в 2020-м (8 %).
Работа с OpenWhisk организована через консольный клиент wsk, который управляет необходимыми примитивами Kubernetes.
Возможности и преимущества:
Поддерживает Kubernetes, Docker Swarm и Apache Mesos.
Поддерживает из коробки Go, Java, NodeJS, .NET, PHP, Python, Ruby, Rust, Scala, Swift. Может запускать произвольно собранные контейнеры.
Автомасштабирование.
Сбор метрик и логов.
Из коробки есть REST API.
Интеграция со Slack (через плагин).
Умеет ограничивать ресурсы, потребляемые функциями.
Ограничения:
Аналогично OpenFaaS не пытается решить вопрос холодного старта, хотя автомасштабирование поддерживается.
Для работы в Kubernetes требуется Docker — не понятно, как быть, когда от Docker окончательно откажутся.
Fission
Фреймворк был создан в 2018 году облачным провайдером Platform9, который поддерживает его и по сей день. В GitHub также упоминается, что в его разработке участвуют DigitalOcean и InfraCloud, но я не смог найти его явных упоминаний от них самих. Выглядит так, что сама Platform9 и является крупнейшим пользователем фреймворка. В целом информации по Fission не очень много, что является то ли причиной, то ли следствием малого числа его пользователей.
Фреймворк управляется через одноименную консольную утилиту. Каких-то особенных CRD он не приносит, а оперирует примитивами Kubernetes.
Возможности и преимущества:
Поддерживает из коробки Node.js, Python, Ruby, Go, PHP, Bash. Может запускать произвольно собранные контейнеры.
Автомасштабирование.
Сбор метрик и логов.
Поддерживает WebHooks из коробки.
С помощью нового движка NewDeploy решает проблему холодного старта (обещают до 100ms на запуск).
Ограничения:
Ориентирован на работу только с Kubernetes.
На входе работает с Istio, что может усложнить внедрение.
Автомасштабируется только на основе CPU usage (обещают добавить custom metrics в дальнейшем).
Не умеет ограничивать ресурсы, потребляемые функциями.
Опыт нашего клиента
Среди наших клиентов нашелся всего один, который применяет self-hosted serverless framework. Эта компания специализируется на виртуальных ассистентах и использует OpenFaaS.
OpenFaaS был выбран потому, что он ускоряет развертывание и тем самым облегчает жизнь разработчику. Однако это работает только тогда, когда нужно быстро сделать кусок API, работу с внешним источником, что-нибудь для обращения партнера и т. д.
Переносить же ключевую функциональность в OpenFaaS клиент не планирует, так как не видит в этом смысла и преимуществ.
Из отмеченных неудобств:
авторизация OpenFaaS не умеет разграничивать права, поэтому в некоторых функциях у клиента две авторизации: одна — на входе в OpenFaaS, другая — внутри самой функции.
Несколько раз возникали проблемы из-за невозможности ограничить ресурсы: одна из функций «съедала» всю оперативную память узла.
Резюмируя, наш клиент признался, что использует фреймворк только из-за удобств для разработчиков. Остальные особенности ему неинтересны.
Заключение
На рынке serverless вырисовывается следующая картина:
Serverless-подход сам по себе живет и здравствует, в том числе благодаря CNCF Serverless Working Group. Хотя интересно, что, согласно упомянутому отчету CNCF за 2021 год, количество вовлеченных в serverless разработчиков за период 2020-2021 снизилось с 27 до 24%. Как предполагают авторы отчета, это произошло из-за опасений vendor lock и ограничений FaaS в целом.
Self-hosted-решения либо еще не распробованы, либо так и останутся уделом энтузиастов.
Выводы по рассмотренным фреймворкам:
OpenFaaS и Fission живут за счет энтузиазма своих создателей (одного человека или целой компании соответственно).
OpenWhisk живет скорее по инерции.
Knative живет за счет вклада Google и большей интеграции с K8s. Со временем проект стал интересен крупным вендорам, так что видны его перспективы.
P.S.
Читайте также в нашем блоге: