LinkedIn archivó el plan de migrar a la nube de Microsoft Azure

Artículo original ↗ Discusión en Hacker News ↗

LinkedIn supuestamente ha archivado un esfuerzo de varios años para migrar su infraestructura fuertemente personalizada, on-premises, a la nube Azure de Microsoft, pese a pertenecer a Microsoft. Los comentaristas sostienen que las migraciones cloud de “lift and shift” suelen fracasar a gran escala, ya que las arquitecturas heredadas, el acoplamiento estrecho a plataformas internas y los enormes volúmenes de datos hacen que refactorizar sea costoso y arriesgado. El hilo se amplía hacia una crítica a la complejidad de Azure, al coste real y el ROI de la nube pública para empresas maduras, y a cómo el vendor lock-in y la cultura organizacional suelen importar más que el proveedor de nube elegido.

Experiencia y formación en Azure

  • Varios practicantes informan que Azure se percibe como “descoordinado”, con servicios fragmentados y certificaciones y trayectorias de formación que cambian constantemente.
  • A un arquitecto le gusta Azure, pero dice que muchas soluciones terminan convirtiéndose en conectar varios servicios superpuestos sin patrones claros.
  • Algunas organizaciones están migrando activamente desde Azure de vuelta a on‑prem debido a la complejidad e inestabilidad percibidas.

AKS y servicios de Azure

  • Varios comentaristas desaconsejan firmemente usar Azure Kubernetes Service (AKS), citando inestabilidad, problemas operativos e incidentes dolorosos en producción; uno enlaza a un blog sobre los “horrors of AKS” y afirma fallos similares recientes.
  • Otros responden que Microsoft ejecuta cargas de trabajo importantes (p. ej., Microsoft 365) sobre AKS; los escépticos señalan que Microsoft no publicitará problemas internos.
  • Azure Event Hubs como reemplazo de Kafka es criticado por peculiaridades del protocolo, carencias de funciones, límites de escalado y comportamiento de “embrace/extend”.
  • Algunas ofertas de Azure (Service Fabric, Postgres gestionado) se describen como históricamente débiles o difíciles de trabajar.

La arquitectura de LinkedIn y el intento de migración

  • LinkedIn funciona sobre su propia “nube” interna con abstracciones personalizadas (p. ej., Rest.li, balanceo de carga del lado del cliente, clústeres Hadoop/HDFS muy grandes).
  • Empleados afirman que no hubo un simple lift-and-shift; en su lugar, hubo una reconciliación compleja entre la pila de LinkedIn y los primitivos de Azure.
  • A escala de exabytes y con compute+storage fuertemente acoplados, mapear al modelo desacoplado y a los servicios de Azure (p. ej., espacios de nombres de Data Lake) parecía extremadamente costoso.
  • Algunos insiders describen la pila de LinkedIn como muy personalizada pero eficaz; otros la califican de sobredimensionada y difícil de cambiar.
  • La migración a Azure (Blueshift) consumió años y presupuestos enormes antes de cancelarse; algunos elogian haber limitado pérdidas, otros lo ven como una clara mala gestión.

“Lift and shift” frente a cloud-native

  • “Lift and shift” se define como mover cargas de trabajo existentes a máquinas virtuales en la nube con refactorización mínima; muchos lo consideran un término de venta que oculta la complejidad real.
  • El consenso: rara vez ofrece los beneficios prometidos y a menudo termina siendo más caro de lo previsto.
  • Los sistemas grandes y de larga vida acumulan casos límite, supuestos de latencia y dependencias entre equipos, lo que hace que los refactors y las migraciones en vivo sean extremadamente difíciles.

Economía de la nube frente a on-prem

  • Hay un fuerte desacuerdo sobre el coste:
    • Algunos argumentan que la nube puede reducir capex, personal y retrasos de aprovisionamiento, y ayuda con cargas de trabajo con picos.
    • Otros dicen que, para cargas de trabajo considerables y estables, el cómputo en la nube es mucho más caro que servidores bien gestionados en colo/managed servers.
  • En particular, se informa que Azure ofrece descuentos empresariales muy grandes (a menudo ~50% sobre la lista), lo que influye enormemente en las decisiones ejecutivas.
  • Varias organizaciones están reconsiderando la nube pública (especialmente Azure) debido al aumento de precios y la complejidad operativa, mientras que otras están moviéndose hacia la nube para centrarse en sus competencias principales.

Vendor lock-in e infraestructura personalizada

  • Pasar de una nube a otra suele requerir reescribir infraestructura como código y reemplazar servicios gestionados propietarios; el “like for like” es raro.
  • Las plataformas internas personalizadas pueden ser eficientes a escala, pero se convierten en anclas de migración; una vez que emerge un estándar comunitario, seguir invirtiendo en equivalentes hechos en casa es arriesgado.

Dogfooding y comparaciones entre proveedores de nube

  • Algunos elogian a AWS por forzar agresivamente a los equipos internos a usar AWS desde temprano, argumentando que esa presión mejoró los productos de AWS.
  • Otros afirman que Microsoft también hace un fuerte dogfooding de Azure (Teams, Office 365, sistemas internos), pero adquisiciones como LinkedIn y GitHub son excepciones parciales debido a stacks grandes y especializados ya existentes.
  • Se menciona el dogfooding interno de Google Cloud, pero sigue sin estar claro; algunos sostienen que Google no usa GCP de forma amplia para productos principales, otros dicen que se usa para ciertas cargas de trabajo.