Twilio的作者介绍在4月21日亚马逊Web服务宕机中其系统并没有被影响。他们涉及的云解决方案基于通过结合内部运营服务到以复制方式在多个服务器上部署，避免单一点失败。“通过创建由单一主机组成的简单服务，而不是多个从属主机，从而在主机宕机的时候创建可以存活的复制服务实例。”如果一个服务器宕机，同样的服务在另一个服务器上是可用的。这种基于复制的模型九十年代在Novel的 NetWare中就为人所知。

　　“例如，如果我们有一个应用，由业务逻辑组件A、B、C组成，每一个必须在单独的主机上运作，我们可以构成服务组（A，B，C），（A，B，C）……或者我们创建组件池（A,A……），（B,B……），（C,C……）。通过构架（A，B，C），单一的机器宕机导致整个系统组的损失。通过分解资源为独立的池，单一主机宕机仅仅影响单一主机的功能价值损失。”

　　尽管收集服务群得技巧看起来简单有效，但是我并不这样认为。我的怀疑来自大型企业的经验以及企业的面向服务解决方案：

　　(1)理应交互的服务属于不同的业务所有者；

　　(2)交互性品质的特定所有者很容易识别或者工作的志愿者，这里云可能是理想的第三方。

　　因此，难点在于：如果你是服务A的所有者，我是服务B的所有者，我凭什么在没有你的允许的情况下创建（A，B）服务组？如果你不同意我的组建或者就是去度假了不能及时响应我的请求，该怎么办？最后，在SOA环境中，我们不知道下一个可能需要的服务组合是什么，而且要不断地为新的组合重新部署服务，这样看来也许不是个好办法。

　　基于服务组的解决方案的有效性是有问题的。另一个事情是部署同样的服务的冗余。在业务运营中的任务会导致服务冗余，可以明确地表示如下：任何业务组织必须有数个方法/手段来调用和执行任何关键（极其重要的）业务功能。这个任务也是我们所熟知的“业务连续性”原则。可能有很多种不同的方法来创建这种连续性，冗余是其一。冗余可以通过复制获得，或者通过中介获得，这个中介为连续性增加了另一个有用的方面，即“不要把所有鸡蛋放在同一个篮子里。”

　　服务冗余和应用冗余的区别在于后者通常被理解为复制功能，不仅仅是多个应用的不同实施，还被不同的消费者不同情况地使用。服务冗余意味着冗长的访问同一种功能的同一种实施。

　　不论如何，Twilio还是证明了服务冗余辉煌的业务价值！