云原生是不是未来的趋势?如何落地是个问题?
谈到云原生,不管从技术角度还是从业务角度出发,很多人对云原生众说纷纭,但结论不同。我咨询过很多在云计算这个领域里面的专业人士。有人说云原生就是容器、微服务、DevOps等技术;有人说云原生是就是生在云上、长在云上……要理解云原生,要先弄清楚云原生的概念。
云原生的概念
如何理解云原生这个概念呢?判断观点的正确性,我们需要找到最先发表出这个观点的人,看他对这件事物的描述和理解,追本溯源。我们来看云原生概念的发展:
- 2015年Pivotal公司Matt Stine撰写了一本书《迁移到云原生应用架构》,提出云原生应用架构的几个特征:1.符合12因素应用、2.面向微服务架构、3.自服务敏捷架构、4.基于API的协作、5.抗脆弱性。
- 同年Google主导成立云原生计算基金会(CNCF),CNCF对云原生的定义包含:应用容器化、面向微服务架构、应用支持容器的编排调度。
- 2017年同样是Matt Stine本人,在接受采访的时候被问到云原生的定义和特性,又做了一些调整:模块化、可观测性、可部署性、可测试性、可处理性、可替代性。
- 2018年CNCF社区的不断壮大,云原生生态和市场认可不断变强,云原生概念又在变化:云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
- 2019年在Pivotal的官网上,对云原生的概念也发生变化。
到目前为止我们可以看到云原生不是一个单纯的技术,他的概念不同的组织、个人在不同的时空都有不一样的认知和见解。未来云原生的定义肯定还会变化!
如果真的要给当下的云原生下一个定义,个人对技术和业务的理解,可以这么描述:云原生是一种业务与技术结合的管理方式,能够在多云模式下(公有云、私有云、混合云)灵活地构建大规模应用,实现自动化的管理方式。像是工业化替代纯人力工作、敏捷开发在某些领域替换传统开发,解决业务问题的同时,提高生产效率。
云原生解决的问题
前面我讲到很多人对云原生的理解就是:生在云上、长在云上。那云原生肯定也是解决“云”的一些问题。
传统基于虚拟化的云平台,为应用提供资源是通过虚拟机的方式实现,每台虚拟机都会有自己的包括内核、系统等。启动虚拟机的过程会需要占用少部分的CPU等资源,并且未解决安全问题,VPC是按照虚拟机为颗粒度进行管理。例如:在一个数据中心有100颗CPU的资源,虚拟化本身可能会占用10几颗CPU用来维持正常虚拟化环境。
在这个过程,云平台为应用提供的资源与业务本身是没有直接联系的,业务代码和基础架构之间是分开的。基础架构不关心虚拟机上部署了业务,这就导致升级和维护比较困难。
我们会发现基于虚拟化的云平台主要面对的问题是:
- 资源利用率低:虚拟机开销大、资源颗粒度大
- 操作系统比较复杂:宿主机OS、Hypervisor、虚拟机OS
- 业务与基础架构分离,难运维
云原生基于云的环境,能够更好地满足应用的业务需求,把复杂的非业务需求剥离开来,打包在一起下沉到基础设施和中间件中,让应用真正的服务于业务,专注于满足有价值的业务需求。
云原生不是普及问题是落地问题
以往数十年的技术发展,技术本身也经历了数次更迭,开发者对新兴技术的接受度本身是比较高的。随着 CNCF 社区的发展,加上市场的不断发酵,开发者对于云原生概念基本达成理解和共识,难点在于落地。
CNCF 社区将更多技术集成到 Kubernetes 的生态中,Kubernetes也在很多场景和技术中实践和测试:K8s可以管理虚拟机、容器,实现Serverless等。云原生的落地涵盖了技术、业务、组织等,与业务相关更与人相关。
具体来说,DevOps 涉及文化、组织架构等与人相关的因素。微服务架构改造则涉及重发、重构、重写,如果是核心业务改造,风险大、问题多、人心难定。
小编以为对于新技术的落地有必要从边缘逐步到核心,沉淀经验在逐步替换,直接大刀阔斧的改革不是很有必要。