我将尝试总结我所知道的，但请注意，我没有参与过 KubeFlow 项目。
Databricks 上的 Kedro
我们的方法是使用 CI 构建我们的项目，然后从笔记本执行管道。我们没有使用kedro recommended approach 来使用databricks-connect，因为在作业和交互式集群之间有large price difference（DB-connect 需要这些large price difference）。如果您正在处理数 TB 的数据，这很快就会变得相关。
作为 DS，这种方法可能感觉很自然，但作为 SWE，尽管它不是。在笔记本中运行管道感觉很笨拙。它有效，但感觉非工业化。 Databricks 在自动启动和关闭集群并为您处理运行时方面表现良好。因此，他们的附加值正在将 IaaS 从您手中抽象出来（稍后会详细介绍）。
GCP 和“云原生”
专业版：GCP 的主要卖点是 BigQuery。这是一个非常强大的平台，仅仅因为你可以从第 0 天开始就保持高效。我见过人们在它之上构建整个 Web API。 KubeFlow 不绑定到 GCP，因此您可以稍后将其移植到其他地方。 Kubernetes 还允许您在集群、API、流媒体、Web 服务、网站上运行任何您希望的东西。
缺点：Kubernetes 很复杂。如果你有 10 多名工程师长期运行这个项目，你应该没问题。但不要低估 Kubernetes 的复杂性。它之于云就像 Linux 之于操作系统世界一样。考虑日志管理、嘈杂的邻居（一个用于 Web API 的集群 + 批量 Spark 作业）、多集群管理（每个部门/项目一个集群）、安全性、资源访问等。
IaaS 服务器方法
您的最后一种选择，手动安装服务器是我推荐的一种方法，只有当您拥有一个庞大的团队、非常大的数据并且正在构建一个收入可以承受大量维护成本的长期产品时。
背后的人
您所在地区的人才市场如何？如果您可以聘请具有 GCP 知识的经验丰富的工程师，我会选择第二种解决方案。 GCP 是一个成熟的“原生”平台，因为它为客户抽象了很多东西。如果您的市场主要有 AWS 工程师，那可能是一条更好的选择。如果您有许多 kedro 工程师，那也有相关性。请注意，kedro 是不可知论者，可以在任何地方运行。真的只是python代码。
主观建议：
我主要从事 AWS 项目和一些 GCP 项目，因此我会选择 GCP。我会使用平台的组件（BigQuery、Cloud Run、PubSub、Functions、K8S）作为一个工具箱来选择并围绕它建立一个组织。 Kedro 可以在任何这些上下文中运行，作为调度程序触发的作业、作为 Kubernetes 上的容器或作为将数据引入（或引出）BigQuery 的 ETL 管道。
虽然 Databricks 比原始 AWS “管理更少”，但仍然需要考虑服务器和 VPC 网络费用。 BigQuery 只是 GB 查询。函数只是调用计数。这些高级组件将使您能够快速向客户展示价值，并且您只需要在扩展时更深入（RaaS -> PaaS -> IaaS）。
AWS 在 IaaS 上也有这些更高级别的抽象，但总的来说，（在我看来）Google 的产品是最成熟的。主要是因为他们发布了他们在内部使用了近十年的工具，而 AWS 为市场构建了新工具。不过，AWS 是 IaaS 之王。
最后一点内容，two former colleagues have discussed ML industrialisation frameworks earlier this fall