Pull to refresh

Comments 7

Еще было бы весьма недурно чтобы вся эта история вертелась на децентрализованной основе.
например когда базы, скрипты, файлы распределены по плоской инфраструктуре нод-хранилищ с контролем целостности
на ум приходит Swarm
Есть вот такая штука: ether1.org
Там не FaaS, но сайт в децентрализованной структуре можно хостить.
Позвольте с вами не согласится по поводу исправления ошибок.
Для более-менее нетривиальной serverless задачи там уже десятки-сотни РАЗНЫХ функций и найти в какой функции у вас сбоит — та еще задача. К тому же часто еще и сбой не проявляется при локальном тесте.
Все-таки serverless сейчас уже далеко не только функции. Мне нравится в этом случае определение и сервисы Google.

Определение:
— нет управления инфраструктурой (включая автоматическое масштабирование)
— отсутствие оплаты за простой (оплата за реальное использование)
— безопасность на стороне поставщика

И их 3 основных сервиса:
— функции
— AppsEngine (свой фреймворк приложений для нескольких языков)
— Cloud Run (любой контейнер без состояния, который реагирует на http)

Как по мне, всё приложение на функциях писать неудобно
(поэтому и появились всякие фреймворки для функций, но все равно сложно),
AppsEngine несколько ограничен и заточен на Google (первый serverless сервис, который никак массово не взлетает, в о основном из-за зависимости кода от Google),
а Cloud Run — выглядит как раз как то, что надо.
Да, можно сказать, что serverless уже не только про функции. Отчасти это правда. Serverless сегодня и про микросервисы, менеджмент которых берет на себя провайдер услуги. Но функции для serverless — основа, то с чего всё началось, и то на чем легко объяснить принципы, как мне кажется.

С моей точки зрения Cloud Run не может считаться полностью попадающим под определение serverless, так как на разработчика всё равно ложится необходимость написания docker-файла. На мой взгляд это дополнительная сложность. Хотя сама идея выглядит многообещающей.
Sign up to leave a comment.