区别一

可预测的。原生云应用符合一个框架或“契约”，旨在通过可预测的行为最大限度地恢复弹性。在云平台上使用的高度自动化、容器驱动基础架构驱动了软件编写的方式，这种契约的一个很好的例子是这12个原则首先被证明为12要素应用。 

不可预测的。传统企业应用因为每个应用程序的独特设计或开发而无法实现在一个原生云平台上运行的所有好处，这种类型的应用程序通常需要花费更长的时间来构建，大批量发行，只能逐步扩展，并假定依赖服务的高可用性。 


区别二

操作系统的抽象。原生云应用架构允许开发人员使用平台作为从底层基础结构依赖项抽象的手段。团队没有配置、修补和维护操作系统，而是专注于他们的软件 。抽象的最有效的手段是一个正式的平台，比如，Pivotal Cloud Foundry是理想的基于云计算的基础设施，如谷歌的云平台操作（GCP）、微软Azure和亚马逊网络服务（AWS）。 

依赖操作系统。传统的应用程序架构允许开发人员在应用程序和底层操作系统、硬件、存储和后台服务之间建立紧密的依赖关系。这些依赖关系使应用程序在新的基础设施复杂和危险的情况下迁移和扩展应用程序，与云模型工作相反。 


区别三

适当容量。一个原生云应用平台在部署应用程序持续需要的时间里，自动化基础设施准备和配置，动态分配和重新分配资源。在原生云运行时上的构建优化了应用程序生命周期管理，包括扩展以满足需求、资源利用率、跨可用资源的编排，以及从失败中恢复到最小化停机时间。 

超大容量。传统的IT为应用程序设计了专用的自定义基础设施解决方案（“雪花基础设施”），延迟了应用程序的部署。该解决方案往往是基于最坏情况容量估计，规模过大，几乎没有能力扩大，以满足需求。 


区别四

 协同。原生云结合人、过程和工具促进DevOps，导致开发和运营功能之间的紧密协作，以加速并顺利地将已完成的应用程序代码转移到生产中。 

筒仓。传统的IT将完成的应用程序代码从开发人员移交给运维人员，然后将其运行到生产中。组织优先权优先于客户价值，导致内部冲突、缓慢和妥协交付，以及员工士气低落。 


区别五：

持续交付。IT团队一旦准备好就可以发布单独的软件更新。迅速发布软件的组织获得更严格的反馈循环，可以更有效地响应客户的需求。持续交付与其他相关方法最有效，包括测试驱动开发和持续集成。 

瀑布式开发。IT团队定期发布软件，通常是几个星期或几个月，当代码被构建到一个版本中时，尽管发布的许多组件早就准备好了，并且没有依赖于人工发布工具的依赖。顾客想要或需要的功能被延迟，商家错过了竞争、赢得顾客、增加收入的机会。


区别六

独立的。微服务体系结构将应用程序分解为小型的、松散耦合的独立操作服务。这些服务映射到较小的独立开发团队，并可以频繁、独立地更新、缩放和故障转移/重启，而不会影响其他服务。 

依赖。单体架构将许多不同的服务捆绑到单个部署包中，从而导致服务之间不必要的依赖性，并导致在开发和部署过程中失去灵活性。 


区别七

自动化的可伸缩性。规模化的基础设施自动化消除人为错误造成的停机时间。计算机自动化面临着这样的挑战，在任何部署规模上始终如一地应用相同的规则集。原生云也超越了传统虚拟化导向的编排之上的点对点自动化。完全的原生云架构是自动化系统，而不是服务器。

手动缩放。人工基础设施包括手工精细操作和管理服务器、网络和存储配置的人工操作器。在规模上，由于复杂度的问题，操作员在正确诊断问题时很慢，并且很难在规模上正确地实现。手工制作的自动化配方有可能将人为错误硬编码到基础设施中。


区别八

快速恢复。容器运行时和编排器提供了一个动态的、高密度的虚拟化覆盖在VM之上，理想的情况是与托管微服务相匹配。编配动态地管理跨vm集群的容器的放置，以便在应用程序的基础设施失败时提供弹性伸缩和恢复。

缓慢恢复。基于vm的基础设施对于基于微服务的应用程序来说是一个缓慢而低效的基础，因为单个vm在启动/关闭时很慢，甚至在部署应用程序代码之前就会有很大的开销。