GMTC全球大前端技术大会(北京站)门票9折特惠截至本周五,点击立减¥480 了解详情
写点什么

避免不完全的云原生

2020 年 12 月 29 日

避免不完全的云原生

本文最初发布于 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 Adoption


2020 年 12 月 29 日 18:211560

评论

发布
暂无评论
发现更多内容

学习笔记丨Linux中数据提取相关命令

Liuchengz.

Linux ubuntu #Ubuntu

架构师养成第三课

万有引力

iOS面试高薪,进阶 你会这些呢嘛?

ios swift 面试

美团十年架构师精心分享:手写分布式消息中间件RocketMQ笔记

小Q

学习 面试 微服务 MQ 中间件

《前端算法系列》如何让前端代码速度提高60倍

徐小夕

Java 算法 前端 前端进阶

100+大厂应届offer,从7个维度全面分析

程序员小灰

编程 面试 面经 腾讯大厂

架构师训练营第 1 期 - 第十二周总结

Todd-Lee

极客大学架构师训练营

2021数字化投资规划,你做好了吗?

ThoughtWorks洞见

架构 业务架构

作业-第8周

arcyao

【小菜学网络】物理层概述

fasionchan

网络编程 计算机网络 网络协议 TCP/IP 物理层

2020年我凭借这份pdf成功拿到了阿里,腾讯,京东等六家大厂offer

Crud的程序员

Java 阿里巴巴 程序员 java面试 offer

Gradle使用问题梳理

maijun

Gradle

架构师训练营第 1 期 - 第十二周作业

Todd-Lee

极客大学架构师训练营

找到相同链表的点

落朽

Week 12

黄立

TRONex智能合约APP系统软件开发

开發I852946OIIO

系统开发

基于 getty 的分布式事务框架seata-golang 通信模型详解

apache/dubbo-go

dubbo dubbo-go dubbogo seata

Tronex智能合约APP系统开发|Tronex智能合约软件开发

开發I852946OIIO

系统开发

第三周学习心得

cc

shell脚本的使用该熟练起来了,你说呢?(篇三)

良知犹存

Shell

生产环境全链路压测建设历程之六 淘宝网2012年双十一的痛

数列科技杨德华

TCC Demo 代码实现

Java 分布式事务 Demo TCC

实践出真知!华为Android面试真题解析,附超全教程文档

欢喜学安卓

android 程序员 面试 移动开发

腾讯T3大牛手把手教你!从外包月薪5K到阿里月薪15K,分享一点面试小经验

欢喜学安卓

android 程序员 面试 移动开发

第三周设计作业

cc

复盘不止复盘,更是个人认知升级加速器?

Alan

复盘 思维 技术人应知的创新思维模型 28天写作

网易游戏部门Java架构师必看的“完美版”Netty源码笔记

Java架构追梦

Java 学习 源码 架构 Netty

图解MyBatis

田维常

《架构即未来:现代企业可扩展的Web架构流程和组织》.pdf

田维常

架构

天下武功,唯“拆”不破之MECE原则一| 技术人应知的创新思维模型 (5)

Alan

职场成长 技术人应知的创新思维模型 组合创新 结构化思维 28天写作

记录一次腾讯c/c++ linux后台开发岗面试经历(面试题含答案)

linux大本营

c++ Linux 腾讯 后台开发 架构师

避免不完全的云原生-InfoQ