在初步迁移到云端后，企业往往会发现其基础设施成本出乎意料地高。无论初始规划和成本估算过程多么完善，最终成本几乎总是超出预期。
按需配置云资源可以节省资金，但在初期，由于资源的配置便捷性和速度，它反而会导致基础设施使用量增加。但企业不应因此气馁，基础设施团队也不应以此为由收紧安全策略或从工程团队手中收回灵活性。实现高灵活性与低成本并存是可行的，但这需要经验、合适的工具以及对开发流程和公司文化进行小幅调整。
在本文中，我们介绍了五种我们用来帮助企业降低云成本并有效规划云迁移的策略。
轻量级 CI/CD
在我们的一篇近期文章中，我们讨论了企业如何迁移到微服务架构，但往往忽略了重构发布流程。单体应用的发布流程可能导致集成环境臃肿。不幸的是，在数据中心时期因测试环境匮乏而长期受挫的团队，在迁移到云端时往往会过度补偿，配置了过多的环境。云端配置的便捷性使这一情况变得更加严重。
不幸的是，大量的非生产环境并不能帮助加快产品上市速度。相反，即使整个流程已实现自动化，它仍可能导致发布流程变得更长且更脆弱。
如果您注意到非生产环境的成本正在上升，您可以通过实施轻量级持续交付流程来降低总体云成本。实施该流程的关键变更包括：
- 将测试转移到独立的单个微服务或应用层面。如果设计得当，大多数缺陷可以在服务级测试阶段被发现。正确实现桩模块（stubs）和测试数据可确保高测试覆盖率。
- 减少集成测试环境的数量，包括功能集成、性能集成、用户验收测试（UAT）和预发环境。
- 采用服务网格以及在应用和微服务之间的智能路由。服务网格允许多个逻辑“环境”在生产环境的安全边界内共存，并支持直接在生产中以“暗启动”模式测试服务。
- 引入现代持续交付工具，以简化 CI/CD 流水线，在生产环境中实施安全的暗启动，并启用受控且可监控的金丝雀发布。
请参阅我们的上一篇关于此主题的详细文章。
应用现代化：容器、无服务器和云原生技术栈
云迁移中的“平移和迁移”（lift and shift）策略正变得越来越不受欢迎，但只有少数公司选择深入进行应用现代化，将其工作负载迁移到容器或无服务器计算上。直接将应用程序部署在虚拟机（VM）上是可行的方法，可以与不可变基础设施、基础设施即代码以及轻量级 CI/CD 需求保持一致。对于某些应用程序，包括许多有状态组件，这是唯一可靠的选择。然而，基于 VM 的部署会带来基础设施开销。
由于更密集的打包、更大的机器以及异步工作负载回收未使用的容量，容器集群的资源（内存、CPU）开销可能减少 30% 或更多。
与基于 VM 的工作负载相比，容器通过更密集的打包和更大的机器提高了约 30% 的资源（内存、CPU）利用率。异步作业进一步通过回收未使用的容量来提高效率。
好消息是，容器平台在过去几年中已经显著成熟。大多数云提供商都支持作为服务的 Kubernetes。除了极少数打包好的遗留应用程序或非标准技术栈外，基于 Kubernetes 的平台可以支持大多数应用程序工作负载并满足企业要求。
是否将有状态组件（如数据库、缓存和消息队列）托管在容器中仍然是一个开放的选择，但即使仅迁移无状态应用程序也能降低基础设施成本。如果有状态组件不托管在容器平台上，可以使用各类云服务。我们最近发表了一篇文章，比较了部分云数据库和企业数据仓库（EDW）。
更高级的现代化可能包括迁移到无服务器部署。现代的云容器运行时，在特定约束的无服务器平台和常规 Kubernetes 基础设施之间提供了中间方案。根据用例的不同，它们也可以有助于节省基础设施成本。此外，使用云服务还减少了与配置、设置和维护相关的人力成本。
响应式和前瞻性扩展
企业可以实现两种类型的扩展能力，以提高云资源的利用率并降低云成本：响应式自动扩缩容和基于 AI 预测的扩缩容。响应式自动扩缩容最容易实施，但仅适用于不需要长时间启动和预热时间的无状态应用程序。由于其基于运行时指标，它不能很好地处理流量的突然激增。在这种情况下，可能会在不必要时配置过多实例，或者新实例配置过晚，导致客户体验性能下降。配置为自动扩缩容的应用程序应设计和实现为能够快速启动和预热。
预测性扩缩容适用于所有类型的应用程序，包括数据库、其他有状态组件以及启动和预热时间较长的应用程序。预测性扩缩容依赖于分析和过去流量、性能和利用率的 AI 和机器学习，并提供对所需基础设施规模的预测，以应对即将到来的流量高峰或低谷。
在我们过去的实施中，我们发现大多数应用程序都有明确的每日、每周和年度使用模式。这既适用于面向客户的应用程序，也适用于内部应用程序，但由于客户与企业互动方式的自然波动，它在客户应用程序中效果最佳。在更先进的情况下，可以使用内部促销和销售数据来预测未来的需求和流量模式。
关于扩展能力，无论是自动扩缩容还是预测性扩缩容，都需要提醒一点。大多数云提供商为稳定的 CPU 容量或其他云资源的持续使用提供折扣。如果扩展能力无法带来比云折扣更好的节省，则无需实施。
按需和低优先级工作负载
为了同时利用动态可扩展性和云折扣以持续使用资源，公司可以实现对低优先级工作负载的按需配置。这类工作负载包括深度测试、批量分析、报告等。例如，即使在使用轻量级 CI/CD 的情况下，公司仍需要在测试或生产环境中执行服务级别测试或集成测试。CI/CD 流程可以设计为将大量测试与低生产流量时段对齐。对于面向客户的应用程序，这通常对应于夜间。大多数云服务提供商允许在虚拟机停机后以不同工作负载重新配置时继续使用获得折扣，因此公司无需牺牲部署的灵活性，并可以复用现有的配置和部署自动化。
环境按需配置的重要方面是在不再需要时立即销毁它们。我们的经验表明，工程师经常在不使用环境时忘记关闭它们。为了避免依赖人工操作，我们将关机实现为持续交付管道的一部分，并实施环境租赁系统。在后一种情况下，每个新创建的环境都会获得一个租约，如果所有者没有明确续租，则租约到期时将被销毁。还需要单独的监控进程和云资源的垃圾回收，以确保所有未使用的资源都会被销毁。
我们在多个客户实施中有效使用的另一项节省成本措施是使用提供有限 SLA 保证的深度折扣云资源。此类资源的示例是竞价实例或可抢占实例。它们代表未使用的容量，价格比常规虚拟机实例便宜几倍。这些实例可用于构建 - 测试自动化和各种对重启不敏感的批处理作业。
360 监控
那句著名的格言“无法衡量就无法管理”同样适用于云成本。在监控云基础设施时，一个显而易见的选择是使用云工具。为了充分利用成本监控，必须以正确的方式组织云资源，以便能够按以下方式衡量成本：
- 部门
- 团队
- 应用程序或微服务
- 环境
- 变更
虽然前几点可能显而易见，但最后一点可能需要进一步澄清。在现代持续交付实现中，几乎每次对源代码仓库的提交都会触发持续集成和持续交付流水线，进而为测试环境配置云基础设施。这意味着每次变更都伴随着相关的基础设施成本，应当对其进行衡量和优化。我们已在其他文章中更详细地探讨了如何衡量变更级别的指标和关键绩效指标（KPIs），详见《持续交付蓝图》。
存在多种正确衡量云基础设施成本的技术：
- 按部门、团队或应用程序组织云项目，并将这些项目的成本和账单与部门或团队的预算相关联。
- 使用部门、团队、应用程序、环境或变更标签对云资源进行标记。
- 使用工具，包括云成本分析和优化工具，或使用提供持续效率用于衡量、报告和优化基础设施成本的功能。
通过适当的成本监控和合适的工具，公司应该能够充分了解低效问题，并应用上述我们概述的成本优化技术之一。
结论
云迁移对任何组织来说都是一项充满挑战的任务。虽然提前估算云基础设施成本很重要，但当公司发现实际账单高于最初预期时，不应因此气馁。首要任务是确保应用程序正常运行，避免对业务造成中断。随后，公司可以采用上述策略来优化云基础设施规模并降低云成本。我们已帮助众多《财富》1000 强企业在云迁移的初始阶段及之后优化云成本。