# Zappos 的网站与 Amazon 集成后冻结了两年 > 原文： [http://highscalability.com/blog/2015/10/7/zapposs-website-frozen-for-two-years-as-it-integrates-with-a.html](http://highscalability.com/blog/2015/10/7/zapposs-website-frozen-for-two-years-as-it-integrates-with-a.html)  这是来自 [Roger Hodge](https://twitter.com/rogerdhodge) 在《新共和国》中写的精彩而深刻的文章中的一个有趣的掘金： [Zappos 进行了一项激进的实验，以终止我们所知的办公场所](http://www.newrepublic.com/article/122965/can-billion-dollar-corporation-zappos-be-self-organized)： > Zappos 的面向客户的网站在过去几年中基本上被冻结，而该公司将其后端系统迁移到 Amazon 的平台上，这是一个多年项目，称为 Supercloud。 Zappos 的一个证明是，他们在冻结的网站上仍然卖得很好，而世界上大多数其他地区都采用了跨多个平台持续部署和不断发展的模型。 亚马逊要求采取此举，否则 Zappos 这样的公司可能会对这种深度整合的隐含对[康韦定律](https://en.wikipedia.org/wiki/Conway%27s_law)敏感。 请记住，据报道 Facebook 正在保持 WhatsApp 和 Instagram [独立](http://techcrunch.com/2014/02/19/facebook-buying-whatsapp-for-16b-in-cash-and-stock-plus-3b-in-rsus/)。 停止世界计划必须意味着某些事情，不幸的是，我没有战略眼光来理解为什么会这样。 有什么想法吗？ 本文提供了有关此举的更多诱人细节： > 同时，将 Zappos 的整个 IT 基础架构迁移到亚马逊-这意味着要想出一种方法，将一套极为复杂的自定义软件程序移至每年 10 亿美元的电子商务网站上 全新的环境-继续。 **这项工作的难度几乎无法想象。** 想象一下，拿一百万平方钉并试图将其插入一百万个圆孔中，除非您甚至都不知道是否所有的孔都存在，或者孔可能位于何处，并且您必须协商访问这些孔的方式 与数十个不同的敌对软件工程师团队。 该项目已经消耗了 Zappos 的技术部门超过两年的时间，在此期间，Zappos 站点几乎是完全静态的。 这意味着**没有任何改进或创新，并且仅修复了最少的错误**。 > > 该项目的项目经理 Barry Van Beek 告诉我，他认为 Supercloud 是历史上最大的电子商务重组。 “以前没有人尝试过如此大规模。” 曾在 Zappos 待了八年的 Van Beek 说 **Supercloud 有大约 20 个不同的团队，包括承包商的 250 至 350 人，与 100 多个不同的 Amazon 团队合作。** 当他们开始时，他们不知道自己正在进入什么。 花了几个月的时间弄清楚了亚马逊方面的可用功能，并且在一年多的时间里，Van Beek 甚至不确定迁移在技术上是否可行。 但是，他说， **Supercloud 是亚马逊规定的目标**，他们别无选择。 所以他们想通了。 他说：“努力的程度几乎是难以理解的。” > > Van Beek 告诉我，他相信 Supercloud 可以完成，但他担心该报价造成的中断以及亚马逊方面的不可预见的延误会减缓其进展。 当 Zappos 确实完成迁移时，他希望技术部门能够将其注意力转移到电子商务领域的创新上，以解决诸如尺寸和装配问题之类的挑战。 **如果客户在订购之前更有可能达到理想的状态，则消除退货以及相关的进货和运输成本将提高利润。** 我同意这个项目是疯狂的，这就是为什么我永远不会建议这样做的原因。 我认为它们可以确定推动成功的关键业务流程（例如大约 50 个），并弄清楚如何使用现有的 Amazon 基础架构来实现它们。 然后进行一次大的丑陋转换。 失去的销售绝不会造成该项目成本的损失。 另一件事让我印象深刻……这与人们一直希望人们在其界面和所处理的功能中*希望*不断变化的信念形成强烈反差。 我从没想过对消费者如此，对 B2B 软件也是如此。 如果我是一个有钱的人，并且负责一家公开 B2C 公司，那么我会仔细研究这个示例-所有未花费的费用都将落在底线。 -XC 这样的项目只会在有钱烧钱的公司发生。 如果他们期望获得回报，我怀疑这种规模是否会平衡这十年。 听起来这似乎是 Bezos 的自我动机，而不是艰难的业务需求。 我想 Zappos 会以与 Tony Hsieh 处理整个公司到 Holacracy 的转换相同的方式对待他们的计算基础架构的转换就不足为奇了，也就是说，这是一个很大的突破。 尽管显然托尼不愿意像在网站上那样“冻结公司”，但他们却想办法。 我建议冻结网站以完成这种转换在很大程度上是想象力的失败。 即使他们现有的系统是单片的“一级”应用程序（就像亚马逊曾经的那样），也没有技术上的理由，他们不应该将其逐段转换到云平台上。 我的意思是，在现有代码中抛出“ if”语句以将某些服务调用的一部分发送到新系统，从而合理地安全地推出“转换后的”后端有多难？ “范贝克（Van Beek）甚至在技术上都不确定迁移是否可能”中出现的明显场面表明，也许他们选错了人。 不是“技术上可行的”吗？ 请。 我们在这里谈论的是在计算机上运行的代码，而不是光速旅行。 关于您关于 Instagram 的观点，我最近在 Facebook 上进行了大约 1 个小时的演讲，他们概述了将 Instagram 从 AWS 迁移到 Facebook 内部计算基础架构所采取的步骤，该功能远不及 AWS 那样丰富或灵活。 。 显然这不是一件容易的事，他们设法做到了不冻结甚至关闭 Instagram。 实际上，Instagram 已迁移到 FB 的基础设施 http://engineering.instagram.com/posts/1086762781352542/migrating-from-aws-to-fb/ “这证明了 Zappos 在冻结的网站上仍然能很好地销售产品，而世界上大多数其他地区都采用了跨多个平台的持续部署和不断发展的模型。” 我知道人们不敢得出另一个结论：大多数开发组织并没有增加底线，应该受到挑战。 有谁知道为什么亚马逊要求这种改变或要求改变什么？ 我很想知道他们为什么要迁移到亚马逊！ Zappos 在过去几年中失去了我作为客户的机会。 他们的网站在查找产品，评论，订单历史记录等方面不再具有竞争力。（尝试一下-例如，搜索已完全中断。）他们可能失去了大量客户，但由于困难而没有意识到 跟踪此指标。 像我这样的客户由于更好的选择而只是默默地退出使用他们的服务。 他们确实跟踪客户指标，相信我，我曾经是那里的开发人员。 这个举动并不太令人惊讶，但令人遗憾，这可能是他们在过去几年中大量迁移开发人员的原因。 我是将网站从 perl 更新到 Java 的团队的一部分。 我们真正接触的唯一一件事是基础数据库。 我们最终得到了一个更瘦的应用程序，该应用程序使用了更少的资源。 至于关于“添加'if'语句”的评论，那并不涵盖所有内容。 从 perl 到 Java 的迁移需要一些计划和协调。 那里最大的障碍是移动/镜像数据。 如果您每天要处理成千上万的订单，那么确保在迁移过程中获得正确的数据并非易事。 然后，您拥有了现在必须在两种体系结构上都可以使用的支持软件（当时全部由内部编写）。 哦，是的，然后您就有了与库存和订单管理数据进行通信的仓库处理程序，这些数据也必须在这两个系统之间都可以工作。 这将是一个很大的挑战。