云原生是不是未来的趋势？如何落地是个问题？

云原生是不是未来的趋势？如何落地是个问题？

谈到云原生，不管从技术角度还是从业务角度出发，很多人对云原生众说纷纭，但结论不同。我咨询过很多在云计算这个领域里面的专业人士。有人说云原生就是容器、微服务、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 涉及文化、组织架构等与人相关的因素。微服务架构改造则涉及重发、重构、重写，如果是核心业务改造，风险大、问题多、人心难定。
小编以为对于新技术的落地有必要从边缘逐步到核心，沉淀经验在逐步替换，直接大刀阔斧的改革不是很有必要。