Blog

Blog

PHODAL

云原生转型:规模化演进与文化思考

所谓转型,是指事物的结构形态、运转模型和人们观念的根本性转变过程。

PS:源于所见所闻所习所思总结而成,所代表的场景比较有限,可能不会适用于多数场景。

上周末,我在思考『大型组织如何进行 DevOps 的成熟度模型设计』时,便开始在思索,为什么 DevOps 是一种转型?敏捷也可以是一种转型?它们有着足够大的复杂度,需要改变一系列的组织文化,还有技术实践上的改变。所以,我尝试着继续去探索转型的领域。

如果一个领域,它需要大量的布道,需要进行大量的学习,以及架构(技术上、组织上或者是业务上)的变更,以转变人们的观念,那么它就可以称得上是一种转型。

所以,我重新思考了一下敏捷转型、DevOps 转型中的一些核心变革因素,诸如于:

  1. 观念的转换,引入新文化。
  2. 调整架构,改善协作。这里的架构包含了技术、组织、业务、团队。
  3. 构建能力中心。
  4. 成熟度指导持续提升。

于是乎,我尝试性地将它融入到云原生转型的过程中。说是尝试性,其实呢,我是结合了一些公司的诉求和上云过程提炼而成。诸如于中大型组织在内部推广自己的微服务框架,培养自己的内部技术教练等,提炼而成的技术能力中心。

0. 平台作为起点,逐步迁移上云

云原生源自于 CloudNative,它和微服务类似,微服务代表的是一种架构风格,云原生则是相比更为抽象的一种模式,即理念。因此,基于云原生理论的应用,它在设计架构时就是为云而设计的。

在今天,走向云原生的第一步,采用或者构建云原生平台。

0.1 模式工具化:云平台

过去的几年里,走上云原生的主流模式就是:构建容器化平台,诸如于采用 Kubernetes 作为平台的基石,搭建企业内部的 PaaS 平台。所以,这点陈芝麻烂谷子的过程,也就无关紧要了。

提及这个的原因是,有一些组织的云平台( PaaS )走歪了。在 Kubernetes 火爆之前,市面上已经有一系列的 DevOps 工具,做了类似的事情:基础设施即代码。围绕着『基础设施即代码』这一模式,才是构建云平台的核心 。人们从实践中提取模式,模式中提炼了工具,工具集中打造了平台。但是,用了平台的人总会忘了原来的模式。这就也是为什么有些云平台( PaaS )需要大量的手工配置。

0.2 遗留基础设施现代化

围绕着云平台,就需要把传统的遗留基础设施去掉,迁移到云平台( PaaS )上。

这一点倒也没啥说的。

下一步,就是重新设计应用的架构。

0.3 设计弹性架构 —— 你并一定不需要微服务

微服务架构是云原生下的一种非常好的架构模式,但是这并意味着微服务是唯一的答案。过多错误的微服务划分方式,导致了大量的系统失去了应具有的弹性架构。所以,不要以微服务作为你迁移路径的目标。我们要设计的方向,应该是弹性架构。

围绕如何实现弹性架构而设计,随后相关技术,如采用容器、服务网格、微服务、不可变基础设施和声明式 API,才才是解决问题的正解之路。

故事到这里就结束了?

1. 转换观念,引入新文化

单纯的迁移到云平台,应用进行微服务改造。对于多数的团队来说,它没有带来太大的改变,团队依旧继续原先的思路设计和构建系统。如果只是单纯的上云,团队可能也没有意识去构建所需要的核心能力。

云原生改变了什么?

再考虑一下这个问题,你们为什么选择了云原生?从收益上来看,从组织层面来看,它可以是:

  • 更好的客户体验
  • 提高了收益并降低运维成本
  • 新产品和服务的推行等待时间显着降低

而细到团队来看,它可以分为两部分:

  • 从平台侧,即从基础设施的层面来看,它是关于基础设施的抽象。它还关乎于基础设施的不可变性及可抛弃性。
  • 从开发侧,即从使用平台的层面来看,它是关于应用如何弹性

开发者即服务

而故事并没有那么简单,平台团队如果只是定位于开发平台,那么他们会遇到一系列的现实冲击,诸如于我在《开发者即服务:开发者的被按需即用》所提及的。

团队所面临的问题与开源项目的困境是极为类似的,诸如于要提供更好的服务、更舒适的体验,还想避免疲于支援各种团队。

平台团队需要转变一下解决问题的思路,诸如于采用内部开源、开发者运营等。

规模化的弹性架构设计

在一个组织内,不同团队的水平参差不齐,既可能受限于能力水平,还可能受限于业务场景的简易程度。也因此,一旦面临着这些架构上的调整时,会变得异常混乱。

在云原生的场景下,它相当于立了一个技术基线,所有的团队都应该到达这条基线。而从现实情况来看,多数的业务团队并不具备这样的能力和精力。与能力相比,精力和时间是一个主要问题。

因此,从组织的层面来看,需要寻找方式来支撑规模化的技术能力提升,诸如于人们在敏捷转型时,采用的敏捷教练,又或者是在 DevOps 转型时,引入的 DevOps 教练/工程师。

2. 改善组织协作

从模型上来看,云原生的转型,也意味着在改变组织的协作方式。从维度上来说,它更多的是一种开发对开发的协作方式。而不会像 DevOps 转型一样,有着更广泛的组织内影响。

DevOps >> Dev + Ops

DevOps 运动初期的目的就是打破开发与运维之间的壁垒,鼓励开发与运维之间的协作。而随着国内各类标准和成熟度的出现,我们对它的定义已经是:BizDevOps,即业务 + 开发 + 运维的协作。

成为的 DevOps 运动,可以让组织变得更加流畅 —— 至少在协作上已经是规范化、工具化的。

也因此云原生的成功,也是要建立在 DevOps 的基础上。开发 + 运维一起构建了 PaaS 平台,并用于支持业务 + 开发的活动。

内部开发者体验:PaaS Dev + Biz Dev

而一旦出现了 PaaS 平台,那么这个平台就是平台开发(PaaS Dev)与业务开发(Biz Dev)的协作。

要改善它们的协作方式,就需要关注于设计开发者体验,这便是另外一种协作方式的改变。基于开发者体验度量优化协作,便是要做的另外一项改变。

3. 构建技术能力中心

对于多数组织来说,我觉得它们犯了一个错误就是:没有建立内部的技术社区。以通过构建技术社区,可以沉淀组织的技术资产。其中一个原因或许是:部门之间的竞争。而在云原生时代,这个问题就变得非常紧迫,如何去共享云原生相关的知识?

沉淀知识体系

Wiki 是开发团队用来沉淀知识的方式。对于一个组织来说,相同的知识可能分散于不同的团队。

传统模式下,这并不是问题。而在云原生时代,这个问题更为突出。所以,对于 PaaS 平台团队来说,它们应该主动发起对于知识库的建立。除了,帮助其它人解决问题,还可以减少自己的响应时间。

内部技术社区

内部技术社区是 Tw 用来构建技术能力的方式之一。在特定领域的商机来临时,它可能有足够的能力来支撑。对于多数的组织来说,这也是一种颇为有效的方式。

在这之上,对于组织来说,它们还要考虑的因素是:

  • 社区支撑和运营体系
  • KPI 奖励机制

虽然如此,但是我一直在思考部门墙是否会限制内部技术社区?

技术能力中心

在云原生的背景下,便是让相关的 PaaS 平台和开发人员可以就模式、蓝图、技术和代码示例开展协作。与上述的两个方式相对,成为一个围绕提升技术能力的团队,是一个更有挑战的事情。

有意思的是,这种模式已经在大量技术型氛围的公司采用了,它们招募了一系列的内部技术教练,用于帮助各个团队进行技能能力提升。

4. 成熟度指导持续改进

成熟度模型,又是一个更有意思的标准化模式。它用于指挥一个组织如何高效地工作,换句话来说,就是一个组织如何成为社会这个巨大车轮中的一部分。

成熟度依旧是我们用于指导进行规模化方式的。就这一点而言,我们已经在上一篇文章《中大型组织 DevOps 成熟度模型》中,做了一系列的设计介绍。对于大型组织来说,依旧是根据业内的通用模型,进一步完善自己的模式。

其它

由于篇幅很限,文中的很多内容就不展开讨论了~。

PS:貌似一不小心写崩了,不过大意就看标题~。

参考资料:


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签

最近的一些事

  • 最近我和我的同事们,一起在创建一个新的编程语言:Charj 。它是一个使用 Rust 编写的描述式、中间编程语言。GitHub: https://github.com/datum-lang/datum

    Nov. 14, 2020, 9:27 p.m. | China