既然您已经阅读了一篇超越12因素应用程序的讨论，并且了解到人们经常交替使用“12 factors”和“cloud native”，那么值得花点时间讨论一下cloud native这个术语
像“SOA”、“云原生”和“微服务”这样的流行语和短语都是因为我们需要一种更快、更有效的方式来交流我们对某个主题的看法。这对于促进复杂话题上有意义的对话至关重要，我们最终会建立一个共享的背景或共同的语言
这些流行语的问题在于，它们依赖于多方之间的相互理解或共同理解。就像经典的“电话传话”游戏一样，这种所谓的共同理解随着信息的传播逐步迅速恶化为相互之间的困惑
我们在SOA（面向服务的体系结构）中看到了这一点，并在云原生概念中再次看到了这一点。似乎每次共享此概念时，含义都会改变，然后我们对云原生的理解会越来越多
要理解“云原生”，我们必须首先理解“云”。许多人认为“云”是公开、不受限制地接触互联网的同义词。虽然有一些云产品属于这种类型，但是这离完整的定义相差甚远
在本书的上下文中，云就是指PaaS(平台即服务)。PaaS提供者公开了一个平台，该平台对应用程序开发人员隐藏了基础设施的详细信息，该平台位于基础设施即服务（IaaS）之上。PaaS提供商的例子包括googleappengine、Redhat openshift、Pivotal Cloud Foundry、Heroku、AppHarbor和Amazon AWS
关键的一点是，云不一定是public的同义词，企业程序也可以运行在自己的数据中心、在自己的IaaS之上或在第三方IaaS提供商（如VMware或Citrix）之上建立自己的私有云
接下来，我对短语“cloud native”中的“native”一词表示异议。这造成了一种误解，即只有新开发的符合云部署流程的应用程序才能被视为云原生应用程序。这是完全不现实的，但由于“云原生”这个短语现在无处不在，并且在大多数IT圈中迅速扩散，我不能使用“云友好型”、“云就绪型”或“云优化型”这样的短语，因为它们既没有现在流行的原始短语那么吸引人，也没有得到广泛认可变成我们的方言。下面是我对云原生应用程序的一个简单定义：
一个云原生应用是一个被设计成并且最终运行在PaaS平台上的并且可以任意水平扩展的应用程序
一旦开始为一个概念添加更多细节，你就必须开始从其他人的角度来看待什么是cloud native，你可能陷入“实用主义与纯粹主义”的争论当中（本章稍后讨论）
不久前，部署应用程序还需要跑到空调机房里面找到某个具体的物理服务器，然后安装应用程序
裸机部署充满了问题和风险：我们无法动态扩展应用程序，部署过程很困难，硬件的更改可能会导致应用程序失败，而硬件故障通常会导致大量数据丢失和严重停机
这导致了虚拟化革命。每个人都同意裸机不再是发展的方向，于是hypervisor诞生了。业界决定在硬件上加一层抽象层，这样我们就可以更容易地进行部署，横向扩展我们的应用程序，并希望能够防止大量的停机和硬件故障带来的损失
在当今这个设备和软件不断智能化，并且不断互联的世界里，你可能很难找到一家不以软件开发作为公司重点的公司了。即使是在传统的制造业，存在一些需要制造硬件的物理的产品，可是如果没有软件，制造业也不会发生。没有软件，人类就无法被组织起来去高效的构建大规模的产品，没有软件，你当然无法参与全球市场
不管你在哪个行业，如果没有快速交付可靠软件的能力，你就无法在当今的市场上竞争。它需要能够动态扩展以处理以前闻所未闻的大量数据。如果你不能处理大数据，你的竞争对手就会。如果您不能生产出能够处理大量负载、保持响应能力和像市场一样快速变化的软件，您的竞争对手将找到一种方法
这让我们了解了云原生的本质。那种公司有大量的时间和精力花费在运维工作上，结果构建和维护出来的的却是脆弱的基础设施，以及提心吊胆的每月进行一次发布的时代已经一去不复返了
今天，我们需要专注于更加重要的事情（指的是业务相关），我们要做的比竞争对手更好，然后让平台来满足我们的非功能性需求。吉姆·柯林斯在他的《Good to Great》（HarperBus-iness）一书中提出了一个问题：你是一只刺猬，还是一只狐狸？
希腊诗人和唯利是图的阿奇洛胡斯首先讨论了这个概念，他说：“狐狸知道很多事情，但刺猬知道一件大事。”这句话的核心迫使我们审视我们的时间和资源花费在了哪里，并且想一想花费时间和资源的事情到底是不是我们最重要的事情。你的公司或团队想要完成什么？很可能，您没有用故障转移、快速回复、弹性可伸缩性或自动部署之类的东西来回答这个问题。不，你想做的是把你和其他人区别开来。你想构建一个能让你立于不败之地的东西，把其他的琐碎的事情都留给别人去做
现在是云时代，我们需要以一种拥抱云的方式构建我们的应用程序。我们需要把大部分时间花在刺猬（一件大事）上，让别人或其他人来处理狐狸的许多小事。以最快的速度上线你的产品是如今的市场要求我们必须做到的；它是避免我们被自己的的竞争对手抛在后面的必要条件。我们希望能够将我们的资源投入到我们的业务领域，让其他专家去做那些比我们做得更好的事情
通过拥抱云原生架构，遵循一切皆是服务原则构建出来的并且部署到云上面的应用将能够享受到极大的好处。问题不是为什么要拥抱云原生？问题是你为什么不去拥抱云原生？
纯粹主义者vs实用主义者
从SOA到REST的所有模式，以及介于两者之间的所有模式，既有象牙塔顶上闪耀的理想，也有现实世界中的开发团队、预算和约束的现实。诀窍在于决定哪些理想是你不会让步的，哪些理想你会稍微妥协，以满足实际的需要，让产品按时上线
在这本书中，我提到了对理想的妥协在哪里是可能的，甚至是常见的，但是也清楚地表明了依据我们的经验哪些地方是不能妥协的。最终决定权在于你，如果我们创建的每个应用程序都是一个从未违反本书中任何一条指导原则的纯云原生应用程序，我们会非常高兴，但现实和经验表明，对纯粹主义理想的妥协就像死亡和税收一样永远存在
在规划和实施云原生应用程序时，学习何时何地在本书中的指导原则上妥协可能是最重要的一项技能，而不是完全照搬所有原则或者完全抛弃这些原则