DevOps的下一步:大模型加持的平台工程呼之欲出

DevOps的下一步:大模型加持的平台工程呼之欲出
2023年09月15日 17:55 科技看门道

过去几年,DevOps的理念风靡全球,甚至衍生出SecOps、FinOps、DevSecOps等一系列的软件开发运营管理模式,其目的无非是希望把开发者和IT运营人员衔接起来,围绕产品生命周期提升交付效率与质量。理想是丰满的,但现实总是很骨感。

“随着云原生、Kubernetes平台越来越主流化之后,一方面DevOps对资源管理来说确实效率很高,但另一方面随着复杂度的大幅提升,对DevOps人员的能力要求也越来越高。”数澈软件Seal联合创始人兼CTO梁胜博士在2023平台工程技术峰会上表示,实际上DevOps有点走进了死胡同——DevOps并不能取代研发人员,DevOps取代的是传统运维,但DevOps在企业的需求和人力成本中所占的比重却越来越大,这一定是出了什么问题!

数澈软件Seal联合创始人兼CTO梁胜博士在2023平台工程技术峰会上

云环境之变

我们知道,云计算最早是由亚马逊公司在2006年提出来的,目的就是要利用为圣诞季准备的大量服务器、存储资源,在平时空闲时间提供给其它中小公司,从而节省成本。这样的一个单纯商业模式的变化,引发了整个IT技术的变革,从虚拟化计算、存储、网络资源池,到容器化、微服务,让系统虚拟隔离,甚至直接划分出独立的运行环境,不仅占用资源更少,而且部署速度更快。

实际上,梁胜博士本人就曾经是DevOps理念的核心践行者之一——他早在10年前就创办了全球用户量最多的容器云管理平台Rancher Labs,而容器的核心,就在于可以跨平台,从而让程序员可以享受到研发生产环境一致性的便利,即DevOps。

然而随着云原生逐渐成为主流,我们发现很多当年的客户,还在不断往容器云平台上面构建新的一层平台。"梁胜解释说,这是因为云原生的微服务场景越来越多,部署复杂度也就随之水涨船高,比如企业采购了CICD、监控、安全这些之后,研发人员理解的应用管理与基础设施云平台、Kubernetes能提供的资源管理之间还是有一段距离,所以他们只得不停地构建平台来弥合这最后一公里。

这种情况并非个例,而已经成为一种普遍现象。​在过去两三年间,梁胜及其团队和至少几百家企业交流过,发现每个企业都有类似的需求,在搭建平台过程中都对中间的一层花费了大量的精力,最终形成了企业内部的“应用管理”平台,它为研发人员提供UI、CLI以及服务目录(Catalog)。

换句话说,整个业界都在为打通这最后一公里而各自开发平台,原因很简单,因为在新的云原生环境下,每家企业都有足够的灵活度,让DevOps很难抽象共性,于是对运维侧的需求越来越大,很多时候,企业的研发人员都不得不一起去排查错误,显著影响了企业的研发效率。这,显然造成了巨大的人力资源的浪费

DevOps与Guardrail

应该说,DevOps的初衷是敏捷开发和自动化部署及运维,容器和微服务架构为DevOps提供了很好的前提条件。但是,也正是由于容器和微服务的灵活性,使得底层资源和应用管理之间的适配总是不断出现新的问题。如何才能一劳永逸地解决这最后一公里的问题呢?Gartner在2023年十大战略技术趋势中给出了答案——“平台工程”

所谓“平台工程”,是一套用来构建和运营支持软件交付和生命周期管理的自助式内部开发者平台(Internal Developer Platform, IDP)的机制和架构。平台工程的目标是优化开发者体验并加快产品团队为客户创造价值的速度。Gartner甚至预测,未来3年内80%的软件工程组织将建立平台团队,构建“平台工程”。

作为第三方市场调研机构,Gartner的预测更多是基于目前的市场调研。很明显,目前越来越多的企业都在扩充其运维团队,其中一部分正在开发内部运维平台。不过,既然都AI时代了,难道就没有什么可以节省人力成本的新方案吗?

梁胜举了一个自动驾驶的例子,比如今天的自动驾驶汽车,需要无数个传感器和摄像头的加持,才能确保安全性,最终达到L4甚至更高级别无人驾驶的标准;但是飞机早就达到了自动驾驶的要求,因为飞机有航线,降落和起飞也都有每个机场标准的虚拟滑梯轨道,只要设定好了,就按照那个走就好了,唯一的变量在于天气,在于风向和风力;这就如同,城轨有了轨道的规范,有了自动驾驶的功能之后,很快就在全球范围内很多城市实现了无人驾驶。

换句话说,为DevOps搭建自动化运维最后一公里的关键,在于这个Guardrail护轨/护栏的自动化设计能力的强度和广度。显然,这是目前市场上所缺的。

大模型加持平台工程

“是OpenAI的GPT让平台工程赋予了DevOps新的机遇。”在梁胜看来,平台工程与DevOps并不是非此即彼的关系,相反,平台工程是DevOps的下一阶段。实际上,“平台工程”的概念就是一种Guardrail护轨,目标是把DevOps的复杂度控制下来。而OpenAI的GPT则可以帮助“平台工程”更智能地依照不同企业差异极大的内部环境进行个性化设计,从而真正落地DevOps自动化开发运维的最后一公里,最终,能够帮助企业降低技术运维人力资源成本,把资源重新聚焦到研发上面。

正是基于这种理念,数澈软件Seal历经半年多的调研与打磨,先期推出了具备一键部署和克隆复杂应用系统、集成AI大语言模型简化模板代码生成以及灵活强大的应用和环境动态管理能力等特性的开源应用管理平台Walrus。Seal希望通过基础设施自动化、用户自服务、AI 驱动的应用自交付/自部署/自管理(ADAS),改善传统协作模式,推动DevOps规模化落地

“我们从来不认为GPT 4,或者哪怕将来的GPT 5会是答案,因为它们是通用的大模型,所包含的数据量太大了,另外还存在隐私、安全,以及使用成本太高的问题。”梁胜认为,聚焦专用场景,投入资源来训练一些行业专业的GPT模型是更现实和可行的。

数澈软件Seal联合创始人兼COO江鹏现场演示了Walrus对于普通用户,无需了解底层技术细节的前提下自助构建、部署和运行应用程序的过程,减轻开发人员的认知负担。这实际上体现了Walrus已经具备了将云原生的能力和最佳实践扩展到非容器化环境,屏蔽基础设施的上层抽象,并支持任意应用形态统一编排部署,降低使用基础设施复杂度的能力。

值得一提的是,Seal还宣布Walrus基于Apache 2.0许可正式开源。据悉,Walrus 中的服务模板依照 DRY(Don't Repeat Yourself)原则设计,用户可以重复利用并在实际使用过程中逐渐沉淀研发和运维团队的最佳实践。

而在最新版本中新增的Catalog全面兼容原生Terraform Module 仓库管理模式,用户可一键复用 Terraform 社区上万个成熟的 Module,自定义应用所需的服务模板,进行统一管理和调用。

显然,作为一个有着浓厚开源基因的Seal创始团队,从CloudStack到Rancher Labs到SUSE一路走来,凭借开源法宝经历了无数成功的喜悦,如今在初创企业Seal身上,仍然希望复制过往的荣耀

“我们做开源十几年了,但真正体会到开源的力量,还是在最近AI真正出现并落地之后。”梁胜展示了一张图表,“众所周知,Kubernetes早已成为业界认可的容器编排的事实标准。但是AI相关的开源项目star数量能在几个月之内就超越Kubernetes,令人叹为观止。”

事实上,一整天的2023平台工程技术峰会上,Thoughtworks、万物新生、哔哩哔哩、滴滴出行、享道出行等企业轮番上阵,分享其在平台工程领域和AI大模型领域的探索。这表明,企业对开源和平台工程的重视程度与日俱增,同时开源和大模型也确实能为企业DevOps带来一些真正的机会。

笔者相信,AI加持的平台工程能够真正为企业用户带来全新的应用部署体验和软件交付范式。而数澈软件Seal和一众中国高科技创新企业,必然会把开源的优势发挥到极致,在应用交付领域打造出世界级的开源应用管理平台。

文/余文

《科技看门道》坚持深度报道,希望能通过资深媒体人对IT产业热点新闻的深入思考,挖掘其背后的商业逻辑和创新模式——不仅看热闹,更要看门道!

《科技看门道》主笔在行业渠道媒体拥有20年的从业经历,不仅对IT消费类和企业级软件、硬件、云计算、大数据、人工智能、区块链均有较深入的理解,同时见证了中国IT产业链上下游合作生态圈包括分销、零售、SI、ISV和CSV的进化历程,见证了金融、能源、制造、医疗、教育、政府、零售、高科技等行业的信息化和数字化转型之路。

《科技看门道》相信,IT产业在供给侧的改革——包括云计算、大数据、移动互联、人工智能、区块链等,将会成为推动各行各业发展进步的核心力量。

财经自媒体联盟更多自媒体作者

新浪首页 语音播报 相关新闻 返回顶部