PaaS、DevOps、OpenShift与业务中台的实现

  • 2019 年 11 月 28 日
  • 筆記

导读:在激烈的市场竞争条件下,企业既要进行业内的竞争,还要防止跨界黑马杀进来被升维打击而造成利润下降,这就需要保持竞争力,需要让自己的客户有更好的体验。

企业在通过IT手段提升业务竞争力和客户体验的时候,需要选一些比较新的技术架构和工具。正是由于PaaS、DevOps、微服务可以直接为业务带来收益,因此受到了企业极大的重视。

接下来,我们将讨论企业数字化转型的步骤。

作者:魏新宇、郭跃军

来源:大数据DT(ID:bigdatadt)

01 企业数字化转型之PaaS

PaaS的全称为Platform-as-a-Service,平台即服务。在Docker出现以前,企业IT的建设更多是围绕IaaS进行的。而IaaS的基础包括计算虚拟化、网络虚拟化、存储虚拟化,在此之上构建云管平台。

在虚拟化层面,最为著名的公司当属VMware。传统UNIX服务器的落幕、x86服务器的崛起,很大程度得益于VMware公司的vSphere虚拟化技术。虚拟化中的高可用(HA)、在线迁移(vMotion)等特性,很大程度上弥补了(与UNIX服务器相比)早期x86服务器的稳定性相对较差的缺点。

2010年1月,OpenStack第一个版本发布,开启了开源界私有云IaaS建设的热潮。但在2012年Docker出现后,很多IT企业和行业客户将IT的重点迅速从OpenStack转向Docker,原因何在?

不管是vSphere还是OpenStack,其面向对象都是虚拟机。对于企业而言,虚拟化实现了操作系统和底层硬件的松耦合,但虚拟机承载的是操作系统,我们依然需要在操作系统中安装应用软件。

而Docker可以在容器中直接运行应用(如Tomcat容器镜像),这比虚拟机更贴近于应用,更容易实现应用的快速申请和部署,极大地促进了容器云PaaS的迅速发展。

到目前为止,绝大多数的企业级PaaS产品是以Docker、Kubernetes为核心的,红帽(Red Hat)的OpenShift3也是如此。OpenShift4更进一步引入了CRI-O,这样OpenShift可以承载更多容器运行时:runc(由Docker服务使用)、libpod(由Podman使用)或rkt(来自CoreOS)。

2018年第四季度,全球著名的调研机构Forrester对企业容器平台(ECP)软件套件进行了评估,并确定了全球最重要的8个企业容器平台提供商:Docker、IBM、Mesosphere、Pivotal、Platform9、Rancher Labs、Red Hat和SUSE,参见图1-1。

▲图1-1 Forrester咨询公司2018年第四季度发布的企业容器平台调研报告

红帽的OpenShift整体表现是非常优秀的(Red Hat处于Leaders象限且Market presence较高)。

02 PaaS、DevOps与微服务的关系

PaaS、DevOps、微服务的概念很早就出现了。广义上的微服务和DevOps的建设包含人、流程、工具等多方面内容。IT厂商提供的微服务和DevOps主要是指工具层面的落地和流程咨询。

在Kubernetes和容器普及之前,我们通过虚拟机也可以实现微服务、DevOps(CI/CD),只是速度相对较慢,因此普及性不高(想象一下通过x86虚拟化来实现中间件集群弹性伸缩的效率)。而正是容器的出现,为PaaS、DevOps工具层面的落地提供了非常好的承载平台,使得这两年容器云平台风生水起。

这就好比4G(2014年出现)和微信(2011年出现)之间的关系:在3G时代,流量费较贵,大家对于微信语音聊天、微信视频也不会太感兴趣。到了4G时代,网速提高而且收费大幅下降,像微信这样的社交和互联网支付工具才能兴起和流行。

Docker使容器具备了较好的可操作性和可移植性,Kubernetes使容器具备企业级使用的条件。而IT界优秀的企业级容器云平台——OpenShift,又成为DevOps和微服务落地的新一代平台。

OpenShift以容器技术和Kubernetes为基础,在此之上扩展提供了软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、持续集成流程(S2I/Jenkins)、统一管理控制台、监控日志等功能,形成覆盖整个软件生命周期的解决方案。

所以说,OpenShift本身提供开箱即用的PaaS功能,还可以帮助客户快速实现微服务和DevOps,并且提供对应的企业级服务支持。

03 企业数字化转型之DevOps

DevOps中的Dev指的是Development,Ops指的是Operations,用一句话来说,DevOps就是打通开发运维的壁垒,实现开发运维一体化。

1. 从瀑布式开发到敏捷开发

谈到DevOps的发展史,我们需要先谈一下敏捷开发。

软件工程的方式有其优点,但也带来了不少问题。最关键的一点是:软件不同于工程。通过工程学建造的大桥、高楼在竣工后,人们通常不会对大桥或高楼的主体有大量使用需求的变更;但软件却不同。

对于面向最终用户的软件,人们对于软件功能的需求是会不断变化的。在瀑布式开发模式下,当客户需求发生变化时,软件厂商需要修改软件,这将会使企业的竞争力大幅下降。

传统的软件开发流程是:产品经理收集一线业务部门和客户的需求,这些需求可能是新功能需求,也可能是对产品现有功能做变更的需求。然后进行评估、分析,将这些需求制定为产品的路线图,并且分配相应的资源进行相关工作。

接下来,产品经理将需求输出给开发部门,开发工程师写代码。写好以后,就由不同部门的人员进行后续的代码构建、质量检验、集成测试、用户验收测试,最后交给生产部门。

这样带来的问题是,开发周期比较长,并且如果有任何变更,都要重新走一遍开发流程,在商场如战场的今天,软件一个版本推迟发布,可能到发布时这个版本在市场上就已经过时了;而竞争对手很可能由于在新软件发布上快了一步,而迅速抢占了客户和市场。

正是由于商业环境的压力,软件厂商需要改进开发方式。

2001年年初,在美国犹他州滑雪胜地雪鸟城(Snowbird),17位专家聚集在一起,概括了一些可以让软件开发团队更具有快速工作、适应变化的价值观的原则,制定并签署了软件行业历史上最重要的文件之一:敏捷宣言。

敏捷宣言中的主要价值观如下:

  • 个体和互动高于流程和文档。
  • 工作的软件高于详尽的文档。
  • 客户合作高于合同谈判。
  • 响应变化高于遵循计划。

有了敏捷宣言和敏捷开发价值观,必然会产生对应的开发流派。主要的敏捷开发流派有极限编程(XP)、Scrum、水晶方法等。至此,敏捷开发有理念、有方法、有实践。随着云计算概念的兴起以及云计算的不断落地,敏捷开发也实现了工具化。

2. 从敏捷开发到DevOps

谈到了敏捷开发,那么敏捷开发和DevOps有什么关系呢?敏捷开发是开发领域里的概念(上文已经介绍),以敏捷开发阶段为基础,有如下阶段:

敏捷开发→持续集成→持续交付→持续部署→DevOps

从敏捷开发到DevOps,前一个阶段都是后一个阶段的基础;随着阶段的推进,每个阶段概念覆盖的流程越来越多;最终DevOps涵盖了整个开发和运维阶段。正是由于每个阶段涉及的范围不同,因此每个概念所提供的工具也是不一样的。具体内容参照图1-2。

▲图1-2 从敏捷开发到DevOps的进阶

  • 持续集成(Continuous Integration):代码集成到主干之前,必须全部通过自动化测试;只要有一个测试用例失败,就不能集成。持续集成要实现的目标是:在保持高质量的基础上,让产品可以快速迭代。
  • 持续交付(Continuous Delivery):开发人员频繁地将软件的新版本交付给质量团队或者用户,以供评审。如果通过评审,代码就被发布。如果未通过评审,那么需要变更后再提交。
  • 持续部署(Continuous Deployment):代码通过评审并发布后,自动部署到生产环境,以交付最终用户使用。

DevOps是一组完整的实践,涵盖自动化软件开发和IT团队之间的流程,以便他们可以更快、更可靠地构建、测试和发布软件。

04 企业数字化转型的实现

1. 企业业务中台的建设

近两年,很多国内的企业都在谈业务中台建设。那么,什么是业务中台?实际上,业务中台是相对于“前台”和“后台”而言的。

前台由各类业务系统前端平台组成。每个前台系统就是用户接入点,即企业的最终用户直接使用或交互的系统。如网站、手机App、微信公众号等。前台是以用户为中心的互联网敏态业务。互联网公司先有前台业务,通过将通用业务下沉形成业务中台。

后台是企业的核心业务系统,例如财务系统、仓库物流管理系统等,这类系统构成了企业的后台。后台承载稳态业务。相比于互联网公司,企业客户先有传统业务系统,后有互联网+业务。由于后台更多的是保证核心业务的稳定运行,它并不能很好地支撑前台快速创新响应用户的需求。

但在目前阶段,对于企业而言,客户的体验又是非常重要的,因此企业通过建设中台解决前台的创新问题。通过构建中台,企业将后端业务资源服务化,用以支撑前端全渠道业务、互联网业务和以客户为中心的敏态业务,如图1-3所示。

▲图1-3 业务中台的实现方式

整个业务中台的全景图,将包含PaaS平台、DevOps、微服务治理以及微服务API管理、分布式集成与流程自动化,如图1-4所示。

▲图1-4 业务中台全景图

接下来,我们介绍企业数字化转型的步骤。

2. 企业数字化转型步骤

笔者在日常工作中,接触了大量企业客户数字化转型的案例,归纳整理出通常的转型步骤,如图1-5所示。

▲图1-5 企业转型步骤

图中的纵坐标为业务敏捷性,企业业务敏捷性方面的转型通常包含以下几步:

  • 第一步:构建PaaS平台。PaaS平台为开发人员提供了构建应用程序的环境,旨在加快应用开发的速度,实现平台即服务,使业务敏捷且具有弹性。近几年容器技术的崛起更是促进了PaaS的发展,红帽OpenShift就是首屈一指的企业级容器PaaS平台。
  • 第二步:基于PaaS实现DevOps。PaaS平台是通过提高基础设施的敏捷而加快业务的敏捷,而DevOps则是在流程交付上加快业务的敏捷。通过DevOps可以实现应用的持续集成、持续交付,加速价值流交付,实现业务的快速迭代。
  • 第三步:实现微服务治理。通过对业务进行微服务化改造,将复杂业务分解为小的单元,不同单元之间松耦合、支持独立部署更新,真正从业务层面提升敏捷性。在微服务的实现上,客户可以选择采用Spring Cloud,但我们认为Istio是微服务治理架构的未来方向。
  • 第四步:实现微服务高级管理。在微服务之上实现API管理、微服务的分布式集成以及微服务的流程自动化。通过API管理帮助企业打造多渠道的生态,最终实现API经济。通过微服务的分布式集成和流程自动化,企业可实现统一的业务中台。

图中横坐标是业务健壮性的提升,通常建设步骤为:

  • 第一步:建设单数据中心。大多数企业级客户,如金融、电信和能源客户的业务系统运行在企业数据中心内部的私有云。在数据中心建设初期,通常是单数据中心。
  • 第二步:建设多数据中心。随着业务规模的扩张和重要性的提升,企业通常会建设灾备或者双活数据中心,这样可以保证当一个数据中心出现整体故障时,业务不会受到影响。
  • 第三步:构建混合云。随着公有云的普及,很多企业级客户,尤其是制造行业的客户,开始将一些前端业务系统向公有云迁移,这样客户的IT基础架构最终成为混合云的模式。

企业的IT基础架构与业务系统是相辅相成的。在笔者看到的客户案例中,很多客户都是两者同步建设,实现基于混合云的PaaS、DevOps和微服务,并最终实现基于混合云构建企业业务中台。

关于作者:魏新宇,现为红帽资深解决方案架构师。在IaaS PaaS方面有丰富的经验,致力于开源解决方案在企业中的推广和应用。从售前角度主导了红帽在金融 汽车行业PaaS多个项目。

郭跃军,现为yamaxun AWS专业服务团队云架构咨询顾问。在2019年4月之前任职于Red Hat,担任PaaS咨询顾问。从2015年接触容器技术并开始学习OpenShift,参与了很多OpenShift项目的竞标PoC 咨询和落地实施,帮助很多企业实现了数字化转型。

本文摘编自《OpenShift在企业中的实践:PaaS DevOps微服务》,经出版方授权发布。

延伸阅读《OpenShift在企业中的实践》

推荐语:多位全球知名企业IT负责人联名推荐,两位红帽和AWS云计算和微服务资深架构师和技术专家合著,从实战角度全面剖析OpenShift和DevOps和微服务技术。适读人群 :本书适用于有一定 OpenShift/Kubernetes 基础的读者、企业的架构师、IT 经理、应用架构师、开源技术爱好者。