云决策十诫

新钛云服

于 2024-04-10 08:00:26 发布

阅读量73

点赞数

原文链接：https://mp.weixin.qq.com/s?__biz=MzU0OTg5MzMzOQ==&mid=2247499776&idx=1&sn=53732a4b4f19ba7391773fed6adea9a1&chksm=fa98852a70381cdbbf8b98faf45fc943d2b5cfbca16366ad9de3c6504d63950542e9ced011a4&scene=126&sessionid=0

版权

本文提供给商业决策者和技术决策者十个关键原则，涵盖了云计算的正确采用策略、培训、价值定位、合作伙伴选择、技术栈选择、优化使用等方面，强调了云计算带来的价值超越成本的重要性。

摘要由CSDN通过智能技术生成

新钛云服已累计为您分享793篇技术干货

在过去几年中，我多次帮助多家企业实现云服务的完善，安全且可靠。虽然这些公司的问题都不一样，但问题类型本质上还是可以归类的。这也是本文将会介绍的十诫。

我将这些多年实践总结出来的十诫分为两种类型：一种是针对商业决策者（高管），另一种针对技术决策者（技术团队中的工程师和管理者）

类型一

面向商业决策者

不要把云仅当着

一个技术问题

敏捷或DevOps转型被广泛认为是涉及某种程度的自上而下的组织变革。这包括新的职责、新的工作方式以及团队之间新的沟通方式。您不能仅仅是指望通过买一个“DevOps Box”就能达到成功。

你的云计算采用与此无异。不要认为云计算仅仅是通过另一种方式交付同样的旧技术和工作方式。“迁移与转移”的思维方式最终会导致昂贵且臃肿的云计算采用失败。

在成功采用云计算作为优先选择的企业中，开发、运维、安全甚至财务等各个方面都会采取新的架构。请花时间理解并包容必需的深层次变化。

从一开始就进行培训

你不能只是下达一个自上而下的组织强制采用云计算的命令，然后就离开，并期望会发生好的事情。

云计算是一场大规模的技术技能和团队职责的转变。拥有对云计算技术的深刻理解的人才并不常见，在市场上也并不易于获得。合作伙伴可以提供帮助，但最终你还是需要有一个计划，从内部培养这种专业知识。

在较大的企业中，建立云计算卓越中心是一个不错的开始，但我也看到过这些努力最终被划分为又一个信息孤岛。你不能只是创建一个“云团队”；你必须更广泛地推动一种文化，这意味着要在几个月甚至几年的时间里，细心设计云计算技能在整个组织中的普及。

是的，培训确实花费是很多，但云计算的本质是让你能够用相同数量的人工实现更高的价值。因此，将招聘预算的一部分转移到培训团队：当你的团队掌握使用由云服务提供商维护的服务时，你会对他们的成就感到惊讶。

设定正确的重点，提供适当的激励措施，你的员工将会逐渐实现转变。

将云计算视为价值中心

我们仍然看到一些企业主要是出于节约成本的考虑选择云计算，尽管这样的企业比以往减少了——并且出于不错的理由。你选择云计算不是为了花更少的钱，而是为了创造更大的价值。

这就是为什么我喜欢把云计算描述为“IT的杀手级应用”的想法：就像电子表格让早期的个人电脑成为可取之处，云计算独自就能超越您IT投资的成本。

如果你的组织能够充分利用，云计算能够提升上市时间、创新速度和敏捷度。

一些公司会在云计费单上陷入困境，因为它是他们能看到和理解的与云计算采用相关的唯一指标——尽管它是一个令人痛苦的指标。成功指标，如价值产生的速度，并不是不可能衡量，但是需要有意识地努力建立和评估。

优先考虑实验，知道成功的标准，您就会发现云计算所产生的价值远远超过了成本。

从小开始，

但不要无准备

很容易陷入几个月或甚至几年的云计算等待期。在Andy Jassy最近的re:Invent主题演讲中，他指出了一家组织，尽管该组织自吹自擂地宣称他们采用了云计算，但实际上他们只是部署了一些小的实验项目。虽然这种方法可能有利于您技术团队的简历打造，但对于业务而言却没有价值。

你在刚开始采用云计算时不会一下子就搞对，但不要让这种担忧阻止你开始行动。选择一个适中的工作负载，认真尝试将其运行在云上，找出短板，进行改进，重复，并不断扩大对云计算的了解。

认真对待云计算，就会得到认真的结果。

信任你的合作伙伴

企业在云计算的门槛处陷入数月甚至数年的困境的一个原因是什么？他们意识到变革可能是复杂的，他们不想出错。

出于这个原因，在云计算的过程中介绍可信的合作伙伴是有道理的——那些在这条道路上走过，既知道陷阱，也知道捷径的人。

（顺便说一句，这也是支持公共云的一个很好论点。你真的认为你能比AWS更好地管理数据中心，或者比微软更好地构建开发者工具吗？对锁定的担忧在历史上是合理的，并且有其存在的价值，但最终你必须与能够适当利用风险的供应商合作。）

寻找你可以信任的云计算和咨询合作伙伴，然后给予他们足够的自由度，让他们帮助你实现持久的积极变化。

类型二

面向技术决策者

不要因个人喜好

选择技术栈

在技术决策中，存在这样一条普遍的建议：对于大多数问题，都应该采用经得起时间考验的长期使用的解决方案。没人因为写了另一个Rails应用程序或者任何类似的东西而被解雇。

这条建议在不发生重大破坏性前进跃进的世界中是合理的。然而，云计算改变了情况，因为一些新技术很大程度上减少了你需要管理的内容，同时增加了你提供的基础规模和功能。

例如，AWS的Amplify服务在移动端和后端开发的实时性方面进步很大。基于低代码、专注于模式的API开发方法绝对是优秀的；与云本地数据存储的紧密集成是更好的。并且因为AppSync后端是一个云服务，它会随着时间的推移不断改进，而你不必做任何事情。可能需要你花几周时间才能完全熟悉。但是，在这种情况下，投入一些时间学习的回报是持久的。

关键是，你的感觉可能会出卖你。你需要冷静地评估哪些工具和服务能为你提供最大的收益。

时间是最珍贵的资源；

全力优化

你每天都接触到的最昂贵的资源不是你的生产数据库集群、应用服务器群或日志框架。而是你的日程安排。

你和你的团队拥有有限的周期来构建和维护技术。不要浪费时间重复造轮子。

举个不幸的个人例子，我之前的工作中花费了大量时间从零开始构建一个全栈式的部署框架和管道工具。虽然最终这个部署管道确实为业务提供了一定的价值，但代价是数千小时的工程时间。

如果我和团队更多地依赖现有的云服务，我们可以在更短的时间内完成同样的功能，用来从事更有价值的项目，而不用总是解释给管理层我们在干什么。

鉴于云原生开发高度重视使用现成的服务，它使你在日程表上有更多宝贵的时间可用。

更早地开始在云上构建。不，比那还早一点。

我已经一直在鼓励“本地测试代码，云上测试服务”的理念。随着无服务器开发在技术栈中的位置越来越高，维护独立于云之外的本地开发环境的价值也越来越小。

如果必须这么做，可以在本地迭代代码；在远程栈（显然不是生产栈）部署的角色和资源上进行测试。你在开发生命周期中越早这么做，发现权限和配置问题的速度就越快，在生产环境中出现意外情况的可能性也就越小。

我认为对此有最好理解的供应商是Stackery。我非常喜欢他们的“cloudlocal”开发概念，尽管我觉得这个名字不太可能流行。他们的命令行工具是我知道的唯一一个目前支持在本地执行AWS Lambda函数，并使用与云部署版本相关联的角色的工具。（当你调用本地函数时，他们会将信任关系注入到该角色中。）我预测，其他主要的无服务器部署框架，如AWS SAM和Serverless Framework，也将很快为此提供更好的支持。这是未来的发展趋势。