写给决策者的10条云计算准则

企业数字化转型的一大关键就是“上云”，然而上云并不是简单的上或上哪家云，还有更多因素需要综合考虑。本文作者根据其多年的云计算行业从业经历，总结了云决策的十条准则。

在 Trek10（一家云计算行业服务企业）工作的几年时间里，我与几十家公司（包括初创公司和财富 100 强公司）进行过合作，帮他们的业务和技术决策者组建云团队和构建云端应用程序。

尽管这些公司认为他们面临的挑战都是独特的，但事实上，他们经常一次又一次地遇到同样的问题。

现在我已经结束了在 Trek10 的工作，我想把自己总结的云决策的十条准则分享出来。

我把它们分为两组：一组是给业务决策者（执行人员）的，另一组是给技术决策者（工程师和技术经理）的。

第一组：给业务决策者的建议

1. 云不只是个技术问题

人们普遍认为敏捷或 DevOps 转型是一种自上而下的组织变更，涉及新的责任、新的工作方式和新的团队沟通方式。你不能只是盲目买了“一盒 DevOps”（尽管有人会试图把它卖给你），就满怀期待它能取得成功。

采用云也是一样的道理。不要把云看成是一种用来交付旧技术和旧工作方式的替代工具。“简单粗暴的迁移”心态最终会导致云采用失败，让你付出高昂的代价。

在成功的“云”业务中，开发、运营、安全性甚至是财务都采用了新的配置。所以，请花点时间去理解和拥抱变化。

2. 做好培训

要采用云，你不能只是简单地自上而下传达组织命令，然后站在一旁，期待接下来会有好事情发生。

采用云需要在技术技能和团队职责方面发生巨大转变。市场上了解云技术的人不多，虽然可以寻求外部的帮助，但最终还是需要企业内部自己计划去积累专业知识。

在大型企业中，建立云中心是一个好的开始，但我更多地是看到他们的这些努力变成了一个又一个孤岛。你不能只是组建“云团队”，你还需要广泛地培养云文化。这意味着企业需要在几个月或几年的时间内耐心地在整个组织中扩展云能力。

培训确实需要耗费高昂的成本，但你要知道，云的意义在于它可以让你用相同数量的人力创造出更大的价值。所以，重新分配你的招聘预算，把其中一部分用于培训你的团队，他们将会给你带来惊喜。

设定正确的优先级，提供适当的激励，你会发现你的员工在慢慢地发生转变。

3. 把云看成价值中心

一些企业之所以选择云，主要是为了节约成本，尽管这类企业的数量与过去相比有所减少。他们有充足的理由。但实际上，选择云并不是为了花更少的钱，而是为了创造更多的价值。

这就是为什么我喜欢“云就是 IT 杀手级应用程序”的说法：就像电子表格在早期的个人电脑上所扮演的角色一样，云也足以证明 IT 成本的合理性。

如果你从全局看待企业可以利用的云服务，你会发现，上市时间、创新速度、敏捷性都随着云服务的出现而得到改进。

有些公司看着眼前的云费用账单就头大，因为这是他们唯一能看到和理解的指标——尽管这是一个令人感到痛苦的指标。其他正面的指标，比如时间价值，也并非不可度量，只是它们需要经过深度的努力才能建立起来。

先进行试验，确定你的成功标准，然后你会发现云的价值将远远超过其成本。

4. 从小处着手，但不要浪费时间

人们很容易被困在云采用的边缘地带，可能数月，甚至是数年。在最近的一个 re:Invent 主题演讲中，Andy Jassy 例举了一个案例，一家企业吹嘘自己采用了云，但实际上只是部署了几个小的实验场景而已。虽然这种做法让技术团队具备了吹牛的资本，但对业务来说没有任何价值。

你不可能一开始就把所有的东西都弄好，但不要让它阻碍你起步。从小处着手，认真运营，找出不足之处，改进它，重复这个过程，并向外扩展学习。

认真对待云，好的结果就会随之而来。

5. 信任你的合作伙伴

是什么导致企业在采用云时被困住数月甚至是数年？其中一个原因是他们知道他们要面对复杂的变化，但他们又不想出错。

因此，在采用云时有必要引入值得信任的合作伙伴——他们之前已经走过了这条路，知道哪里有陷阱，知道有哪些捷径可走。

找到你信任的云计算和咨询合作伙伴，然后让他们帮你实现持久和积极的改变。

第二组：给技术决策者的建议

6. 不要因为熟悉就选择某一项技术 在进行技术决策时，很多人建议对于大多数问题可以采用久经考验的解决方案。

在不会发生颠覆性大变革的时代，这算是个好建议。但是，云计算改变了计算方法，一些新技术的出现从根本上把人类从繁琐的事务中解放了出来，并增加了交付内容的规模和能力。

例如，AWS 的 Amplify 服务已经迅速改变了移动开发和后端开发的目标。低代码、以模式为中心的 API 开发方式非常棒，与云原生数据存储紧密集成更为先进。因为 AppSync 后端是云服务，所以它可以随时做出改进，不需要你做任何事情。尽管你可能需要几周时间才能完全掌握它，但在学习上投入的时间会在后续带来无尽的回报。

关键问题是，你的感觉可能会背叛你。所以，你需要冷静地评估哪些工具和服务能给你带来最大的收益。

7. 时间是最宝贵的资源，需要合理利用

你每天接触到的最昂贵的资源不是生产数据库集群、应用服务器群或日志，而是时间。

你和团队用于构建和维护技术栈的时间是有限的，不要把它们浪费在重新发明轮子上。

以我自己为例，我在上一份工作中花了大量时间从头开始构建一个完整的技术栈部署框架和管道工具。部署管道最终确实为业务提供了一些价值，但代价是花费了我们数千小时。

如果我和我的团队可以更多地利用现有服务，那就可以在更短的时间内交付相同的功能，并完成具备更高价值的项目，而不是不断地向管理层证明我们正在做的事情是对的。

云原生开发优先使用预构建的服务，可以为你节约更多宝贵的时间。

8. 尽早进行云开发

我一直鼓励“在本地测试代码，在云端提供服务”。随着无服务器开发的崛起，云端与本地相分离的开发环境的价值变得越来越低。

如果有必要，可以在本地迭代代码，并根据部署在远程的角色和资源对其进行测试。在开发中越早这么做，会越快发现权限和配置问题，在生产环境中出现的意外事故就会越少。

以我最为了解的供应商 Stackery 为例。我很喜欢他们“云本地（cloudlocal）”的开发理念，尽管我怀疑这个名字是否会流行起来。据我所知，他们的 CLI 是目前唯一支持在本地运行 AWS Lambda 函数（与部署在云端的远程角色相关联）的工具。在调用本地函数时，它会将信任关系注入给角色。我预计后续会出现其他大型的无服务器部署框架（AWS SAM 和 Serverless Framework），为此提供更好的支持。

9. 不要浪费时间解决不存在的问题

你认为工作中有很多真实存在的问题，哪里会有假问题。但不幸的是，软件工程师很擅长为无关紧要的问题寻找解决方案。

例如，你的某款应用程序真的有必要支持多区域吗？如果 AWS 美国东部地区发生宕机，你的应用程序需要提供可用性吗？你需要花多少时间来保持跨区域事务的一致性？你需要花多少钱来复制数据？

可移植性更是一个巨大的假问题。正如一些人所说，如果你正在使用 Kubernetes，那么你一定很聪明。协调服务网格、服务代理、入口路由等等，它们都是非常复杂的任务。

我甚至看到人们用复杂的抽象层构建无服务器应用程序，这样他们就可以在有必要更换云提供商时替换技术。

真正明智的技术决策者都知道，你可以成为某个领域的专家，但这个领域是很小的。你可以利用云服务提供的现有架构，并在其上构建自己的功能。

如果你一定要使用 Kubernetes，可以考虑 EKS on Fargate 或 SpotInst Ocean 之类的托管服务，它们已经帮你抽离出大量的东西，并在超低价的 spot 实例上编排容器。

不用说，通过与供应商更紧密地集成，可以让你获得很多优势。除非云供应商表明他们将要进行价格锁定（到目前为止还没有发生这种情况），否则你可以把时间花在更有价值的特性交付上。

我做这些决定的原则很简单：不要“写代码的时候很聪明，却在云这件事情上犯傻”。

10. 展示价值

作为一个技术决策者，一个对代码有实践经验的人，你是确定哪种技术最能够影响问题的人。

如果你对一个看起来有明显好处的决策不是很有信心，可以花一些时间在云端对它进行原型化，这样做通常很快，成本很低。

作为一个技术决策者，你可以向业务展示强有力的证据：看，我已经构建了你需要的东西，它运行速度快，易于维护。

英文原文

Ten Commandments For Cloud Decision Makers