首页>新闻>新闻详情>

避免不完全的云原生

2021-01-05 13:09:35
作者 | Kyle Brown译者 | 平川策划 | Tina本文最初发布于 The Startup 博客,经原作者授权由 InfoQ 中文站翻译并分享。

在我的工作中,最令人沮丧的一部分是对失败的云采用项目进行事后分析。这种情况经常发生;我们被叫到客户那里,帮助他们弄清楚,为什么他们采取了上云的步骤却没有达到预期。在这种情况下,我能做的最重要的事情就是保持冷静,帮助客户根据事实而不是臆测得出结论。我经常会看到,导致这些失败的一个最常见的问题是,团队并没有实现完全的云原生转型,他们只是走了这个过程中的一段路,并且在到达那里之前就停下了。

可以这样说,云原生并不像一个架构的描述(虽然肯定有云原生和非云原生架构),因为作为一个整体,它既描述了一组架构决策,也描述了支持这种架构所需的流程和组织决策。技术决策是必要的,但对于团队来说,要成功地构建、特别是管理和维护云原生系统,仅有技术决策是不够的。为了取得成功,你需要协调以下三类决策。

技术——这些(相对而言)是比较容易做出的决策,包括采用微服务方法、编写组件,以便实现水平扩展,充分利用开源技术,从而从社区的成果获益。但是,每一项决策都伴随着相应的流程和组织决策,它们是技术决策的基础。

团队组织——微服务意味着你在小型自治团队中构建服务。这是康威法则的简单应用——如果你希望系统是由小的、解耦的组件组成,那么你就要保证团队也很小,而且不与其他团队紧密耦合——与团队之间的松散关系相呼应的架构方法,只允许正式进程间通过 API 通信。

流程——微服务意味着你正在将 DevOps 原则应用到开发流程中,比如持续集成和持续交付。但这本身需要你采用其他专门的技术流程,如自动化测试,并把你导向基于主干的开发。事实上,如果你首先采用像测试驱动开发和结对编程这样的开发实践,那么采用那些实践将变得容易很多。

当一家公司试图越过其中的一项时,问题就来了——如果你敲掉凳子的一条腿,整个凳子就会倒下来。例如,当公司告诉我们,他们正在构建多个“微服务”,同时他们也在运用 SaFE 方法来管理结果系统的的多个发布序列的异常复杂的交互时,如果我们看到一个常见问题,就表明有一个更大的问题。你无法两者兼得;这会弄巧成拙。

如果你的设计需要多个复杂的发布序列,那么你可能违背了微服务的其中一项关键原则,即每个微服务的 DevOps 管道应该保持彼此独立(或者至少尽可能地独立)。此外,这种协调还表明,你的系统耦合性超出了正常水平,所以你才需要这种程度的协调。更重要的是,需要这种协调意味着你的团队并不是真正自治的——你可能只是把一个大团队任意分成小块,而没有给予他们真正的自治。

对于这方面的考虑,我们通常还可以追溯到 IT 和业务之间的互动。这从下图中可以看到:

图 1:云原生方法需要技术、组织和流程的变革

采用云原生开发方法(如微服务)的唯一原因是,团队能够以增量的方式交付可度量的业务价值单元。但是,如果你的业务不能这样做——不能从小型业务价值单元(可以在一段时间内独立交付)的角度来考虑,那么事实上,微服务架构以及其余大部分云原生方法,都不会有太多的价值。

因此,每当我看到不完全的转型时,我的第一个想法就是与业务和 IT 负责人一起坐下来,问问他们对采用云有什么期望。通常你会发现,人们的期望差别很大。例如,在“IT 主导”的转型工作中,你有时会看到业务被排除在转型工作之外——事实上,他们不仅应该有一席之地,而且应该主导这项工作。其中一个征兆出现在我问敏捷团队产品负责人向谁汇报时——如果是 IT 部门的人,那么我们可能会有问题,因为业务并没有像他们应该做的那样深入地参与进来。但这并不是转型不完全的唯一征兆。下面是其他一些征兆:

  1. 如果你仍然有一个架构委员会审批设计,或者一个变更控制委员会审批所有发布,那么你并没有真正授予团队完全的自主权。你应该制定指导方针,然后确保团队遵照指导方针开展工作。

  2. 如果不能快速构想和测试你的业务假设(通过 A/B 测试),那么你就不能获得云计算承诺的潜在业务成果。这一切都取决于业务和 IT 之间紧密的互动循环。

还有许多其他的例子可以说明,团队可能会因为不完全的转型而失败;太多了,我就不列举了。我要向托尔斯泰道歉,“所有成功的转型是相似的;所有失败的转型各有各的失败。“你只需要坚持基本原则,保证做好这三个方面的工作,并与业务保持一致,但要做到这一点并不容易。为了实现完全的转型,你必须在每个阶段不断地回顾这些基本原则。

那么,你能采取哪些积极的行动来确保自己彻底地完成转型,而不是中途停下来呢?回到这些基本原则到底意味着什么?

  1. 在组织方面,第一步也是最大的一步是建立小型团队(例如双披萨团队),并授予他们自主权,让他们自己做出技术决策,并确保他们有一个专门的产品负责人,他可以自己做出业务决策。这些决策应该在一定范围内做出,但这是最大的一步。许多团队(包括我们的团队)发现,像 Spotify 模式这样的框架也能帮助更大的团队(如多组双披萨团队)通过协作组织(如分会、协会和部落)定义这些限制,并在小型团队之间进行协调。

  2. 在技术方面,确保团队在做架构选择时能减少跨服务耦合、增加组件内聚性,并确保能够快速轻松地添加特性。这涉及到采用容器或无服务器,并且要保证,在使用像微服务这样的技术时不会通过共享数据库引入“隐式”耦合,并利用所有可以让我们从中获益的架构选项服务,例如,使用同步和异步调用路径。

  3. 在流程方面,最重要的步骤是采用敏捷开发方法的技术实践,如 Forssgren 等人提出的极限编程,这被认为是成功的秘诀。这不仅包括每个服务的 CI/CD,还包括测试驱动开发、结对编程,最重要的是,让团队推动他们自己的敏捷转型。从上至下的敏捷原则和方法训练很好,但是,如果团队是流程所有者,他们的表现会最好。

原文链接:Avoiding Incomplete Cloud Native Adoptionhttps://kylegenebrown.medium.com/avoiding-incomplete-cloud-native-adoption-17e62b2ae13今日好文推荐中国三大电信运营商被迫从美股退市,商务部:将采取必要措施2020年,不可错过的技术圈十大“翻车”事件我真的逃不掉拼多多真香定律

InfoQ 读者交流群上线啦!各位小伙伴可以扫描下方二维码,添加 InfoQ 小助手,回复关键字“进群”申请入群。回复“资料”,获取资料包传送门,注册 InfoQ 网站后,可以任意领取一门极客时间课程,免费滴!大家可以和 InfoQ 读者一起畅所欲言,和编辑们零距离接触,超值的技术礼包等你领取,还有超值活动等你参加,快来加入我们吧!




  • 点个在看少个 bug 👇

热门交易所

热门币种

Bitcoin
BTC-2.85%
31,459.6
Ethereum
ETH-4.77%
1,287.79

比特币蜘蛛BTCSpider.com是比特币新闻及数字货币信息的聚合站,每天追踪采集全球主流比特币等数字货币财经媒体、项目官网、交易平台的新鲜信息,实时更新海量资讯内容。