所谓转型,是指事物的结构形态、运转模型和人们观念的根本性转变过程。
PS:源于所见所闻所习所思总结而成,所代表的场景比较有限,可能不会适用于多数场景。
上周末,我在思考『大型组织如何进行 DevOps 的成熟度模型设计』时,便开始在思索,为什么 DevOps 是一种转型?敏捷也可以是一种转型?它们有着足够大的复杂度,需要改变一系列的组织文化,还有技术实践上的改变。所以,我尝试着继续去探索转型的领域。
如果一个领域,它需要大量的布道,需要进行大量的学习,以及架构(技术上、组织上或者是业务上)的变更,以转变人们的观念,那么它就可以称得上是一种转型。
所以,我重新思考了一下敏捷转型、DevOps 转型中的一些核心变革因素,诸如于:
于是乎,我尝试性地将它融入到云原生转型的过程中。说是尝试性,其实呢,我是结合了一些公司的诉求和上云过程提炼而成。诸如于中大型组织在内部推广自己的微服务框架,培养自己的内部技术教练等,提炼而成的技术能力中心。
云原生源自于 CloudNative,它和微服务类似,微服务代表的是一种架构风格,云原生则是相比更为抽象的一种模式,即理念。因此,基于云原生理论的应用,它在设计架构时就是为云而设计的。
在今天,走向云原生的第一步,采用或者构建云原生平台。
过去的几年里,走上云原生的主流模式就是:构建容器化平台,诸如于采用 Kubernetes 作为平台的基石,搭建企业内部的 PaaS 平台。所以,这点陈芝麻烂谷子的过程,也就无关紧要了。
提及这个的原因是,有一些组织的云平台( PaaS )走歪了。在 Kubernetes 火爆之前,市面上已经有一系列的 DevOps 工具,做了类似的事情:基础设施即代码。围绕着『基础设施即代码』这一模式,才是构建云平台的核心 。人们从实践中提取模式,模式中提炼了工具,工具集中打造了平台。但是,用了平台的人总会忘了原来的模式。这就也是为什么有些云平台( PaaS )需要大量的手工配置。
围绕着云平台,就需要把传统的遗留基础设施去掉,迁移到云平台( PaaS )上。
这一点倒也没啥说的。
下一步,就是重新设计应用的架构。
微服务架构是云原生下的一种非常好的架构模式,但是这并意味着微服务是唯一的答案。过多错误的微服务划分方式,导致了大量的系统失去了应具有的弹性架构。所以,不要以微服务作为你迁移路径的目标。我们要设计的方向,应该是弹性架构。
围绕如何实现弹性架构而设计,随后相关技术,如采用容器、服务网格、微服务、不可变基础设施和声明式 API,才才是解决问题的正解之路。
故事到这里就结束了?
单纯的迁移到云平台,应用进行微服务改造。对于多数的团队来说,它没有带来太大的改变,团队依旧继续原先的思路设计和构建系统。如果只是单纯的上云,团队可能也没有意识去构建所需要的核心能力。
再考虑一下这个问题,你们为什么选择了云原生?从收益上来看,从组织层面来看,它可以是:
而细到团队来看,它可以分为两部分:
而故事并没有那么简单,平台团队如果只是定位于开发平台,那么他们会遇到一系列的现实冲击,诸如于我在《开发者即服务:开发者的被按需即用》所提及的。
团队所面临的问题与开源项目的困境是极为类似的,诸如于要提供更好的服务、更舒适的体验,还想避免疲于支援各种团队。
平台团队需要转变一下解决问题的思路,诸如于采用内部开源、开发者运营等。
在一个组织内,不同团队的水平参差不齐,既可能受限于能力水平,还可能受限于业务场景的简易程度。也因此,一旦面临着这些架构上的调整时,会变得异常混乱。
在云原生的场景下,它相当于立了一个技术基线,所有的团队都应该到达这条基线。而从现实情况来看,多数的业务团队并不具备这样的能力和精力。与能力相比,精力和时间是一个主要问题。
因此,从组织的层面来看,需要寻找方式来支撑规模化的技术能力提升,诸如于人们在敏捷转型时,采用的敏捷教练,又或者是在 DevOps 转型时,引入的 DevOps 教练/工程师。
从模型上来看,云原生的转型,也意味着在改变组织的协作方式。从维度上来说,它更多的是一种开发对开发的协作方式。而不会像 DevOps 转型一样,有着更广泛的组织内影响。
DevOps 运动初期的目的就是打破开发与运维之间的壁垒,鼓励开发与运维之间的协作。而随着国内各类标准和成熟度的出现,我们对它的定义已经是:BizDevOps,即业务 + 开发 + 运维的协作。
成为的 DevOps 运动,可以让组织变得更加流畅 —— 至少在协作上已经是规范化、工具化的。
也因此云原生的成功,也是要建立在 DevOps 的基础上。开发 + 运维一起构建了 PaaS 平台,并用于支持业务 + 开发的活动。
而一旦出现了 PaaS 平台,那么这个平台就是平台开发(PaaS Dev)与业务开发(Biz Dev)的协作。
要改善它们的协作方式,就需要关注于设计开发者体验,这便是另外一种协作方式的改变。基于开发者体验度量优化协作,便是要做的另外一项改变。
对于多数组织来说,我觉得它们犯了一个错误就是:没有建立内部的技术社区。以通过构建技术社区,可以沉淀组织的技术资产。其中一个原因或许是:部门之间的竞争。而在云原生时代,这个问题就变得非常紧迫,如何去共享云原生相关的知识?
Wiki 是开发团队用来沉淀知识的方式。对于一个组织来说,相同的知识可能分散于不同的团队。
传统模式下,这并不是问题。而在云原生时代,这个问题更为突出。所以,对于 PaaS 平台团队来说,它们应该主动发起对于知识库的建立。除了,帮助其它人解决问题,还可以减少自己的响应时间。
内部技术社区是 Tw 用来构建技术能力的方式之一。在特定领域的商机来临时,它可能有足够的能力来支撑。对于多数的组织来说,这也是一种颇为有效的方式。
在这之上,对于组织来说,它们还要考虑的因素是:
虽然如此,但是我一直在思考部门墙是否会限制内部技术社区?
在云原生的背景下,便是让相关的 PaaS 平台和开发人员可以就模式、蓝图、技术和代码示例开展协作。与上述的两个方式相对,成为一个围绕提升技术能力的团队,是一个更有挑战的事情。
有意思的是,这种模式已经在大量技术型氛围的公司采用了,它们招募了一系列的内部技术教练,用于帮助各个团队进行技能能力提升。
成熟度模型,又是一个更有意思的标准化模式。它用于指挥一个组织如何高效地工作,换句话来说,就是一个组织如何成为社会这个巨大车轮中的一部分。
成熟度依旧是我们用于指导进行规模化方式的。就这一点而言,我们已经在上一篇文章《中大型组织 DevOps 成熟度模型》中,做了一系列的设计介绍。对于大型组织来说,依旧是根据业内的通用模型,进一步完善自己的模式。
由于篇幅很限,文中的很多内容就不展开讨论了~。
PS:貌似一不小心写崩了,不过大意就看标题~。
参考资料:
围观我的Github Idea墙, 也许,你会遇到心仪的项目