更好地了解toB领域,须得从层出不穷的“新词儿”入手,IDC、Gartner等调研机构也煞费苦心地成为“造词运动”的直接推动者。这么多新术语、表达方式和首字母缩写,为我们的理解增加了诸多挑战。今年年初,Gartner发布2023年十大战略技术趋势,“平台工程”赫然在列。同时,Gartner还预测到2026年,80%的软件工程组织将建立平台团队,其中75%将包含开发者自助服务门户。
在过去20年间,软件工程领域一直存在一个显著的趋势,组织在产品既要保证客户预期质量,又要快速推向市场的情况下,越来越依赖于自动化,开发者角色之间的传统界限越来越小。平台工程也延续了这一趋势,并成为下一代软件开发平台。由于平台工程是新的称号,人们对它有着许多的问题:它是什么,为什么需要它,又能带来哪些变化。今天,小编也带你走进平台工程的世界。
开发环境愈发复杂,谁来简化?
时至今日,现代化应用开发经历了哪些变化?肉眼可见的便是,现代化应用开发除了云原生技术外,还会使用到IaaS云服务、内部自建服务等异构基础设施,以及存在多云、混合云的部署需求。对于采用分散或临时的云计算方法来说,管理这些问题变得十分困难,复杂的技术已经远远超出普通Dev能够理解的范畴,更不可能将底层的复杂性直接暴露给普通Dev。
对于许多组织而言,使用平台工程方法来建立一个可以扩展的共享功能,已经成为一种必要。事实上,平台工程并没有明确的定义,简单理解,平台工程是一种DevOps方法,组织在该方法中开发一个共享平台,通过提供具有自动化基础架构操作的自助服务功能来改善整个组织的开发人员体验和生产力。平台工程师提供的集成产品通常被称为内部开发人员平台(IDP),涵盖了应用程序整个生命周期的运营需求。
举个例子,我们可以将某餐厅看作企业,餐厅里的顾客是开发者,饭菜可以看成API、工具、服务、知识等。这些顾客(开发者)对于饭菜种类(服务)的要求不尽相同,点的菜品也是五花八门。这样直接造成在短时间内满足不了需求,降低了开发效率,又使得厨师忙碌,可能出现菜品重复做的情况。
如何才能最大限度地满足这些顾客的需求?最为直接的方式就是将餐厅打造为自助餐,顾客可以根据自身的需要挑选适合自己的菜品进行搭配,即来即取即吃,可以在短时间满足大家的需求,提升开发效率,又能最大限度规避菜品重复的情况。而这便是平台工程,在这里,餐厅里的厨师便是平台工程师,他们所要做的便是,扩大菜品的种类,让顾客有更多的菜品可选。
由此可以知道,通过建设平台工程,可以让开发者以“自助式”实现应用的端到端流程,同时,将开发人员从不必要的认知负荷中解放出来,保留开发人员在需要时偏离路径的自由。而且对Ops工程师来说,采用平台工程还可以帮助他们摆脱重复做同样的任务。
DevOps的持续进化
“DevOps已死,平台工程才是未来”我们通过这句话便可以感受到平台工程的火热程度。甚至出于某种营销策略,总会有人将平台工程宣告为DevOps的终结。事实上,DevOps和平台工程并非这种“你死我活”的关系,在某种程度上,平台工程有可能为DevOps带来新生。之所以这样说,是有原因的。
DevOps主要根植于以敏捷开发为代表的持续开发方式的出现以及持续开发带来的运维问题。简单来看,DevOps往往涵盖包容、协作、自主和共同责任等要义,弥补了开发与运维间的矛盾。然而,在实践中,DevOps却出现诸多问题:
在面对许多开发和产品团队时,每个团队都在技术栈、工具、流程、云服务提供商及其特性和功能上做出自己的决定,进而导致效率低下,管理愈加繁重;随着云原生技术的推广与普及,无论从数量还是复杂性来看,工具环境都在快速增长。这种复杂性给开发人员带来了极大的认知负担,还增加了新功能开发的启动时间。
另外,DevOps也遇到了文化上的障碍。Puppet公布的2021年DevOps现状调查显示,83%的 IT政策制定者表示他们的公司已经开始使用DevOps。但是,大多数企业仍处于DevOps演化的中间阶段。在这些问题中,文化方面的问题是阻碍DevOps发展的最大障碍,而不合理的奖励机制和责任体系也可能对成熟性产生影响。
总体来说,在 DevOps实施的过程中,有一些企业将其简单化地理解为“让开发人员去负责运维的工作”,甚至于让高层开发人员接手运维的角色,使得开发逐渐无法承受。而以平台工程为代表的内部开发人员平台,可以让开发人员和运维人员将注意力集中在各自工作的核心职责和优势上,真正实现“术业有专攻”“专人做专事”。
写在最后
平台工程是一个强大的解决方案,它能帮助CIO把信息技术转化为企业的核心驱动力量,实现企业的价值。平台工程能够搭建并运行自助开发平台,为用户提供高效、可靠、安全的服务。应该指出,平台建设是一个长期而复杂的过程,它要求周密的规划、资源的投资、持续的关注与重复。
相关阅读