Платформа как услуга: история, роль и проблемы
"Платформа как услуга" или PaaS (Platform-as-a-service) существенно упростила разработку программного обеспечения. История PaaS началась в 2006 году с Force.com, затем последовали Heroku, AWS Elastic Beanstalk и DotCloud, который впоследствии преобразовался в Docker.
Сегодня сфера PaaS контролирует значительную долю рынка облачных технологий, оцениваемую в 170 млрд долларов. Однако компании все еще сталкиваются с проблемами ручного развертывания и управления жизненным циклом нагрузки. Почему же PaaS не стала более широко распространенной?
Версатильность и ограничения PaaS
PaaS-платформы могут быть более гибкими, и я не говорю только о совместимости с языками и фреймворками. PaaS часто определяют как универсальное решение для развертывания любого приложения, но есть подвох. В данном контексте под приложениями обычно подразумеваются 12-факторные приложения.
Однако многие рабочие нагрузки не соответствуют обычным веб-приложениям; они имеют уникальные требования, такие как задачи пакетной обработки, высокопроизводительные вычислительные задачи, GPU-интенсивные задачи, приложения, ориентированные на работу с данными, или даже задачи квантовых вычислений.
Необходимость изменений в использовании PaaS
Важно отметить все преимущества, которые предоставляет PaaS. Компании должны управлять всеми своими рабочими нагрузками наиболее удобным образом, и абстрагирование их развертывания и управления - это путь к этому. Необходима смена подхода. Во-первых, компании, принимающие парадигму PaaS, должны признать, что не будет универсального решения для всех рабочих нагрузок.
Новый подход: API рабочей нагрузки
Бывший инженер Google, Келси Хайтауэр, подтверждает это предположение о том, что единая, всеобъемлющая PaaS всегда будет маловероятной. Он также использовал термин API рабочей нагрузки для обозначения инструмента, который обеспечивает этот бесшовный опыт "вот мое приложение, запусти его для меня". Такое определение четко указывает на цель: запуск конкретной рабочей нагрузки. В отличие от PaaS, который требует более точного определения и приводит к путанице, что PaaS - это универсальное решение для запуска любых приложений. Этот термин будет использоваться в остальной части статьи.
Второе изменение для компаний, которые хотят предоставить бесшовный опыт развертывания и управления для всех своих рабочих нагрузок, заключается в том, что каждая рабочая нагрузка должна иметь свой собственный API. Например, Amazon Lambda может быть использован для пакетных заданий, Vercel - для front end, Vertex AI - для моделей машинного обучения, а Korifi - для веб-приложений.
Теперь давайте рассмотрим, как выбрать API для рабочих нагрузок.