LinkedIn ने Microsoft Azure क्लाउड पर माइग्रेट करने की योजना को स्थगित किया

मूल लेख ↗ Hacker News चर्चा ↗

बताया जाता है कि LinkedIn ने अपनी भारी कस्टमाइज़्ड, ऑन-प्रिमाइसेज़ infrastructure को Microsoft की Azure cloud पर माइग्रेट करने के कई साल लंबे प्रयास को स्थगित कर दिया है, जबकि वह Microsoft के स्वामित्व में है। टिप्पणीकारों का तर्क है कि “lift and shift” cloud migrations बड़े पैमाने पर अक्सर विफल हो जाती हैं, क्योंकि legacy architectures, in-house platforms के साथ tight coupling, और massive data volumes refactoring को महँगा और जोखिम भरा बना देते हैं। यह चर्चा Azure की जटिलता, mature enterprises के लिए public cloud की वास्तविक लागत और ROI, और vendor lock-in तथा organizational culture के प्रभाव पर एक व्यापक आलोचना में बदल जाती है, जहाँ चुने गए cloud provider से अधिक महत्व अक्सर इन्हीं का होता है.

Azure अनुभव और प्रशिक्षण

  • कई प्रैक्टिशनर बताते हैं कि Azure “असमन्वित” लगता है, जिसमें सेवाएँ बिखरी हुई हैं और प्रमाणपत्र तथा प्रशिक्षण पथ लगातार बदलते रहते हैं।
  • एक आर्किटेक्ट को Azure पसंद है, लेकिन वह कहता है कि कई समाधान कई ओवरलैपिंग सेवाओं को जोड़कर काम करने लगते हैं, बिना किसी स्पष्ट पैटर्न के।
  • कुछ संगठन perceived जटिलता और अस्थिरता के कारण Azure से वापस ऑन-प्रिमाइसेज़ की ओर सक्रिय रूप से माइग्रेट कर रहे हैं।

AKS और Azure सेवाएँ

  • कई टिप्पणीकार Azure Kubernetes Service (AKS) का उपयोग करने से कड़ा हतोत्साहित करते हैं, अस्थिरता, परिचालन समस्याओं, और दर्दनाक प्रोडक्शन घटनाओं का हवाला देते हुए; एक व्यक्ति “horrors of AKS” ब्लॉग का लिंक देता है और हाल की इसी तरह की विफलताओं का दावा करता है।
  • अन्य लोग जवाब देते हैं कि Microsoft स्वयं बड़े वर्कलोड्स (जैसे Microsoft 365) को AKS पर चलाता है; संदेहवादी नोट करते हैं कि Microsoft अपनी आंतरिक समस्याएँ प्रचारित नहीं करेगा।
  • Kafka के विकल्प के रूप में Azure Event Hubs की आलोचना की जाती है, प्रोटोकॉल की विचित्रताओं, फीचर गैप्स, स्केलिंग सीमाओं, और “embrace/extend” व्यवहार के लिए।
  • कुछ Azure पेशकशों (Service Fabric, hosted Postgres) को ऐतिहासिक रूप से कमजोर या उनके साथ काम करना कठिन बताया जाता है।

LinkedIn की आर्किटेक्चर और माइग्रेशन प्रयास

  • LinkedIn अपनी स्वयं की आंतरिक “cloud” पर चलता है, जिसमें कस्टम abstraction हैं (जैसे Rest.li, client-side load balancing, बहुत बड़े Hadoop/HDFS क्लस्टर्स)।
  • कर्मचारी बताते हैं कि कोई सरल lift-and-shift नहीं था; इसके बजाय, LinkedIn के stack और Azure के primitives के बीच जटिल reconciliation करनी पड़ी।
  • exabyte scale पर और tightly coupled compute+storage के साथ, Azure के disaggregated model और services (जैसे Data Lake namespaces) में mapping बेहद महँगी दिखी।
  • कुछ अंदरूनी लोग LinkedIn stack को भारी कस्टम लेकिन प्रभावी बताते हैं; अन्य इसे over-engineered और बदलने में कठिन कहते हैं।
  • Azure migration (Blueshift) वर्षों और बड़े बजट तक चली, फिर रद्द कर दी गई; कुछ लोग घाटा काटने की प्रशंसा करते हैं, जबकि अन्य इसे स्पष्ट mismanagement मानते हैं।

“Lift and Shift” बनाम Cloud-Native

  • “Lift and shift” को existing workloads को cloud VMs पर न्यूनतम refactoring के साथ ले जाना परिभाषित किया गया है; कई लोग इसे एक sales term कहते हैं जो वास्तविक जटिलता को छुपाता है।
  • आम सहमति: यह शायद ही कभी वादे किए गए लाभ देता है और अक्सर अनुमान से अधिक महँगा हो जाता है।
  • बड़े, लंबे समय तक चलने वाले सिस्टम edge cases, latency assumptions, और cross-team dependencies जमा कर लेते हैं, जिससे refactors और live migrations बेहद कठिन हो जाते हैं।

Cloud बनाम On-Prem Economics

  • लागत पर तीव्र असहमति है:
    • कुछ का तर्क है कि cloud capex, staffing, और provisioning delays को कम कर सकता है, और spiky workloads में मदद करता है।
    • अन्य कहते हैं कि बड़े, स्थिर workloads के लिए cloud compute अच्छी तरह चलाए गए colo/managed servers की तुलना में बहुत महँगा है।
  • विशेष रूप से Azure के बारे में बताया जाता है कि वह बहुत बड़े enterprise discounts देता है (अक्सर सूची मूल्य पर ~50% छूट), जो executive निर्णयों को भारी रूप से प्रभावित करता है।
  • कई संगठन अब rising prices और operational complexity के कारण public cloud (विशेषकर Azure) पर फिर से विचार कर रहे हैं, जबकि अन्य core competencies पर ध्यान केंद्रित करने के लिए cloud में जा रहे हैं।

Vendor Lock-In और Custom Infrastructure

  • clouds के बीच जाना आमतौर पर infrastructure-as-code को फिर से लिखने और proprietary managed services को बदलने की मांग करता है; “like for like” दुर्लभ है।
  • कस्टम internal platforms scale पर efficient हो सकते हैं, लेकिन migration anchors बन जाते हैं; एक बार community standard उभरने के बाद, homegrown equivalents में निवेश जारी रखना जोखिम भरा होता है।

Dogfooding और Cloud Provider Comparisons

  • कुछ लोग AWS की प्रशंसा करते हैं कि उसने internal teams को शुरू से ही AWS पर जाने के लिए आक्रामक रूप से मजबूर किया, और तर्क देते हैं कि इस दबाव ने AWS products में सुधार किया।
  • अन्य कहते हैं कि Microsoft भी Azure का भारी dogfooding करता है (Teams, Office 365, internal systems), लेकिन LinkedIn और GitHub जैसे acquisitions मौजूदा बड़े, specialized stacks के कारण आंशिक अपवाद हैं।
  • Google Cloud के internal dogfooding का उल्लेख किया गया है, लेकिन यह अस्पष्ट बना हुआ है; कुछ का दावा है कि Google core products के लिए व्यापक रूप से GCP का उपयोग नहीं करता, जबकि अन्य कहते हैं कि यह कुछ workloads के लिए उपयोग होता है।