所以我们更深的挖掘了一下，内部测试结果也非常喜人。实际上，在2012年初，我与Solomon Hykes谈了一次，我们当初想要更进一步的整合Dotcloud和Koding这两个平台。当时Dotcloud也着手采用LXC，几个月后，最终使用了基于LXC的Docker。

Docker是一个很棒并且很成功的产品，LXC也是相当有趣的技术。但是，当我们利用LXC来给数万用户提供开发环境的时候，事情并没有想象的那么顺利。问题不是出现在LXC和Docker技术本身，而是扩展性上。总的来说，Docker与LXC并没有像Xen这样的业务流程软件，所以Koding必须要有一个这样的。

让我们想象这样一个场景，你有个配置为 16GB/8CPU/1TB 的服务器，你基本上可以部署任意数量的容器。这里我们假设要部署100个，先部署其中的一个。如果它们不用于生产环境，它们将不会使用你的cpu和内存。我们曾用LXCs进行 CPU和内存限制（假设为C组）以确保这个容器不会堵塞整个主机。理论上这是可行的但在实践中，我们看到了–LXC的限制效果然并卵。这个容器产生的各种蛋疼的原因，然后导致在其他99个用户对该主机抱怨服务器性能差，也就是说这个容器影响到了其他容器。

此外，我们需要用代理软件将username.kd.io这个泛解析域写进去（白话：把这些域名分派给这些免费给虚拟机用户），否则我们需要自己写一个DNS协议和DNS服务器，这时就需要给那些容器分配公网IP，不过这是特殊情况，最新的DNS软件用了有几年了。同时，我们自己写SSH和FTP代理软件，让我们的用户通过主机名从外部连接到他们的容器。（我不讲细节了，你肯定不想自己写SSH或FTP代理服务器，然后部署和维护它们。）
 

除那以外，有100人在主机上使用那些文件，克隆git报告，随着时间地推移那些基于VM的LXC正在以GB级别增长。当这些用户离开他们的会话时，我们高效地（且廉价地）存储所有这些以GB计的文件。因此，我们需要一个网络文件系统，让容器从一个宿主机转移到另一个宿主机。总的来说，我们的用户文件已经超过了PB级别。我们评估过GlusterFS和其他一些网络文件系统，还是选择了CEPH作为我们的网络文件系统。它很好地解决了我们的问题，因为它允许你直接将一个文件系统挂载到你的容器。CEPH是一个伟大的软件，不过，我们曾经挂载了超过2000个根驱动器，这导致的结果是我们不能预测会在哪里出现问题。我在这里重申，这也不是CEPH的问题，这是伸缩性问题。你的服务器已经将I/O耗尽，当你的网络线缆不能再承载任何数据时，你再尝试挂载新的驱动器，TCP包已经没有更多的士兵去冲击你的网卡出入口了。这样，所有的主机都会失效，因为你的存储已经不能用了。

所有这一切发生在一个为了消除“托管”变量的托管服务中，当时，我们确定把我们的服务部署到数据中心并通过直接的网络进行连接。我们最终的架构是部署在超过2TB RAM和一个PB级存储的OpenStack上。但是奇迹没有持续，当Koding迎来50000人的峰值请求时（在一个VM上），我们部署的网络架构不能随着需求相应的扩展。

我们的架构在给定的任何时刻，都有超过64台非常强大的主机（可供使用），他们中2-3台被用来做比特币矿机，或者出现fork轰炸和内核报急，因为我们不能控制某个用户对于系统的用途。作为一个不错的技术CEO，已经针对Koding写出了第一个基于云主机的openvz，并在2010年获取了资金，并使用Go编写了我们的后端，我可以告诉你这个系统的复杂性在这一点上已经超出我的理解范畴。对这个系统发生的大量事件持续地进行操作不是任何单一Koding的团队成员所能完成的。当问题发生，它通常需要3-4个人在一起合起来处理。我们的系统管理员所说的话没有人能理解，我们会谈及内核补丁，aufs，tcp dumps，更好的路由，网络交换机，数据中心，他们之间的连接，OpenStack的问题，咒骂我们买的Fusion-io驱动，因为很明显SSD是不够快（真实的故事）的。增加复杂性，我们的团队成员分布在全球，一个简单的问题也会需要那些在新西兰，伊斯坦布尔，柏林和旧金山的员工间的合作。

我们只能另起炉灶了,而且我们逐渐开始意识到Koding已经要变成一个基础架构公司了。是的，我们本可以解决如何精密安排那些LXC的问题，如何分配公共IP给每一个LXC的问题，把它们从一个容器移动到另一个容器，等等等等的问题。我们本可以和LXC核心团队进行更多的合作来减少安全的问题——然而，那些问题早已经被Amazon解决了，并且他们管这个叫做EC2，EBS，S3，Route53，Cloudwatch，Snapshots等等。我们在重复造轮子，就是为了拥有LXC。然而我们的用户只是要求一个稳定的可以工作的虚拟机而已，可是如果重复造那些所有的轮子的话，我们在破坏我们用户的工作流程。这个决定另一个很重要的部分是基于LXC提供的容器是无法提供一个美好的虚拟机体验的事实。比方说，在LXC容器内部是无法很好的运行另外一个容器的（比如说Docker）。此外的，在我们公司的新策略中，我们的虚拟机是需要真实的和其他虚拟机独立的，它们只需要对自己负责并且主机系统和虚拟机之间是存在真实的隔离的。

我们决定停止重复造轮子。这种行为在伤害我们并且让我们远离我们真正应该为用户做的事情——那就是提供他们能够亲手体验到的最好的开发环境。

简单来说，直到某一天一个公司会提供LXC而不是Xen虚拟机，并且那个公司可以保证他可以确保安全地和靠谱地处理万级别的并发时，Koding就将会使用虚拟机。目前，可以做到这一点的公司恰好就是Amazon。他们实在太棒了。我们刚刚在九月增加了150,000个虚拟机通过99.5%的运行时间。这个运行时间对我们的用户来说是真实的而对Koding来说更是超现实的。这些是我们使用LXC永远也可能不会达到甚至说是接近的一个状态。

Koding的任务是保证开发者能够拥有可依赖的开发环境，所有的用户并不关心底层运行的机制到底是什么（好吧，我知道你们有些人可能会想知道）。同时，通过Docker容器的不可思议的开始，我们使用亚马逊虚拟机的决定，使得我们能够在我们提供的虚拟机内部使用Docker，这些都是在基于LXC的虚拟机中不可能（容易地）达到的。

这个就是我们决定使用亚马逊虚拟机而不是LXC的故事。希望它能解决你的问题。欢迎交流。