在使用 Cloud Run/Cloud Functions 之后，我认为几乎每个不是自己本身就是云服务提供商的公司……

每次我推动在那些处于或倾向于使用Kubernetes的工作中使用云运行时，都被视为一个不严肃的人。就像如果你不是整天与YAML配置和ArgoCD作斗争，你就不能成为“真正的”工程师（甚至在深夜也是如此）。

这里有很多内容需要分析。 根据最近的经验，我只想说问题不在于Kubernetes本身，而在于Kubernetes不是一个产品平台；它是一个基础架构，而大多数组织实际上想要的是一个平台。 我们最近移除了一个基础的Kubernetes产品（类似于Rancher但不是Rancher）。它托管了我们很多软件开发应用，如GitLab、Nexus、KeyCloak等。 但为了运行这些应用，你必须构建一个完整的平台并将它们全部连接起来。这是在本地运行在vXRail上的。 我们最终发现，我们公司有一个基于EKS-A的内部软件开发平台，它带有自动安装程序，包含所有应用，并包括ArgoCD来维护状态和协调新部署。 之前的团队在DIY之前平台时做得非常糟糕。因此我们转而使用了一个更易维护的平台。 如果有人制作了这样的产品，我相信很多人会很乐意使用。…

既然你们正在这个领域进行开发。我们遇到的问题是，无论是lambda还是cloud run这类托管解决方案，似乎都无法与我们的服务网格兼容。Cloud run和lambda无法与GCP服务网格集成，除非也是通过GCP进行管理。任何自定义的东西都不在考虑范围内。由于我们需要端到端的mTLS，因此我们不能使用cloud run。 在我看来，这表明cloud run更像是一个最终产品，而不是一个构建模块，它阻碍了采用，因为我们基本上需要自己复制大部分cloud run的功能，只是为了添加运行我们的Sidecar的那一点点功能。 在你们的新解决方案中，你如何看待这个问题？

如果你想要使用的话，有很多运行在k8s上的PaaS组件。我不太喜欢，因为我认为直接给开发人员访问k8s的权限是更好的模式。 托管的k8s服务如EKS近几年非常可靠。 YAML没问题，它只是配置语言。 > 你不应该在这个粒度级别上考虑扩展和供应，它应该始终在多租户区域级别，这是Kubernetes犯下的一个基本错误，而Borg处理得更好 我不确定你是什么意思。托管的k8s服务，甚至你自己部署的k8s集群，都可以跨AZ自动扩展。这个功能已经存在很多年了。你只需要在你的pod模板规范中设置一个拓扑键，你的pod就会跨AZ分布，很简单。 大多数你想部署应用程序的任务，k8s已经有现成的解决方案了。…

> 实时使用情况 -> 计费 这正是让我对TigerBeetle感到兴奋的地方；云服务提供商之所以只能以每小时的粒度报告计费，是因为底层系统运行的是批量作业来计算最终的计费金额。拥有一个能够跟上实时计费的数据库是一个游戏规则的改变者，我们甚至还没触及它所能实现的表面。