EBay云平台首席工程师Subbu近日撰文论述了为什么传统的虚机不是云基础架构的好抽象，以及在他的眼里，什么是Cloud Native。本文截取自他的观点，点击原文可阅读Subbu的文章。
Suddo在博文中回顾了自己在Ebay基础架构演进的路程，得出结论认为构建云基础架构不应依赖暂态的抽象定义。什么叫做暂态抽象定义呢？就是以计算机角度进行的抽象，包括主机，磁盘，IP地址，主机名，定义为暂态的(比如虚机)，因为暂态抽象会导致难以从错误中恢复。
所有的IaaS都采用十年前的AWS的方式来工作，包含3个步骤：
1. 对自动化基础架构的抽象，包括计算，块存储，网络，均提供API进行相应操作；
2. 提供额外的服务用于监控，编排；
3. 让用户采用步骤1和2来处理他们自己应用的弹性，容错，从而打造整个自动化基础架构。
这种方式的缺点在于，即便有了1和2，步骤3的工作仍然是复杂的，只有很少用户和公司取得了成功。而大多数采用这种方式的用户都让他们的基础架构脆弱不堪，以至于容易得出云中架构并不成功的结论。
为什么会这样呢？为了让应用能够对来自暂态抽象层的错误更加健壮，用户需要监控错误，把每个应用以尽可能快的速度恢复。这并不是一个运维的问题，甚至也不是DevOps问题。这是个软件工程问题，如下图所示，称为PDMR循环：Provision->Deploy and configure->Monitor and detect->Remediate。
以上的闭环中，没有监控和恢复的步骤，当底层错误发生时，应用是无法恢复到期望的状态的。因此，只有那些对于云计算理解深刻，并且投入了大量的开发团队用于构建以上的步骤3所需要的软件的团队，才能在这些老的玩法上取得成功，最明显的例子比如Netflix。至于剩下的团队，他们只能梦想着美好的事情发生——比如计算，存储，网络都跟IaaS宣称的那样真成了共享资源池，可以随心所欲的使用——当然，这并没有发生，凡是仅仅在这么幻想的团队他们都没有在云上收获到他们想要的，反而掉进了大坑。更何况，许多开源的IaaS，比如OpenStack，连上述的步骤1，2都没有提供完全，就更不要说打造PDMR的完整闭环了。
这就是Suddo在Ebay的演进中收获的最大教训——如果仍以10年前的角度来架构云，会导致失败。
那么什么样的才是未来的云基础架构呢？相比于暂态抽象，Suddo提出了2点：
1. 持久的(Durable)。云基础架构可以构建在暂态抽象上(虚机)，但底层抽象需要是持久的，以便于快速从错误恢复。
2. 声明性的。抽象层的用户可以方便地声明他们所期望的状态，服务则试图让抽象快速达到该状态。
虚机，以及物理主机，它们既不是持久的，也不是Cloud Native的——容器也同样。但是，容器的集群，例如Kubernetes Pods集群，以及Mesos上由Marathon管理的容器集群，它们都是持久且Cloud Native的。什么是Cloud Native？就是你无需在IaaS层来完成PDMR闭环周期，你只需声明你所期望的，然后把整个PDMR循环都都交给云来完成。
持久的，声明性的Cloud Native基础架构，毫无疑问代表了云的未来，但这是在表明IaaS死了吗？并非如此，你仍然需要创建虚机，然后把云构建在其上。最终，IaaS将是非常薄的纯运维层，绝大多数人都不需要再去关心。
坦率说，Suddo对于云架构的定义很晦涩，暂态，持久，声明性，然而透过其定义，我们可以清晰地看到Ebay的教训带来的是什么启示，以及技术究竟如何演进和选择才是正确之道。NetflixOSS作为IaaS早期3步骤的成功实践者，也已经从今年起全面启用Mesos，无疑，这是向着Cloud Native又前进了一大步。
