写点什么

避免不完全的云原生

  • 2020 年 12 月 29 日
  • 本文字数:2310 字

    阅读完需:约 8 分钟

避免不完全的云原生

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

评论

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

DevOps 技术栈

柴锋

Linux DevOps 运维 敏捷 Shell

troubleshoot之:用control+break解决线程死锁问题

程序那些事

Java JVM 死锁

数据库的乐观锁和悲观锁并非真实的锁

架构师修行之路

数据库 架构 乐观锁 悲观锁 分布式锁

LeetCode题解:21. 合并两个有序链表,迭代,JavaScript,详细注释

Lee Chen

大前端 LeetCode

ARTS-week-2

saddamwilson

ARTS 打卡计划

图文讲解 AQS ,一起看看 AQS 的源码……(图文较长)

程序员小航

AQS jdk源码 源码阅读 java 并发

服务器与普通电脑的区别?

德胜网络-阳

如何设计实现一个证书加密签名工具包

三尾鱼

ARTS Week11

时之虫

ARTS 打卡计划

第十章作业

武鹏

JDK1.8新特性(七):默认方法,真香,开动!接口?我要升级!!

xcbeyond

接口 新特性 JDK1.8 默认方法 JDK1.8新特性

Go: 互斥锁和饥饿

陈思敏捷

mutex Go 语言

LeetCode题解:21. 合并两个有序链表,利用数组排序,JavaScript,详细注释

Lee Chen

大前端 LeetCode

List 和 Map 的排序

一盐难进

Java

Kafka处理请求的全流程解析

yes

kafka 面试 后端 消息队列 源码解析

区块链+收藏品,全球三种典型应用路径的差异化

CECBC

区块链 应用价值

Requests模块基本操作

骆俊

ARTS Week8

丽子

机器学习算法之——K最近邻(k-Nearest Neighbor,KNN)分类算法原理讲解

迈微AI研发社

学习 算法 KNN K聚类

基于 grpc,protobuf搭建 server/client模型通信

是老郭啊

多省市出台关于区块链人才引进的计划

CECBC

新基建 区块链技术

区块链跃升各国创新战略

CECBC

新基建 国家战略 区块链标准

机器学习算法之——卷积神经网络(CNN)原理讲解

迈微AI研发社

学习 算法 卷积神经网络 CNN

如何理解Java8 的函数式编程

Rayjun

Java 函数式编程

关于 Bash 的 10 个常见误解

柴锋

bash Linux DevOps Shell

视读——沟通的艺术,看入人里,看出人外(第二章)

废材姑娘

读书笔记 视觉笔记

# spring boot自定义线程池进行异步调用

一盐难进

Java

HTTPS证书过期导致的故障

焦振清

运维 https SRE 服务故障 证书过期

2.2.1 类反射 -《SSM深入解析与项目实战》

谙忆

知路,然后智行远;懂行,所以万业兴

脑极体

如何对 ElasticSearch 集群进行压力测试

Bestony

elasticsearch ELK Elastic Stack

ShadowRealm 与微前端沙箱

ShadowRealm 与微前端沙箱

避免不完全的云原生-InfoQ