LinkedIn shelved plan to migrate to Microsoft Azure cloud

Original Article ↗ Hacker News Discussion ↗

LinkedIn has reportedly shelved a multi‑year effort to migrate its heavily customized, on‑premises infrastructure to Microsoft’s Azure cloud, despite being owned by Microsoft. Commenters argue that “lift and shift” cloud migrations routinely falter at large scale, as legacy architectures, tight coupling to in‑house platforms, and massive data volumes make refactoring expensive and risky. The thread broadens into a critique of Azure’s complexity, the true cost and ROI of public cloud for mature enterprises, and how vendor lock‑in and organizational culture often matter more than the specific cloud provider chosen.

Azure Experience and Training

  • Several practitioners report Azure feels “uncoordinated,” with fragmented services and constantly changing certifications and training paths.
  • One architect likes Azure but says many solutions devolve into wiring multiple overlapping services with no clear patterns.
  • Some organizations are actively migrating off Azure back to on‑prem due to perceived complexity and instability.

AKS and Azure Services

  • Multiple commenters strongly discourage using Azure Kubernetes Service (AKS), citing instability, operational issues, and painful production incidents; one links to a “horrors of AKS” blog and claims recent similar failures.
  • Others counter that Microsoft runs major workloads (e.g., Microsoft 365) on AKS; skeptics note Microsoft won’t advertise internal problems.
  • Azure Event Hubs as a Kafka replacement is criticized for protocol quirks, feature gaps, scaling limits, and “embrace/extend” behavior.
  • Some Azure offerings (Service Fabric, hosted Postgres) are described as historically weak or hard to work with.

LinkedIn’s Architecture and Migration Attempt

  • LinkedIn runs on its own internal “cloud” with custom abstractions (e.g., Rest.li, client‑side load balancing, very large Hadoop/HDFS clusters).
  • Employees state there was no simple lift‑and‑shift; instead, there was complex reconciliation between LinkedIn’s stack and Azure’s primitives.
  • At exabyte scale and with tightly coupled compute+storage, mapping to Azure’s disaggregated model and services (e.g., Data Lake namespaces) looked extremely costly.
  • Some insiders describe the LinkedIn stack as heavily custom but effective; others call it over‑engineered and hard to change.
  • The Azure migration (Blueshift) consumed years and large budgets before being cancelled; some praise cutting losses, others see it as clear mismanagement.

“Lift and Shift” vs Cloud-Native

  • “Lift and shift” is defined as moving existing workloads to cloud VMs with minimal refactoring; many call it a sales term that hides real complexity.
  • Consensus: it rarely delivers promised benefits and often becomes more expensive than projected.
  • Large, long‑lived systems accumulate edge cases, latency assumptions, and cross‑team dependencies, making refactors and live migrations extremely hard.

Cloud vs On-Prem Economics

  • Strong disagreement on cost:
    • Some argue cloud can reduce capex, staffing, and provisioning delays, and helps with spiky workloads.
    • Others say for sizeable, steady workloads, cloud compute is far more expensive than well‑run colo/managed servers.
  • Azure in particular is reported to give very large enterprise discounts (often ~50% off list), which heavily influences executive decisions.
  • Several organizations are now reconsidering public cloud (especially Azure) due to rising prices and operational complexity, while others are moving into cloud to focus on core competencies.

Vendor Lock-In and Custom Infrastructure

  • Moving between clouds usually requires rewriting infrastructure-as-code and replacing proprietary managed services; “like for like” is rare.
  • Custom internal platforms can be efficient at scale but become migration anchors; once a community standard emerges, continuing to invest in homegrown equivalents is risky.

Dogfooding and Cloud Provider Comparisons

  • Some praise AWS for aggressively forcing internal teams onto AWS early, arguing this pressure improved AWS products.
  • Others state Microsoft also heavily dogfoods Azure (Teams, Office 365, internal systems), but acquisitions like LinkedIn and GitHub are partial exceptions due to existing large, specialized stacks.
  • Google Cloud’s internal dogfooding is mentioned but remains unclear; some claim Google doesn’t broadly use GCP for core products, others say it’s used for certain workloads.