LinkedIn abandonou plano de migrar para a nuvem Microsoft Azure

Artigo original ↗ Discussão no Hacker News ↗

O LinkedIn supostamente arquivou um esforço de vários anos para migrar sua infraestrutura fortemente personalizada e on-premises para a nuvem Azure da Microsoft, apesar de pertencer à Microsoft. Os comentaristas argumentam que migrações de cloud do tipo “lift and shift” frequentemente fracassam em grande escala, pois arquiteturas legadas, forte acoplamento a plataformas internas e volumes massivos de dados tornam a refatoração cara e arriscada. A discussão se amplia para uma crítica à complexidade do Azure, ao custo e ao ROI reais da nuvem pública para empresas maduras e ao fato de que lock-in de fornecedor e cultura organizacional muitas vezes importam mais do que o provedor de cloud escolhido.

Experiência e treinamento em Azure

  • Vários profissionais relatam que o Azure parece “descoordenado”, com serviços fragmentados e certificações e trilhas de treinamento em constante mudança.
  • Um arquiteto gosta do Azure, mas diz que muitas soluções acabam se reduzindo a conectar vários serviços sobrepostos, sem padrões claros.
  • Algumas organizações estão ativamente migrando para fora do Azure e voltando para ambiente on-premises por causa da complexidade e da instabilidade percebidas.

AKS e serviços do Azure

  • Vários comentaristas desencorajam fortemente o uso do Azure Kubernetes Service (AKS), citando instabilidade, problemas operacionais e incidentes dolorosos em produção; um deles aponta para um blog sobre os “horrors of AKS” e afirma que falhas recentes semelhantes ocorreram.
  • Outros contra-argumentam dizendo que a Microsoft executa grandes cargas de trabalho (por exemplo, Microsoft 365) no AKS; os céticos observam que a Microsoft não vai divulgar problemas internos.
  • O Azure Event Hubs como substituto do Kafka é criticado por peculiaridades de protocolo, lacunas de recursos, limites de escalabilidade e comportamento de “embrace/extend”.
  • Algumas ofertas do Azure (Service Fabric, Postgres hospedado) são descritas como historicamente fracas ou difíceis de usar.

Arquitetura e tentativa de migração do LinkedIn

  • O LinkedIn roda em sua própria “cloud” interna com abstrações personalizadas (por exemplo, Rest.li, balanceamento de carga no lado do cliente, clusters Hadoop/HDFS muito grandes).
  • Funcionários afirmam que não houve um simples lift-and-shift; em vez disso, houve uma reconciliação complexa entre a stack do LinkedIn e os primitivos do Azure.
  • Em escala de exabytes e com compute+storage fortemente acoplados, mapear para o modelo desacoplado do Azure e seus serviços (por exemplo, namespaces do Data Lake) parecia extremamente caro.
  • Alguns insiders descrevem a stack do LinkedIn como fortemente personalizada, mas eficaz; outros a chamam de superengenheirada e difícil de পরিবর্তar.
  • A migração para o Azure (Blueshift) consumiu anos e grandes orçamentos antes de ser cancelada; alguns elogiam o corte das perdas, outros veem isso como clara má gestão.

“Lift and shift” vs. cloud-native

  • “Lift and shift” é definido como mover cargas de trabalho existentes para VMs na nuvem com refatoração mínima; muitos o chamam de termo de vendas que esconde a complexidade real.
  • O consenso: raramente entrega os benefícios prometidos e muitas vezes acaba mais caro do que o projetado.
  • Sistemas grandes e de longa vida acumulam casos extremos, suposições de latência e dependências entre equipes, tornando refatorações e migrações ao vivo extremamente difíceis.

Economia da nuvem vs. on-prem

  • Há forte discordância sobre custo:
    • Alguns argumentam que a nuvem pode reduzir capex, equipe e atrasos de provisionamento, além de ajudar em cargas de trabalho com picos.
    • Outros dizem que, para cargas de trabalho grandes e estáveis, o compute na nuvem é muito mais caro do que servidores em colo/gerenciados bem operados.
  • Em particular, o Azure é reportado como oferecendo descontos muito grandes para empresas (muitas vezes ~50% sobre a tabela), o que influencia fortemente as decisões executivas.
  • Várias organizações agora estão reconsiderando a nuvem pública (especialmente o Azure) devido ao aumento de preços e à complexidade operacional, enquanto outras estão migrando para a nuvem para focar nas competências centrais.

Lock-in de fornecedor e infraestrutura personalizada

  • Mover-se entre clouds geralmente exige reescrever infraestrutura como código e substituir serviços gerenciados proprietários; “equivalente por equivalente” é raro.
  • Plataformas internas personalizadas podem ser eficientes em escala, mas tornam-se âncoras de migração; uma vez que um padrão comunitário emerge, continuar investindo em equivalentes caseiros é arriscado.

Dogfooding e comparações entre provedores de cloud

  • Alguns elogiam a AWS por forçar agressivamente as equipes internas a adotar a AWS cedo, argumentando que essa pressão melhorou os produtos da AWS.
  • Outros afirmam que a Microsoft também faz amplo dogfooding do Azure (Teams, Office 365, sistemas internos), mas aquisições como LinkedIn e GitHub são exceções parciais devido a stacks grandes e especializadas já existentes.
  • O dogfooding interno do Google Cloud é mencionado, mas continua incerto; alguns afirmam que o Google não usa amplamente o GCP para produtos centrais, outros dizem que ele é usado para certas cargas de trabalho.