LinkedIn 搁置迁移到 Microsoft Azure 云的计划

Azure 经验与培训

• 多位实践者表示，Azure 给人的感觉是“缺乏协调”，服务碎片化，认证和培训路径也不断变化。
• 一位架构师喜欢 Azure，但表示许多解决方案最后都变成了把多个相互重叠的服务连在一起，没有清晰的模式。
• 一些组织正在积极从 Azure 迁回本地部署，原因是认为其复杂且不稳定。

AKS 和 Azure 服务

• 多位评论者强烈不建议使用 Azure Kubernetes Service（AKS），理由包括不稳定、运维问题以及痛苦的生产事故；其中一人链接到一篇关于“AKS 恐怖经历”的博客，并声称最近也有类似故障。
• 也有人反驳称微软把重大工作负载（例如 Microsoft 365）运行在 AKS 上；怀疑者则指出微软不会宣传内部问题。
• Azure Event Hubs 作为 Kafka 替代品受到批评，原因包括协议怪癖、功能缺口、扩展限制以及“拥抱/扩展”式行为。
• 一些 Azure 产品（如 Service Fabric、托管 Postgres）被描述为历史上较弱或难以使用。

LinkedIn 的架构与迁移尝试

• LinkedIn 运行在其自有的内部“云”上，采用定制抽象层（例如 Rest.li、客户端负载均衡、超大规模 Hadoop/HDFS 集群）。
• 员工表示，这里没有简单的原样迁移；相反，LinkedIn 的技术栈与 Azure 的基础原语之间需要进行复杂的协调和对接。
• 在 EB 级规模以及计算与存储高度耦合的情况下，将其映射到 Azure 的解耦模型和服务（例如 Data Lake 命名空间）看起来代价极高。
• 一些内部人士把 LinkedIn 的技术栈描述为高度定制但有效；另一些则称其过度设计且难以变更。
• Azure 迁移项目（Blueshift）耗费了多年和大量预算，最终被取消；有人称赞这是及时止损，也有人认为这显然是管理失误。

“原样迁移” vs 云原生

• “原样迁移”被定义为几乎不做重构就把现有工作负载迁移到云端虚拟机；许多人认为这只是一个销售术语，掩盖了真实复杂性。
• 普遍共识是：它很少能兑现承诺的好处，而且往往比最初预估的更昂贵。
• 大型、长期运行的系统会积累边缘情况、延迟假设以及跨团队依赖，使得重构和在线迁移极其困难。

云端 vs 本地部署的经济性

• 成本上存在强烈分歧：
  • 有人认为云可以减少资本支出、人员配置和资源开通延迟，并有利于应对突发流量。
  • 也有人表示，对于规模较大且负载稳定的工作负载，云计算的成本远高于管理良好的托管机柜/托管服务器。
• 尤其是 Azure，据说会给超大企业非常大的折扣（通常约为标价的 50%），这对高层决策影响很大。
• 一些组织现在由于价格上涨和运维复杂性，正在重新考虑公有云（尤其是 Azure）；另一些组织则正在迁入云端，以便专注于核心竞争力。

供应商锁定与自研基础设施

• 在不同云之间迁移通常需要重写基础设施即代码，并替换专有托管服务；“一模一样”的迁移很少见。
• 自研内部平台在大规模下可能高效，但也会成为迁移锚点；一旦社区标准出现，继续投资自研替代方案就会有风险。

Dogfooding 与云厂商比较

• 有人称赞 AWS 早期就强力推动内部团队使用 AWS，认为这种压力改进了 AWS 产品。
• 也有人表示微软同样大规模地 dogfood Azure（Teams、Office 365、内部系统），但像 LinkedIn 和 GitHub 这样的收购案由于已有庞大且专业化的技术栈，因此是部分例外。
• 还提到了 Google Cloud 的内部 dogfooding，但情况仍不明确；有人声称 Google 并未广泛把 GCP 用于核心产品，也有人说它用于某些工作负载。