不知从何时起，几乎所有的云计算厂商都在提容器、Kubernetes、DevOps、Serverless、ServiceMesh等等概念，那么云计算领域到底发生了什么？如何看待云原生在2019年的最新变化？云原生基础设施领域有哪些值得关注的重要趋势？面对这些复杂的技术问题，相信许多人都云里雾里。

▲灵雀云CTO陈恺

“2019年是云原生概念和技术普及的元年，未来云原生会变成一个常态。” 灵雀云CTO陈恺，有曾经在微软美国总部开发云计算平台 Azure的工作经历，对于云原生以及相关的技术热点，有着独特的视角。他认为，在数字化转型压力下，大多数企业已经能够接受云原生概念，所以云原生普及不难，难的是如何去落地。

过去，企业传统业务系统的研发并不受重视，比如银行内部的业务管理系统，一般采用的是Oracle、SAP等第三方产品，不做自己的软件产品研发，有些企业甚至都没有研发人员。但是，数字时代企业IT发生了根本性转变。企业需要开发、上线、运营自己的产品。企业之前的软件开发模式、迭代速度和频率可能不能满足数字化背景下的企业需求。软件产品的场景由支撑角色转向了竞争性场景。比如车联网、自动驾驶、风控、营销、互联网金融等，如果软件产品迭代速度跟不上，就可能失去了企业的生存空间。在这样的背景下，云原生迎来了“施展才华的舞台”。

随着信息技术的不断深入，很多企业都有大量复杂的传统应用，虽然这些应用还在遵循传统的开发模式，但是一些新业务会以云原生的方式落地。云原生让企业体验到云带来的优势，他们开始考虑如何兼顾两种类型的应用，对传统应用进行改造，这也是我们常说的“双态IT”概念，即敏态和稳态应用。等发展到一定阶段，企业会把业务全面云原生化。

简单理解，企业在数字化转型过程中，云原生是必然选择，中间会涉及很多关键技术，包括Kubernetes、DevOps、Serverless、ServiceMesh、微服务架构等等，这些技术是一个有机统一体，相互关联。那么，从选型的角度看，我们该如何正确处理各种技术之间的关系？

1、Kubernetes会替代OpenStack吗？

现在，Kubernetes在云原生领域的发展态势可以说是如火如荼，大有超过OpenStack的趋势；但另外一种声音则表示，Kubernetes和OpenStack在不同领域各司其职， OpenStack面向的是底层基础设施的虚拟化，而Kubernetes更多面向的是应用层。那么，Kubernetes和OpenStack到底是怎样一种关系，Kubernetes会替代OpenStack吗？

“的确，Kubernetes和OpenStack二者应用并不冲突，但随着Kubernetes的发展，OpenStack的应用场景会越来越小。” 陈恺认为，Kubernetes超越OpenStack是一件自然而然的事儿。

OpenStack刚刚诞生的时候，很多企业认为它更适合做公有云，但是采用OpenStack做公有云不太可能成功。后来，大部分企业用OpenStack做私有云，但是经过一段时间验证，OpenStack的优势并没有完全超越VMware。而Docker和K8s出来以后，底层技术平台的游戏规则彻底被改写，Kubernetes容器编排平台变成Stack的中心，不管是VMware、OpenStack还是公有云以及裸机，所有的应用环境都能支持。

灵雀云基于开源Kubernetes分不同层级给企业用户提供产品和服务。最底层的是Alauda Kubernetes（AKS），是一个企业就绪的K8s发行版，跟上游K8s 最接近，包含开发者和企业用户都需要的功能，如：自动化部署、网络存储、升级、企业用户／租户权限和监控、日志等都集成在其中，开箱即用。和社区版Kubernetes相比，灵雀云企业就绪发行版的最大的区别是，“源于K8s ，但高于K8s”，它基于100多家头部客户的生产环境经验。再往上一层，是灵雀云的ACP 2．0（Alauda Container Platform），它的定位是一站式云原生应用赋能平台，包含三个子产品：一个是容器平台（Alauda Container Platform）、DevOps平台（Alauda DevOps）和服务网格Service Mesh（Alauda Service Mesh，简称“ASM”），是用来做微服务治理的平台。

2、为什么要打造开放式DevOps工具链集成与编排平台？

除了推出与Kubernetes相关的产品，灵雀云还要打造一个开放式的DevOps工具链集成和编排平台。如何理解这一概念？

“尽管DevOps本身和K8s关系不大，但是我们的产品架构是基于K8S原生架构。换句话说，我们用K8s作为开发框架，用它的API来编排所有DevOps需要的工具。”很多企业在做DevOps时，流程非常长，涉及到很多阶段，每个阶段都要选很多工具，并且没有固定标准。灵雀云DevOps平台并不是要做一系列新的工具出来，说服用户用灵雀云的CI／CD，而是尽可能地去兼容客户已有的工具，甚至对用户未来的工具选型也能适配，用更开放式的集成和编排方式，去纳管客户所有的工具。

所以， 灵雀云的DevOps工具链集成主要服务于三个场景：第一，CI／CD；第二，敏捷性的项目管理；第三，DevOps端到端的数据可视化，把不同工具的数据打通，然后在整个DevOps流程里面通过数据串连。同时，提炼DevOps落地最佳实践，将DevOps最佳实践自动化，作为服务提供给客户。

3、如何理解微服务架构？

至于，微服务架构，本质上是用运维的复杂度去换取敏捷性。

在陈恺看来，微服务早期很痛苦，因为没有相配套的工具以及相关的基础设施去管理应用的复杂度，微服务改造效果完全依赖技术团队本身的能力和水平。一些技术能力很强的企业，会在微服务改造过程中慢慢沉淀出属于自己的微服务工具和框架，然后再把这些工具和框架开源出来。

另外，企业早期做微服务之所以很痛苦，是因为应用的复杂度是未知状态，开始做微服务的时候没有意识到，具体操作后才发现，把一个单体应用变成一个分布式单体应用，是非常痛苦的一件事。后来，当容器和K8s成为流行趋势后，微服务才有了与之配套的工具和基础设施。

其实，K8s刚开始出现的时候，很多人把它拿来和SpringCloud对比，因为之前很多人都用SpringCloud来做微服务治理，解决服务的复杂度。但是K8s和SpringCloud放在一起使用总是有些别扭，后来基于大型互联网公司的一些业务驱动的实践，在K8s之上探索出了新的微服务治理的方式，Service Mesh、Istio 、Envoy等优秀的技术和产品，都是用户不断选择不断创新出来的。

4、函数计算会是Serverless的最佳实现范例吗？

众所周知，函数计算最主流的产品就是AWS Lambda，2014年亚马逊正式推出。Lambda的推出，标志着Serverless时代正式开启，所以Serverless的大多数应用场景都在Lambda上面。

但是，Lambda并不是一个开放式的标准，绑定性比较强，这意味着你的API、函数包装的格式都必须是AWS的应用，否则如果将来要迁移，会有很多不确定性。尤其是国内的很多企业，他们不希望把所有的应用全部放在公有云，这是Serverless模式落地的最大挑战。

但是，从总体发展趋势上看，大家对于这种按需服务的Serverless模式非常感兴趣。虽然从个人角度看，Serverless模式看不到服务器，但其实它的服务器在由公有云厂商负责。而私有云模式，服务器就在企业用户的眼前。Serverless的一大卖点是，从0到无限的规模化扩展能力，这在公有云上容易实现，但私有环境很难具备这样的优势。不过，无论是私有云厂商还是社区，都在极力推动私有部署的Serverless架构的发展。并且，从技术层面，也逐渐达成了共识。我们可以用K8s编排容器、虚拟机等，为什么不能用来编排函数？这是正在进行中的一个趋势。

而从最佳实践角度看，Serverless概念本身肯定要比Function更广泛，Serverless可以包含函数、数据库，所有服务都可以是Serverless的，比如：Fargate，这种无服务器的容器服务也算Serverless，任何不用自己管理服务器的行为都可以叫Serverless。

总体来看，云原生是大势所趋，而灵雀云会以基础设施管理为核心，Kubernetes、DevOps、微服务三大技术为牵引力，不断做技术层面的布局。对于企业专注的云原生核心应用和技术能力，会进行产品和研发方面的投入；对于云原生和容器周边应用，则借助外部合作伙伴力量，集成第三方产品，逐步扩大云原生服务能力。