可预测：云原生应用符合一个通过可预测行为来最大限度发挥弹性优势的“合同”。高自动化，容器驱动的架构使用云平台驱动改变了软件交付形式。这种“合同”的一个很好的例子就是heroku的十二因素应用。

不确定性：传统应用在开发方式和架构上往往不能真正发挥云服务的优势。这样的应用通常需要很长的时间来构建，一次发布很多内容，只能逐步伸缩，并常伴有许多单点故障。

操作系统抽象：云原生应用要求开发者使用一个平台作为基础设施，意味着应用的基础设施是经过抽象的，更易于迁移和伸缩。构建抽象平台的方法可以自己搭建也可以购买第三方服务，比如Openshift，Cloud foundry。

操作系统依赖：传统的应用程序架构使得开发人员习惯于在应用程序和底层操作系统，硬件，存储和后台服务之间建立紧密的依赖关系。相比于云原生应用，这种依赖会让应用的迁移和伸缩变得异常复杂和充满风险。

大小适合的容量：云本地应用平台可自动进行基础设施配置，并根据应用的需求在部署时重新动态分配资源。管理好一个云原生应用运行时的全生命周期，可以做到按需伸缩，提高资源利用率，编排计算资源，以及最短宕机时间的故障恢复。

过大容量：传统的IT设施为应用设计了专属的技术设施架构，为一个应用准备充足的基础设施资源，从而延迟应用的部署。这种设计方案通常会按照最坏情况下估算容量，解决方案的规模往往大大超过实际需要的规模。

共同协作：云原生促进DevOps，人员，流程和工具的组合，从而在开发和运营之间进行密切协作，以加速和平滑将完成的应用程序代码发布到生产环境中。

部门孤立：传统IT在开发和运维之间有高高的部门墙，开发要跨过一堵墙来向运维交付软件，组织事务优先于客户价值，导致内部冲突，妥协和缓慢的交付让员工士气低落。

持续交付：IT团队的产品永远处于可发布状态。发布软件的周期保证了更短的反馈周期，并能更有效地响应客户需求。持续交付最好和其他一些实践一起使用，例如测试驱动开发和持续集成。

瀑布模式：IT团队定期发布，通常周期为数周至数月，尽管代码已经完成构建，甚至于其他部件并无依赖，仍然不能发布。客户期望的功能总是被搁浅、延期，企业从而丧失了竞争优势、客户、和机会。

独立：微服务架构将一个复杂的应用解耦为一个个小而独立的模块，这些小的服务由一个个小型团队开发和运维，确保各自独立、频繁的更新，伸缩和故障切换/重新启动，而不影响其他服务。

依赖：单体架构将原本不需要绑定的模块绑定在一个软件包中发布，导致开发和部署过程中的敏捷性丧失。

自动扩容：基础设施自动扩容可以消除宕机时间和避免人为操作失误。计算机自动化不会遇到任何类似的挑战，在任何规模的部署中都使用同一套部署脚本。云原生也超越了基于传统的面向虚拟化的业务流程的自动化实践。一个完全的云原生架构包括适用于团队的自动化和业务流程，而不是要求他们习惯于写自动化脚本。换句话说，团队的目标是使得构建和启动应用变得易于管理，而自动化只是其中的一个手段。

手动扩容：人工基础设施包含了人工运维和人工管理的服务器，网络，以及存储配置。扩容工作因为其复杂性，运营人员很难在扩容过程中诊断问题，而且实施过程中很容易出现错误，手工编写的配置文件有可能将人为错误的硬编码到基础设施中，成为一个很难发现且长期存在的隐患。

快速恢复：容器化运行时提供了一个虚拟机之上的动态，高密度的虚拟层，是理想的微服务托管方式。动态管理容器在宿主机上的编排，方便及时回滚，扩容，和重现错误。

缓慢恢复：基于虚拟机的基础架构对于基于微服务的应用程序来说是一个缓慢而低效的基础设施，因为单个虚拟机启动/关闭的速度很慢，甚至在部署应用程序代码之前也就带来很大的开销。