关于Azure Container Apps，我们还需要另一个托管容器服务吗？

在本月早些时候的Ignite 2021大会上，微软宣布了一个新的无服务器容器平台的公开预览，该平台被命名为Azure Container Apps。它是Azure计算服务的最新基于容器的产品。

微软将Azure Container Apps定位为AKS的平台即服务（PaaS）层。它带来了一个熟悉的工作流，即部署一个或多个容器镜像并带着URL或端点离开。在幕后，Container Apps运行在基于AKS的隐藏的抽象Kubernetes集群之上。

今年早些时候，亚马逊推出了App Runner——一种在AWS上运行容器化应用的托管服务。正如Duckbill Group首席云经济学家Corey Quinn所指出的，App Runner成为第18个在AWS上运行容器的服务。从Elastic Beanstalk到AWS Fargate，亚马逊的云有着压倒性的容器服务选择。

谷歌云也不例外。要部署容器化工作负载，你可以将App Engine Flex、Google Kubernetes Engine、GKE Autopilot和Cloud Run作为目标。

虽然Kubernetes架构和API已经标准化和成熟，但堆栈中仍然缺少开发人员的经验。云提供商无法提供Kubernetes的PaaS层，这一事实有力地说明了这一点。

是什么促使云提供商几乎每季度都向产品组合中添加新的容器服务？

Kubernetes的复杂性持续增长

Kubernetes是一个元平台——一个设计用于构建其他平台的平台。但即使在推出7年后，业界仍在致力于良好的开发者体验。

在Kubernetes之上缺乏开源的、可移植的PaaS/应用程序层是开发人员发现难以应用Kubernetes的关键原因之一。

在过去几年中，云原生生态系统有了重大发展。存储、网络、服务网格、可观察性和安全领域的进步推动了这一进程。它们正在帮助Kubernetes和云原生堆栈真正企业就绪。另一方面，它们也增加了堆栈的复杂性。

尽管可以保证Kubernetes API是相同的（不用考虑托管服务选项），但在不同的云环境中运行的平台层并不一致。你可能会争辩说，AWS App Runner、Google Cloud Run和新开发的Azure Container Apps等服务提供了开发者体验。虽然这对于处理少数容器的简单工作负载可能是正确的，但部署、扩展和管理复杂的多容器应用程序是困难的。

需要一个可移植的云原生平台层

Knative和Dapr等项目试图减少在Kubernetes上运行复杂工作负载所需的管道。但是，它们仍然需要一个抽象层来提供无缝的开发人员体验。

Knative是一个基于Istio服务网格的平台，专注于为Kubernetes带来无服务器功能。服务和事件功能作为一组API公开，供开发人员在Kubernetes上部署和扩展容器。但是，Knative本身并不是PaaS层。它通过简化和聚合的API层抽象底层的Kubernetes和Istio API。

分布式应用程序运行时（Dapr）也采用平台方法，提供开发微服务的核心构建块。它公开了一个可插拔的模型，可以轻松地交换对象存储、缓存、消息传递和数据库等服务，而无需更改代码。最近，Dapr已作为孵化器项目提交给CNCF。

KEDA是另一个开源项目，也是CNCF孵化器项目。它是一个基于Kubernetes的事件驱动的自动伸缩引擎，可根据外部因素（如队列中的消息数量或来自Prometheus的自定义指标）伸缩工作负载。KEDA和Knative Serving的最终目标是相同的——提供一个零规模的基础设施，以优化资源利用率并降低计算成本。

Dapr和KEDA之间的共同点是，这些项目由Microsoft和红帽支持和维护。

作为Knative的主要贡献者，谷歌已经在GKE上基于Knative构建了Cloud Run专有层。Cloud Run是公共云中可用的简单但功能强大的无服务器容器平台之一。

Cloud Run是Knative和类似PaaS的开发人员体验之间缺失的环节。与Knative不同，Cloud Run不是一个开源项目。谷歌正利用这一点在其公共云（GKE）和混合云（Anthos）平台上提供差异化体验。

借鉴谷歌的playbook，微软现在将Dapr和KEDA结合起来，以Azure Container Apps的形式提供新的容器服务。它是一个多租户的隔离层，运行在预先配置了Dapr和KEDA的AKS集群之上。与Cloud Run一样，你不必配置托管AKS集群并在其上安装Dapr和KEDA。Container Apps附带了基于Dapr、KEDA和Envoy代理的预配置环境。

因此，Azure Container Apps对Dapr+KEDA的作用就如同 Google Cloud Run对Knative的作用一样。

很明显，谷歌和微软等平台提供商正在利用其开源投资，在其云平台上提供不透明的托管服务。这没有什么问题，但它突出了Kubernetes缺乏开源、基于标准、可移植的应用程序平台。

Kubernetes上的应用程序平台碎片化不健康

从长远来看，云原生应用程序层和专有实现之间不断扩大的差距将损害生态系统。即使容器镜像是堆栈中最低的公分母，在这些黑匣子服务上运行的应用程序的打包和配置也截然不同。

在Kubernetes的上下文中，有效的部署/pod定义必须在任何集群管理或自托管的环境中运行——这与托管应用程序服务不同。针对AWS Fargate的微服务工作负载无法轻松迁移到Azure Container AInstances或Container Apps。此外，在这些托管服务中，将多个容器缝合在一起作为单个基于微服务的工作负载很难运行和扩展。

我们需要的是一个可移植、透明、开源的应用程序层，它将在部署在开发人员笔记本电脑上的Minikube集群或公共云中配置的大规模多节点集群中持续运行。我们正在等待一个平台层，它可以将Knative、Dapr和KEDA的优点带到Kubernetes，而没有锁定。

原文链接：

https://thenewstack.io/azure-container-apps-do-we-need-yet-another-managed-container-service/