本着“不了解就没有评论的资格”，讨论之前有必要先搞清楚什么是云原生。不同于其他文章的长篇大论，我会用最简单的文字阐述我所理解的云原生。
基本概念
云原生，全称CloudNative。和其他热门的概念词一样，云原生也是从国外传入的概念（国外理论第一，国内应用第一），在国内是由阿里在2019年提出，所以普遍认为2019年是国内云原生元年。
到底什么是云原生？
云原生并不是某种具体的框架，而是一种设计思路（或者说概念），它倡导云原生应用都应该具有某些特征。从广泛认可的角度来看，大致包含四个板块
持续交付（CI/CD）
说白话，就是自动打包、编译、部署、运行。为什么呢？现在商业模式越来越多，竞争越来越紧张。几乎所有公司都希望可以更快：更多的功能，更快的更新，更小的代价。之前可能是一周一个小版本，一月一个大版本；之后可能会变成每天N个小版本的高频更新。尤其是进入微服务时代，各种微小的服务需要各自更新迭代，成本太高了。且在这一行，只要是人操作的，就不可避免会出错，只是概率高低而已。更新越快，出错概率越高。所以云原生应用，自动化是必须的。
DevOps（开发/运维）
不同于现在大部分公司的管理布局，云原生旨在开发/运维/测试不分家，是从项目（甚至是公司）管理方面的要求。有中型以上公司工作经验的，相信都有感觉，影响一家公司交付周期的，是这家公司的部门墙。开发代码写完提交给测试，测试流程走完提交给运维，这个过程中但凡是出现一次测试不通过、运维失误之类的，那交付时间就要滞后。除了Task没完成影响绩效，还有可能造成损失。到时候三方拉人一起开会，那就又是一例“三个和尚没水喝”。如果开发更专注于开发，剩下的交给自动化，岂不美哉？
微服务（Microservices）
微服务使程序高内聚、低耦合。根据业务和调度资源对程序进行分拆，被分拆的程序作为一个又一个微小的服务存在，彼此调用但互不影响。云原生如果没有微服务，自然是不够味的。至于如何搭建微服务应用，各大网课都有课程，不用我多说了吧？未来我会写一些微服务相关的文章，届时细细剖析。
容器化（Containers）
如果没有docker的出现，可以说微服务流行的概率约等于没有。容器化的好处太多了：可以忽略环境的差异进行统一维护，规模超大的情况下还可以用k8s等工具进行容器编排等等，可以说没有容器化，微服务的代价会高到无法选择。
全局来讲，云原生是一种技术发展的方向。可以感觉到，随着市场的发展，社会节奏的加快，更稳更快的技术交付已经成为判断技术力的新指标，究其根本还是业务倒逼技术发展。如果没有双11、618，可能就没有公司为了抗住高并发去升级架构；如果手机没有语音助手、全面屏没有人脸识别，可能机器学习、人工智能的理论仍然藏在某个研究所的档案室里。本文主要的目的是梳理讨论云原生的定义和价值，并不是针对落地应用做探讨。而且，并不是只要满足上面的四个前置条件就一定是云原生应用，就好像灵长类动物和人类有很多相似却不相同。
欢迎各抒己见！
