云原生的反面是什么？

最近接到一个评审的邀请，邀请我评审一个项目。该项目的创新点里大量提到云原生，对这一块很不熟悉。假期看了不少文章，总是觉得心虚，而且和我的知识链条相差太远。

云原生的“原生”到底是和什么概念对比阐述的？我看到很多文章的概念里有容器、微服务，这些概念以前也有了，而且云、虚拟化、容器这些东西，谁是原生的，哪一块不是原生的呢？

有的文章通过编程语言来区别本地和原生。但是感觉这个概念如果和语言相关，那未免太LOW了。个人觉得应该是直接在网页上开发的意思，但又觉得不是这么回事。

求解答，要不真不敢当评委了，害怕贻笑大方。

参考。
https://zhuanlan.zhihu.com/p/150190166
所以现在的项目申请，就是看谁会讲故事，以及这个故事到了哪位看故事人手上。对看故事的人熟悉，打打招呼，便能获得通过。也算是个圈子，渐渐的都是圈内人拿下项目。

说起云原生，不得不提一下云原生的细节定义，这里cloudfoundry对其有一些定义
http://www.cloudfoundry.cn/cloud-native-glossary/
其中最有名的就是12-factor apps

img

这边也已经有大佬把其中内容翻译并且解释了
https://www.kdocs.cn/view/l/skIUQnbIc6cJ

云原生(Cloud Native)，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。
Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。
Cloud Native也可以理解是一系列Cloud技术、企业管理方法的集合。

这...
评审大佬不了解概念，又刷新了我的认知

云原生，是云计算名词的延申，是基于分布部署和统一运管的分布式云 ，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。
在用简单的话术来讲其实就是资源整合，开发者无需考虑底层的技术实现，只需要充分发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等应用交付新模式。

简单的理解就是,
一个产品 是不是为了在云端部署 而做的,
反面就是 开发一个本地单机的,

一个产品如果以云原生开发, 日常访问几十, 服务器集群部署浪费, 单机部署资源不足, 就是一个失败的云原始
一个产品 单机的思路开发, 日常访问几万, 单机扛不住, 集群扩展麻烦, 这时候云原生的概念就显得特别重要,

云原始好不好 还是要看产品的当前体量好后期发展方向, 单纯的强调云原始 没啥意义, 那些大厂都是有足够的流量 促使他们的产品走上云原生

这玩意就很直接的去理解他，首先‘云’，就是人家提供的环境（包括基础设施或者半成品或成品服务），那么‘原生’就是前面这些东西的描述了，哈哈哈说白了就是直接用人家的提供的环境，不去自定义，优点还是比较多的，简单容易维护，人家也提供技术支持，向下传递也更容易。

今天看了大家的回答，又和人讨论了半天，并试着在容器里开发了一个小程序（以前就有MQ，但是连接的是几台计算机）。

感觉浅浅的有了点认识：

  1. 与虚拟机比： 同样是虚拟化，容器相对虚拟机而言是原生的。没有第二层OS，层次扁平。
  2. 与单机开发比：同样是用C语言编程，但运行在容器里，一开始就是为了云环境开发的（而不是改造单机版的），所以是对于Cloud来说是Native（原生、本地）的。开发者会避免使用显式配置的固定数据库链接、WebService，文件夹位置来IO，而是按分布式的思路从头来设计。容器进程起来后，IO与MQ、动态获取的资源打交道，与绝大多数固定的物理位置去耦合。
  3. 配置与部署： 把资源发布到环境里。所有的二级以下配置，都能从一个统一的一级配置服务里获取。部署/拆除也是自动的，不用在部署前，人为或者半自动的触发配置文件修改工作。

这个东西确实是很大体量的请求场景才能用的到。所以能不能这样理解，给一个访问量不超过100台计算机，一天几万业务量的应用上此环境，可能开发成本会很高。另一方面，如果某个项目号称是“云原生”，但是还是要人工配置CFG文件、指定节点数，访问人工指定的固定的关系数据库，那就是乱套用概念在忽悠人。