У вас есть экземпляры контейнеров Azure, которые даже не похожи на Google Cloud Run. У вас может быть экземпляр GCE с одним контейнером.
Вы можете запускать контейнеры на платформах PaaS, таких как Служба приложений Azure и AppEngine Flexible, при этом к вам добавляются дополнительные инструменты, такие как SSL, балансировка нагрузки, CDN и т. д.
У AWS есть собственные ECS, AWS Fargate и Beanstalk.
Развертывание контейнера в бессерверной модели (Azure Container Instances/Google Cloud Run/AWS Fargate) кажется полезным, однако оно не стандартизировано за пределами формата контейнера. В большинстве случаев он предназначен для запуска одного контейнера, когда вам не нужны все навороты PaaS, запуск инструмента или короткое пакетное задание. ACI и Fargate могут обслуживать долго работающие контейнеры, Cloud Run больше похож на FaaS для контейнеров.
Для любого более требовательного решения Kubernetes определенно подойдет. Требуется немного больше понимания и настройки, но у каждого облачного провайдера есть услуга Kubernetes. Вы можете относиться к этому как к стандарту.Трудно сказать, какой из них CaaS...
передовые технологии
в этом пространстве.
Длинная версия
Ключом к пониманию следующего прогресса является концепция «как услуга»:
Выделенный → IaaS → CaaS → FaaS → PaaS → SaaS Это означает, что вы платите деньги внутренней или внешней команде за размещение службы, на которой вы развертываете свое бизнес-решение. Да, вы можете использовать контейнеры поверх выделенного аппаратного сервиса. Вы можете использовать контейнеры поверх IaaS. Тем не менее, вам придется позаботиться о проблемах низкого уровня, таких как установка и исправление операционной системы. Если вы просто арендуете виртуальные машины у поставщика облачных услуг, вы не арендуете контейнерное решение как услугу. Когда люди говорят о CaaS, они обычно имеют в виду «оркестрацию контейнеров как услугу». Примеры включают службу Amazon Elastic Kubernetes, службу Azure Kubernetes и Google Kubernetes Engine, службу IBM Cloud Kubernetes и службу контейнеров Alibaba для Kubernetes. Существует огромная разница между развертыванием программного обеспечения в кластере Kubernetes, который кто-то другой настроил, защитил и затем автоматизировал для вас, и необходимостью самостоятельно настраивать кучу виртуальных машин IaaS для надежного запуска контейнеров. Высокопроизводительные установки Kubernetes используют специализированные «единые цели».
операционные системы
так что серверы больше похожи на устройства, чем на типичные виртуальные машины. Идея состоит в том, что кластер (как ОС, так и программное обеспечение Kubernetes) может быть исправлен для безопасности в виде последовательного обновления без простоя служб, размещенных в кластере.
Урок истории ;-)
Историческая ситуация примерно в 2011 году, до выпуска Docker в 2013 году, была бы такой:
Выделенный → IaaS → PaaS → SaaS
В этом отношении именно PaaS, ИМХО, представляет собой расплывчатую классификацию, которая со временем изменилась с появлением контейнеров. Примерами ранних решений PaaS, появившихся до контейнеров, являются оригинальный Heroku, оригинальный CloudFoundry и ранние версии RedHat Openshift. Они были «платформами DevOps» до того, как был изобретен термин DevOps. В первоначальных версиях использовались некоторые методы Linux, которые позже прославили контейнеры, но это была внутренняя деталь. Основные маркетинговые аргументы были двоякими. Во-первых, это производительность разработчиков благодаря встроенному CI/CD, а во-вторых, серверы легко обновлять и администрировать. К серверам относились как к овцам, а пакеты обновлений, поставляемые поставщиками, обеспечивали их безопасность.:
Проблемы исходной концепции PaaS заключались в отсутствии стандартизации, привязке к поставщику, недостаточной переносимости, а также в наличии собственных инструментов. У них были встроенные и собственные системы сборки, а также собственные механизмы настройки и развертывания. Оркестраторы контейнеров с открытым исходным кодом произвели революцию, решив эти проблемы. Крупные PaaS-решения с открытым исходным кодом, такие как OpenShift, CloudFoundry и Mesphere, теперь поддерживают Kubernetes. Пользователям больше не нужно использовать собственный конвейер сборки и развертывания, а также собственные механизмы настройки. Они могут использовать огромное количество различных инструментов для создания контейнеров, которые они размещают в любом количестве размещенных реестров контейнеров. Затем они могут использовать Kubernetes API для развертывания в выбранном ими облачном провайдере. ИМХО, первоначальная концепция PaaS «быстрого создания, развертывания и настройки веб-приложения» стандартизирована в CaaS в качестве основной среды выполнения. Дополнительная информация.
если вы хотите узнать, что можно сделать с кассой CaaS
мой блог о полной автоматизации стартапа Обновлять: очень информативно. Около 2:45 сравнивается PaaS, CaaS и FaaS. В докладе рассказывается о KNative, а в конце, около 32:07, KNative сравнивается с PaaS, CaaS и FaaS. В презентации говорится, что определение CaaS в Kubernetes довольно упрощенное и в нем не хватает многих «очевидных» вещей, если вы знакомы с PaaS. И KNative, и OKD (Openshift) демонстрируют, что можно построить платформу другого типа (PaaS, FaaS) поверх простого CaaS Kubernetes.