服务
关于
CloudProse博客
聚光灯

云决策者的十诫

两个石碑引导您的朝圣之旅到云
福雷斯特Brazeal 迷航10 191210 171202
阿甘(Forrest Brazeal) | 2020年2月11日

在Trek10的过去几年中,我曾与数十家公司合作,从初创公司到财富100强,帮助企业和技术决策者建立了在云中蓬勃发展的团队和应用程序。

尽管这些公司有时认为他们的问题和疑问必须是独特的,但实际上,团队经常会一遍又一遍地遇到相同的挑战。

当我 结束我在Trek10的任期,我想给您留下十条有助于指导我的云决策的一般规则。

我将它们分为两个“片剂”:一组用于业务决策者(执行人员),一组用于技术决策者(技术组织中的工程师和经理)。

平板电脑1:面向业务决策者

一,别再假装云只是一个技术问题

敏捷或DevOps转换是 被广泛理解 涉及某种程度的自上而下的组织变革。它涉及新的责任,新的工作方式,团队之间的新沟通形式。您不会尝试购买“一箱DevOps”(尽管有些人会尝试将其出售给您!)并期望成功。

您的云采用情况也不例外。不要以为云只是提供相同的旧技术和工作方式的替代工具。一种 “随心所欲”的心态 最终将导致昂贵、,肿的云采用失败。

开发,运营,安全性甚至财务-在成功的云优先业务中都采用了新的配置。花时间去理解和接受需要改变的深度。

二。从第一天开始的火车

您不能提出自上而下的组织职责以采用云,走开并期望一切都会好起来。

就技术技能和团队职责而言,云计算是一个巨大的转变。也不了解云端的来龙去脉的人。合作伙伴可以提供帮助,但最终您需要制定计划以从内部建立专业知识。

建立一个 云卓越中心 对于大型企业来说是一个好的开始,但是我已经看到这些努力变成了另一个孤岛。您不能只是创建一个“云团队”;您必须树立更广泛的文化,这意味着需要在几个月和几年的时间内耐心地扩展整个组织的云能力。

是的,培训很昂贵。但是,云计算的全部重点是,您应该能够在相同数量的人员上建立更多的价值。因此,将您的部分招聘预算重新分配给您的团队培训:您会惊讶于他们使用云提供商提供的服务可以完成的工作。

设定正确的优先级,提供适当的激励措施,您的员工队伍将缓慢但必定会发生转变。

三,将云计算为价值中心

我们仍然看到一些企业之所以选择云,主要是出于节省成本的原因,尽管比过去几年有所减少,并且有充分的理由。您不会花更少的钱去云计算,而是去那里创造更多的价值。

这就是为什么我喜欢云的形象 “ IT的杀手级应用”:就像电子表格为早期PC所做的那样,仅云计算就可以证明您的IT足迹成本不菲。

如果您组建一个可以利用的组织,那么上市时间,创新速度,敏捷性都将随着云服务而增加。

一些公司之所以陷入困境,是因为这只是他们能够看到和理解的唯一与采用云相关的指标(尽管很痛苦)。成功的度量标准(如实现价值的时间)并非无法衡量,但它们需要认真努力来建立和评估。

优先进行实验,了解您的成功标准,您将看到云驱动器的价值远远超过其成本。

IV。从小处开始,但不要踢轮胎

在处于云雾笼罩的阶段,很容易陷入数月甚至数年的困境。在他的 最近re:Invent主题演讲,安迪·贾西(Andy Jassy)宣布了一个组织,尽管吹嘘他们采用云技术,但实际上只部署了一些小型实验。尽管该方法可以用作您的技术团队的履历表,但对企业没有任何价值。

刚开始时您不会立即将所有内容都存储在云中,但不要因此而阻止您开始。选择一口大小的工作负载,认真尝试在云中运行,找出不足之处,加以改进,重复并扩大学习范围。

认真对待云,然后将得出认真的结果。

五,信任您的合作伙伴

企业在云之门被冻结数月或数年的原因之一?他们认识到变化可能很复杂,并且他们不想弄错它。

因此,在您的云之旅中引入值得信赖的合作伙伴是很有意义的,这些合作伙伴是那些曾经走过道路并且知道陷阱以及捷径的人。

(顺便说一下,这是对公共云本身的一个很好的论点。您是否真的认为您可以比AWS更好地运行数据中心,或者比Microsoft更好地构建开发人员工具?关于锁定的担忧在历史上是合理的,并且有其地位,但最终,您必须与可以帮助您适当利用风险的提供商进行合作。)

找到您信任的云和咨询合作伙伴,然后给予他们一定的自由度,以帮助您实现持久而积极的变化。

平板电脑II:面向技术决策者

VI。不要基于熟悉偏见来选择技术

技术决策中有很多建议,基本上可以说:对于大多数问题,请使用永远存在的久经考验的解决方案。没有人因为编写其他Rails应用程序而被解雇。

在当今世界上不会发生重大的,具有颠覆性的飞跃的情况下,这是一个很好的建议。云改变了演算,因为某些新技术从根本上减少了您必须管理的事物的范围,同时增加了所提供内容的基础规模和功能。

AWS的 放大 例如,这项服务已迅速将目标移动到了实时移动和后端开发中。以低代码,以模式为中心的API开发方法很棒。与云原生数据存储的紧密集成更好。而且由于AppSync后端是一种云服务,所以它可以随着时间的推移而不断改进,而您无需执行任何操作。可能需要几个星期才能完全掌握最新信息。但是在这种情况下,花在学习上的时间会无限期地带来红利。

关键是你的感觉会背叛你。您需要无私地评估哪些工具和服务可以为您带来最大的收益。

七。你的时间是你最昂贵的资源。优化它

您每天接触的最昂贵的资源不是您的生产数据库集群,您的应用服务器场或日志记录堆栈。这是您的日历。

您和您的团队在构建和维护技术上的周期有限。不要浪费他们重新安装轮子。

为了提供一个不幸的个人示例,我在以前的工作中花了大量时间从头开始或多或少地构建了完整的堆栈部署框架和管道工具。部署管道最终确实为业务提供了一些价值,但要花费数千个工程小时。

如果我和我的团队更加依赖现有服务,那么我们本可以在更少的时间内交付相同的功能,并进行更高价值的项目,而不必不断地向领导层证明我们在做什么。

由于云原生开发在使用预建服务方面具有很高的优先级,因此可以将更多的宝贵时间重新投入您的日历中。

八。早先在云中构建。不,早于此。

我一直在努力鼓励 “本地测试代码和云中的服务” 一阵子。随着无服务器开发越来越多地爬到堆栈上,维护本地开发环境与云分离的价值越来越小。

如果需要,在本地迭代代码;针对部署到远程堆栈(显然不是您的生产堆栈)的角色和资源进行测试。您在开发生命周期中越早进行此操作,就越快地发现权限和配置问题,生产中的惊喜也就越少。

我最了解的供应商是Stackery。我喜欢他们的概念 “ cloudlocal” 发展,尽管我怀疑这个名字会流行。他们知道自己的CLI是唯一知道的工具,该工具当前支持在与该功能的云部署版本关联的角色下运行本地AWS Lambda函数。 (当您调用本地函数时,它们会向角色注入信任关系。)我预计您将很快看到其他大型无服务器部署框架AWS SAM和无服务器框架对此提供更好的支持。这是事情发展的方向。

九。停止解决假问题

您会认为我们的工作中会存在足够的实际问题,而不会伪造那些问题。不幸的是,软件工程师擅长提出解决问题的解决方案。

例如,您的应用程序真的需要跨区域吗?如果整个AWS美国东部地区出现故障,您的应用是否需要维护可用性?您将花费多少时间来维护多个区域的事务一致性,您将花费多少钱来复制数据,而仅在蓝色月亮中一次优雅地下降几分钟?

可移植性是一个巨大的假问题。 正如有些人所说,如果您使用的是Kubernetes,则必须非常聪明:这是必要条件,而不是恭维。协调服务网格,服务代理,入口路由以及所有其他任务都是非常复杂的任务。

我什至看到人们在构建具有复杂抽象层的无服务器应用程序,因此,如果他们需要选择其他云提供商,他们可以交换技术。

一个真正明智的技术决策者知道您可以成为专家的范围很小。利用云服务开箱即用地增强生产的架构,并在顶部构建您的独特功能。

如果必须使用Kubernetes,请查看托管服务,例如 Fargate上的EKS 要么 SpotInst海洋 这样就可以提取大量的毛料(并可以在超低价位的现货实例上协调您的容器)。

更不用说,通过与提供商进行更紧密的集成,您可以获得很多优势。直到云提供商表明他们将锁定掠夺性价格(到目前为止还没有发生)之前,您的时间可能会更有价值地用于功能交付上。

我做出这些决定的原则很简单: 不要代码明智,愚蠢的.

十,通过展示价值创造动力

作为技术决策者,是亲自接触代码的人,您非常适合确定哪种技术对您的问题领域影响最大。

如果您不能接受似乎有明显好处的设计选择,请查看您是否可以找到一些时间在云中进行原型设计-它通常又快又便宜。

作为技术决策者,您可以对业务提出有力的论据:在这里,我已经构建了您需要的东西。它运行速度快,易于维护。

无论您是企业还是技术决策者,云迁移的成功最终都取决于您是否愿意对不舒适感到自在:突破您可以构建的范围,拒绝熟悉偏差的舒适度以及信任为前进道路建模的供应商和合作伙伴。

尽管我在Trek10的工作即将结束,但我仍然坚信在这里找到的愿景和专业知识,建议您在应用这些准则时向他们寻求帮助。

作者
福雷斯特Brazeal 迷航10 191210 171202
阿甘(Forrest Brazeal)