大学毕业后我的第一份技术工作是在南方一家钢铁公司做代码编写顾问。当时的技术栈还很简单,我们拥有三代大型机:Burroughs、DEC PDP-11/70和全新的IBM 3090,使用COBOL、Fortran和Assembler编写。有三种存储数据的选项:磁带、DB2和IMS数据库。运营模型也很简单,一部分人管理大型机、软件和数据库,其他人编写代码。
当应用程序崩溃时,编码的人会对程序进行修复。早在面向服务的架构、微服务甚至互联网出现之前,每个程序只由一名开发人员编写是很常见的现象。那时,经营IT公司比现在容易得多,因为要管理的技术比较少,基础设施也进行了集中管理,而且几乎所有人都在用相同的语言编写代码。
在大型机时代,一种简单的运营模型如图2-1所示。大型机团队管理大型机的整个堆栈,包括基础设施、编程语言(例如COBOL、Fortran和RPG)以及数据库技术(IMS、DB2等)。
图2-1:20世纪80年代大型机时代的简化版运营模型
他们还提供磁带服务,管理作业的执行,并且是环境所有变更的审核和批准关卡。
之后Internet、Windows、Linux和三层Web体系架构开始流行。以前的运营模型不能继续支持IT的新需求。除大型机外,现在整个公司中每个人都有个人计算机(PC),而且数据中心塞满了微型计算机、自动磁带备份设备、存储设备和复杂的网络基础设施。这就导致了更复杂的运营模型,如图2-2所示。
图2-2:大约在20世纪90年代,客户端服务器时代的一个更复杂的运营模型
在大型机时代,大型机组管理整个技术栈。在客户端服务器时代,技术栈被分解为多个组件栈,人们可以针对应用程序的需求来灵活地采用这些组件。你必须根据可用的基础设施来调整应用程序。
当客户端-服务器架构出现时,你可以根据应用程序的需求调整基础设施。架构师现在不仅可以申请特定的基础设施来满足他们的需求,还对数据库技术有更多的选择。这促使许多企业IT部门创建了由数据库专家组成的筒仓,用来向业务部门交付数据库技术。但这并不仅限于数据库,在操作系统、编程语言、存储和网络技术等方面也有了更多的选择。运营模型已经从拥有所有计算、网络、存储和数据库技术的大型机团队转变为独立交付所有这些服务的领域专家。
现在,架构师有更多选择来优化硬件、中间件和数据库技术以满足应用程序的需求,但是管理底层技术的复杂度却大大增加了。每个技术领域都涌现出许多新流程,因此,走完核心IT流程变得充满挑战。在这个过程中,领域专家沉迷于交付自己的技术堆栈,以至于IT服务开始变得不那么了解所提供服务的应用程序。
在接下来的几十年里,随着技术的进步,我们的运营模型发生了变化(见图2-3),但没有那么剧烈。实际上,很少有公司重新设计运营模型,反而只是在其现有模型中添加更多服务。驾驭IT变得极具挑战性,以至于许多业务部门开始寻求外部供应商来满足它们的需求。
图2-3:云计算前的运营模型(大约在2000年)
随着我们向云端迁移,这些遗留的运营模型不足以应对将来构建和部署软件。你不能将云插入现有的运营模型中就期望获得理想的结果。作为一个行业,我们需要重新考虑为客户提供服务的方法,需要一个针对云进行过优化的新运营模型。
但是,在构建它之前,让我们先回过头来全面了解云计算和传统本地物理基础设施计算之间的根本差异。
我将介绍一些对云转型具有特殊意义的技术变化:基础设施即代码(IaC)、CI/CD,不可变基础设施、微服务和容器。