摘要

  • Google Cloud Modernize 将成本评估、代码与依赖分析、迁移工具及 Google Cloud 目标环境整合到一个组合中。新的 Agentic Quick Estimator 可依据 VMware 资产清单导出文件和基础设施输入，生成迁往 Compute Engine 的 TCO 预测。
  • 预测结果取决于资产数据、容量配置、区域、许可方式及其他假设。它不能证明迁移已完成、生产环境已验收、转型总成本已确定或客户已经实现节省。
  • 商业验证需要一条可对账的链条：核验源环境清单、由客户确认目标与成本假设、成功切换、验收工作负载，并将迁移后的实际账单与同口径基线比较。

Google 于 10 月 6 日宣布推出 Google Cloud Modernize，核心承诺颇具吸引力：通过把评估、代码分析和迁移工具放进一套 AI 辅助组合，缩短可能跨越多年的现代化路线图。这个商业逻辑说得通。企业若能更快盘点服务器、梳理依赖并比较目标配置，决定先迁什么的时间或许会缩短。但更难回答的经济问题要到后面才出现：估算能否经受具体工作负载的检验，验收后的系统在整个迁移过程中是否真的更便宜？

这套组合包含几种不能混为一谈的承诺。Google 称已正式推出 Agentic Quick Estimator：它接受 RVTools 等 VMware 资产清单导出文件和基础设施输入，预测 Compute Engine 环境的总拥有成本。新的 Modernization Hub 可分析 Java、.NET 和大型机应用的代码并映射依赖。EKS-to-GKE 迁移代理则处于公开预览阶段，Google 说它能处理发现、Kubernetes 清单转换、存储映射和网络映射，同时设置人工审批门槛。每项工具服务于不同阶段——估算、理解、转换和验证；任何一个阶段都不等同于生产切换。(Google Cloud 10 月公告)

估算继承了输入假设

TCO 数字是否有决策价值，取决于源环境画像是否准确，以及目标选项如何设定。Google 文档允许用户手工输入虚拟机、vCPU、内存和存储总量，也可以上传 RVTools 文件；之后选择目标区域、机器系列和存储类型等选项。报告比较的是按这些输入建立的源环境与模拟出的 Google Cloud 配置。如果缺少性能数据，Migration Center 可以依据用户选定的配置策略推荐容量，并标明哪些资产是估算而非实测。这是有用的规划工具，但它仍是模型，不是计量得到的实际消费。(Quick TCO Estimator 文档；TCO 报告文档)

这个区别会影响买方的议价能力。预测可以帮助财务团队判断是否值得资助发现阶段或试点，却不能单独证明目标机器在峰值负载下合适、应用依赖已经完整记录，或完成工程、测试和切换后总运营成本会下降。可靠比较需要相同服务水平与工作负载周期，也要纳入对该客户重要的成本项目：源端与目标端消费、软件许可、网络和存储、迁移人力、可能的并行运行期、运营支持及退出路径。只要用户提供或选择，估算可能覆盖其中部分项目；买家应检查具体报告，而不是假定一个标题数字必然包含全部成本。

Google 自己的 Migration Center 文档把技术适配判断定义为评估，而非商业验收证明。“适配良好”是指基于收集到的源数据，没有发现符合条件的技术障碍；“需要投入后适配”意味着仍可能需要工作。Google 也建议企业盘点集群与工作负载、评估依赖和运维流程、选择迁移策略、制定时间安排并验证计划。这些不是形式步骤，而是把建议变成可安全定价的变更所需的工作。(Migration Center 适配评估；EKS-to-GKE 迁移指南；迁移规划指南)

加速一个环节，不代表漏斗已经跑完

EKS-to-GKE 代理清楚展示了边界。Google 说它可以转换 Kubernetes 清单并映射存储和网络，同时保留人工审批门槛、在内存中保护凭证。这样可能减少重复工作，也让迁移路径更容易检查。公开预览状态则提醒客户，应把它看作仍在发展的能力，而不是适用于所有场景的工作负载测试替代品。网络策略、存储语义、观测、身份、可靠性目标、数据传输和发布程序，仍会影响服务能否迁移。Google 没有披露新代理已完成多少次生产迁移、错误或回滚率，以及客户层面的时间和成本节省。

公告所列客户案例可以提供背景，却不能证明此次发布。Google 表示，NetEase Games 此前在 GKE 上容器化服务后，服务器成本下降 40%，高峰期扩容从数小时缩短到五分钟。博客没有把这项结果归因于 Google Cloud Modernize 或新的 EKS 代理。它证明一家客户曾报告 GKE 部署带来的好处，不是这套 10 月新组合已经产生的测量结果。任何销售材料把历史案例放在新工具旁边时，都应保留这个区别。

大型机、VMware 和应用现代化也需要同样的证据纪律。代码分析可以揭示架构与依赖；双跑流程能在切换前比较输出；目标环境能够提供容量。只有当客户要求的行为得到保留，而且新系统运营成本更低，或新能力足以解释成本差异时，价值才出现。因此，“压缩路线图”是关于工程周期的假设，不是已报告的总成本下降。

买家需要一份经得起切换的账

Google 提供估算器和目标服务，客户则提供大部分资产清单、工作负载优先级和审批；集成商也可能承担交付工作。职责清楚时，这种分工可以提高效率。如果建模目标的一方也销售模型所推荐的容量，而客户又无法复现假设，评估就更难独立判断。这不证明存在利益冲突或估算不准；它说明商业论证应保留输入、带版本的假设和独立基线。

部署后还应继续计量。对每项工作负载，保留源环境需求曲线、目标配置、许可处理、迁移与并行运行成本、验收标准、支持边界以及实际云账单。尽可能在相同负载、时延、可用性、存储与区域下比较。若迁移改变了服务，就应明确报告这项变化，而不是把账单全部差异归因于平台。算力支出下降的同时，数据、支持或网络费用可能上升；版本发布更快，即使直接账单相近，也可能有价值。逐项账本能让两种结果都看得见。

Google Cloud Modernize 可能降低决策和准备工作的成本，但公告没有说明这种效率多常转化为成功的生产迁移或更好的经济结果。客户尚未把可核验的源环境基线、已验收工作负载和实际成本连接起来之前，新工具只是更快抵达一个假设的路径，并不是迁云值得的证明。

来源