Figma ने 12 महीनों के भीतर K8s पर माइग्रेट कैसे किया

 (figma.com)
1 पॉइंट द्वारा GN⁺ 2024-08-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Figma ने अपनी पहले से containerized core services को ECS से EKS-आधारित Kubernetes पर ले जाते हुए, downtime के बिना long-term platform limitations कम करने वाला migration लक्ष्य बनाया
  • ECS में StatefulSets की अनुपस्थिति, Helm chart-आधारित OSS चलाने में कठिनाई, और node isolation की सीमाएं बड़ी थीं; Kubernetes ने CNCF ecosystem और Keda·Karpenter·Istio जैसे विकल्प खोले
  • Migration का scope service execution, deployment और tool abstractions को बनाए रखते हुए केवल orchestration बदलने तक सीमित किया गया; Bazel-आधारित service definitions और 3 EKS clusters की configuration शुरुआती scope में शामिल थीं
  • Transition के दौरान load testing, Weighted DNS-आधारित gradual traffic migration, real services का early migration, raw YAML को छिपाना, और service owners के साथ collaboration के जरिए rollback की संभावना सुनिश्चित की गई
  • जनवरी 2024 तक highest-priority services में से अधिकांश EKS पर migrate हो चुकी थीं, और over-provisioning cost reduction, reliability improvement और developer experience improvements हासिल करने के बाद logging, auto scaling और Graviton migration पर काम जारी है

ECS से Kubernetes पर जाने की वजह

  • 2023 की शुरुआत तक Figma पहले से ही अपनी सभी services को containers के रूप में चला रहा था, और orchestration platform के तौर पर AWS Elastic Container Service(ECS) इस्तेमाल कर रहा था
  • Next-generation compute platform की समीक्षा करते समय, उन्होंने माना कि ECS के ऊपर आगे बनाते रहना long term में इच्छित features बनाना मुश्किल कर देगा
  • Figma हजारों microservices चलाने वाली कंपनी नहीं थी, इसलिए Kubernetes migration का scope व्यावहारिक रूप से manage किया जा सकता था
    • Isolation या performance के कारण नई service की जरूरत पड़ सकती है, लेकिन core services basic modularization और traffic isolation देती हैं
    • नए products भी अक्सर नई service बनाने के बजाय existing core services के अंदर logic जोड़कर support किए जाते हैं

ECS में जिन capabilities की कमी थी

  • ECS Kubernetes के StatefulSets को support नहीं करता, इसलिए etcd जैसे strongly consistent consensus data store को चलाना tricky था
    • Figma ने etcd container startup के समय cluster membership को dynamically update करने वाले custom code से workaround किया
    • यह तरीका fragile और maintain करना मुश्किल था, जबकि Kubernetes में StatefulSets की stateful network allocation का इस्तेमाल आम है
  • ECS में Helm charts से define किए गए service bundles चलाना मुश्किल था
    • कई teams Temporal जैसे OSS software चलाना चाहती थीं, लेकिन ECS में हर service को Terraform definitions में manually port करना पड़ता था
  • ECS on EC2 में problematic single EC2 machine को gracefully terminate करना भी cumbersome था
    • EKS में खराब node को cordon करने पर API server termination procedure का सम्मान करते हुए Pods को दूसरी machines पर move कर सकता है

CNCF ecosystem और platform choice

  • ECS का उपयोग जारी रखने पर Cloud Native Computing Foundation(CNCF) ecosystem की open-source technologies का लाभ उठाना मुश्किल था
  • Auto scaling next-generation compute platform के लिए एक अहम concern था
    • उस समय Figma containerized services पर auto scaling लागू नहीं कर रहा था
    • रात और weekend जैसे low-traffic hours में भी peak load संभालने लायक services provision की जाती थीं, जिससे unnecessary cost आती थी
    • Kubernetes ecosystem का Keda CPU utilization के अलावा AWS SQS queue length और Datadog custom metrics के आधार पर scaling support करता है
  • Service mesh की भी long term में जरूरत पड़ सकती थी
    • Existing service-to-service traffic AWS Application Load Balancers(ALB) और Network Load Balancers(NLB) से route होता था
    • NLB को नए targets register करने और पुराने targets remove करने में कुछ minutes लगते हैं, जिससे emergency deployments धीमे होते हैं और incidents का mean time to recovery बढ़ता है
    • Envoy अधिक customizability और custom filters चलाने की सुविधा देता है
    • Figma पहले ही major services के सामने independent Envoy machine clusters को proxy के रूप में रख चुका था, और incidents के दौरान load घटाने वाले custom filters का इस्तेमाल कर चुका था
    • EKS में Istio जैसे कई open-source options हैं, लेकिन ECS में समान capabilities खुद फिर से बनानी पड़तीं

Popular platform से मिलने वाले operational advantages

  • Figma किसी service या software का सबसे बड़ा user नहीं बनना चाहता
    • सबसे बड़े users rough edges और scaling limits से सबसे पहले टकराते हैं
    • Kubernetes का उपयोग कई बड़ी enterprises विशाल compute platforms के लिए करती हैं, इसलिए Figma उनसे काफी छोटा user है
  • Kubernetes vendor lock-in कम करने में मदद करता है
    • EKS vendor-supported control plane के फायदे देता है
    • Services को generic Kubernetes पर चलने के लिए लिखा जाता है, इसलिए किसी दूसरे vendor-supported Kubernetes platform या self-hosted platform पर ले जाने का बोझ बहुत बड़ा नहीं होता
  • Kubernetes experience वाले engineers को hire करना आसान है
    • Existing experience वाले engineers जल्दी adapt कर सकते हैं और Figma में नए decisions बन सकने वाले areas के लिए context दे सकते हैं

Migration scope तय करने के principles

  • बड़े migrations में जिस core system को बदलना है केवल वही replace करना, और platform users को दिखने वाली abstractions को जितना संभव हो बनाए रखना सुरक्षित होता है
  • Figma ने ECS के बजाय EKS पर चलाने के लिए migration किया, लेकिन service execution model, deployment model और service interaction tools न बदलने की दिशा में scope सीमित रखा
  • Feature change जैसे न दिखने वाले काम भी second-order effects बना सकते हैं, इसलिए large-scale migration timelines आसानी से बढ़ सकती हैं
  • दो exceptions थे
    • अगर नए system को पुराने system जैसा behave कराने के लिए बहुत ज्यादा extra work चाहिए, तो second-order effects स्वीकार कर नया तरीका चुना जा सकता है
    • जो one-way door decisions बाद में बदलना मुश्किल या महंगा हो, उनमें शुरुआत से नया तरीका लागू किया जा सकता है

Scope में शामिल improvements

  • Developer experience

    • Existing ECS service definitions मुख्य रूप से Terraform से create और modify होती थीं
    • Terraform apply से 0 instances वाला ECS task set template बनाया जाता था, फिर deployment process में template clone कर image hash replace किया जाता था और non-zero instance count वाला task set ECS पर deploy होता था
    • एक environment variable जोड़ने के लिए भी Terraform लिखना और apply करना, फिर deployment चलाना पड़ता था; order न रखने पर code में environment variable सुरक्षित रूप से use नहीं हो पाता था और bugs आते थे
    • EKS में service definitions को एक जगह रखकर changes को एक step में deploy करने में बदला गया
    • Figma ने Bazel config files से services define करने का simple internal तरीका बनाया, और service definition YAML व Ingress जैसी configuration YAML automatically generate की
    • YAML code commit के समय CI tools में generate होता है और internal deployment system के जरिए apply होता है

  • Reliability

    • हर service के लिए 3 EKS clusters को Pods चलाने और traffic receive करने के लिए configure किया गया
    • अगर सभी operations cluster level पर हों, तो total failure को service के एक-तिहाई impact तक घटाया जा सकता है
    • जिन services में retry requests या asynchronous processing संभव है, उनमें user disruption अक्सर minimal रह सकता है
    • इस configuration ने deployment pipeline आदि में operational complexity बहुत बढ़ाई, लेकिन migration के समय तुरंत apply करना बाद में जोड़ने से अधिक worth माना गया

  • Cost efficiency

    • Complex cost optimization tasks migration scope में ज्यादा नहीं रखे गए, लेकिन node auto scaling शुरू से support किया गया
    • ECS on EC2 services में deployments के दौरान spikes संभालने के लिए machines over-provision की जाती थीं
    • EKS में Karpenter का उपयोग कर demand के अनुसार nodes dynamically scale up/down किए जाते हैं

Scope से बाहर रखे गए काम

  • Existing logging pipeline complex थी
    • सभी logs पहले CloudWatch में लिखे जाते थे
    • Lambda logs पढ़कर specific patterns delete करने और tags जोड़ने जैसे transformations करता था
    • फिर इन्हें Datadog और Snowflake में लिखा जाता था
    • Intermediate store CloudWatch की cost बढ़ रही थी
  • Figma ने EKS stack में sidecar के रूप में logs process और forward कर सकने वाले CNCF project Vector को adopt करने की योजना बनाई
  • लेकिन log forwarder logic को Vector configuration में port करने वाले second-order effects उठाना worth नहीं लगा, इसलिए इसे migration scope से बाहर रखा गया
  • Pod-level auto scaling भी migration में शामिल नहीं किया गया
    • Complexity बहुत अधिक मानी गई
    • इसे बाद में आसानी से जोड़ा जा सकने वाला काम माना गया
  • Excluded tasks बाद में follow-up work बन गए, और दूसरी services के EKS migration के साथ parallel में improvements दे सके

Safe execution approach

  • Existing ECS stack काफी stable था, इसलिए नया EKS stack और migration process भी कम-से-कम उतना ही reliable होना चाहिए था

  • Load testing

    • Figma ने “Hello, World” service बनाई, और उसे Figma की सबसे बड़ी service जितने Pods चलाने तक scale किया
    • इस test से पता चला कि पूरे platform को support करने वाली core compute services का size और scale adjust करना होगा
    • Kyverno cluster security validation tool है; अगर इसे पर्याप्त बड़ा configure न किया जाए, तो यह नए Pods start होने में देरी कर सकता है

  • Gradual rollout

    • Weighted DNS entries का उपयोग कर existing ECS service से EKS counterpart service की ओर traffic थोड़ा-थोड़ा move किया गया
    • Fine-grained traffic shifting और rollback control safe migration की key थी
    • Unexpected impact किसी unknown inflection point पर हो सकता है, इसलिए blast radius घटाना और तेजी से rollback कर पाना जरूरी था

  • Real services को जल्दी चलाना

    • Real workload को system पर डालने से staging alone से न पता चलने वाली बहुत सारी चीजें सीखने को मिलती हैं
    • Figma ने staging environment पूरा बनाने से पहले ही एक service migrate कर दी
    • यह early migration workload चलाने की capability को end-to-end validate करने और bottlenecks व bugs खोजने में मददगार रहा

  • YAML abstraction

    • Users को raw Kubernetes YAML से सीधे services define करने देना confusing हो सकता है
    • Figma ने users को golden path दिया, और केवल special cases में customization की अनुमति दी
    • Users क्या customize कर सकते हैं और क्या करना चाहिए, यह स्पष्ट करते हुए default consistency enforce की गई, जिससे maintenance और future changes सरल हुए

  • Service owner collaboration और staffing

    • New service setup platform team ने संभाला, जबकि monitoring और alerts updates service की स्थिति सबसे अच्छी तरह जानने वाले service owners के साथ करीबी collaboration में किए गए
    • Migration शुरू होने से पहले भी service owners के साथ options और tradeoffs पर पर्याप्त चर्चा की गई
    • Large-scale migrations unexpected issues, complex interactions और common bugs पैदा कर सकते हैं, इसलिए deep technical expertise और debugging capability वाली team की जरूरत थी

Actual migration timeline और results

  • 2023 की Q1 में plan बनाया गया और migration आगे बढ़ाने की सहमति ली गई
  • 2023 की Q2 में staging environment बनाया गया और single service migrate की गई
  • 2023 की Q3 में productionization, load testing और additional services migrate करने की preparation पर focus किया गया
  • 2023 की Q4 से जनवरी 2024 के पहले हफ्ते तक service traffic को धीरे-धीरे shift किया गया
  • जनवरी 2024 तक highest-priority services में से अधिकांश new EKS clusters पर migrate हो चुकी थीं
    • Core business logic रखने वाला monolith
    • Figma file editing के multiplayer aspect को handle करने वाली complex service
    • सभी clients को real-time updates push करने वाली Livegraph 100x component services
  • Result में deployment के लिए over-provisioning cost कम हुई, 3 clusters चलाने से reliability बढ़ी, और developer usability improved हुई
  • पूरा काम छोटे incidents और low customer impact के साथ आगे बढ़ा
  • एक incident में एक operator ने production cluster में से एक पर गलती से CoreDNS को destroy और recreate करने का काम कर दिया
    • पुराने configuration में यह total outage बन सकता था
    • 3-cluster configuration में impact requests के एक-तिहाई तक सीमित रहा
    • अधिकांश downstream services ने requests retry कीं और आखिरकार सफल रहीं

Launch के बाद tooling improvements

  • Figma ने tools बनाए ताकि service owners cluster में होने वाली चीजें debug कर सकें
    • Running instances की संख्या देखना
    • Container shell access
    • Emergency scaling जैसे operational tasks करना
  • Launch के तुरंत बाद feedback मिला कि यह access tooling पर्याप्त user-friendly नहीं है
  • Complexity की दो वजहें थीं
    • 3 clusters introduce होने से users को कई clusters में commands चलानी पड़ती थीं और हर command में cluster name जोड़ना पड़ता था
    • Kubernetes RBAC roles का उपयोग कर अधिक granular permissions देने से users को समझना पड़ता था कि उनके पास कौन-सी role है और किसी specific task के लिए कौन-सी role चाहिए
  • Figma ने तुरंत दूसरा काम रोककर tools को appropriate cluster और role automatically infer करने के लिए modify किया
  • Users को खासकर आधी रात की emergencies में role खोजने में समय बर्बाद नहीं करना पड़ता

Next steps

  • Remaining services का migration जारी रखते हुए new compute platform improvements parallel में किए जा रहे हैं
  • Current focus areas ये हैं
    • Logging pipeline design को simplify करना
    • Keda के जरिए horizontal Pod auto scaling support करना
    • Figma की सबसे costly services को Graviton processors पर migrate कर cost बचाना, और future में दूसरी services को भी Graviton पर चलाने का path बनाना
  • जिन areas में अभी deep investment नहीं हो पाया, उन्हें भी explore करने की योजना है
    • Service mesh offering को देखते हुए networking stack की reliability और observability improve करना
    • AWS Controllers for Kubernetes(ACKs) से अधिक resources manage कर Terraform dependency कम करना और stack को simplify व unify करना
    • Development environment में services चलाने के तरीके और अन्य environments में चलाने के तरीके को unify करने के लिए developer experience team के साथ collaboration

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-10
Hacker News की राय

  • निजी तौर पर मुझे Kubernetes पसंद है। मैं कई छोटे लेकिन जटिल custom e-commerce shopping malls चलाता हूँ, और साथ में marketing, finance और customer support भी देखता हूँ
    पहले इन्हें dedicated servers पर चलाता था, लेकिन stack काफी जटिल था, इसलिए deployment किसी nightmare जैसा था, और अंततः deployment का बोझ हमारी छोटी कंपनी की गति धीमी कर रहा था
    Kubernetes सीखने और migrate करने में एक महीना लगा, और हम frontend, product manager, logistics dashboard, delivery route optimization, OSRM, ERP, recommendation engine, search आदि मिलाकर करीब 25 services चला रहे हैं
    cluster configuration को एक जगह इकट्ठा करते हुए हमने उसे repeatable structure में व्यवस्थित किया, और हर service की state और running version ठीक-ठीक जान पाना संभव हुआ। zero-downtime rolling deployment भी संभव हो गया, और हाँ यह जटिल है, लेकिन programmers वैसे भी जटिल चीज़ों से निपटते हैं। Nginx configuration files भी जटिल होती हैं
    जितना गहराई में जाते हैं, उतना समझ आता है कि Kubernetes का architecture क्यों सही है, और यह 12-factor को सख्ती से follow करने पर मजबूर करता है। अगर आपकी income सीधे stack की availability और stability से जुड़ी है, तो high availability सिर्फ “हो तो अच्छा” से कहीं ज्यादा है। hosting cost भी करीब 400 dollars प्रति माह है, इसलिए इतनी महंगी नहीं है

    • Figma पहले भी ECS पर चल रहा था, इसलिए ऐसा नहीं था कि वे सिर्फ dedicated servers इस्तेमाल कर रहे थे
      मैं Kubernetes पर भरोसा करता हूँ, लेकिन यह सचमुच जटिल है। यह कठिन समस्याएँ हल करने वाला tool है। अगर multi-cloud है तो सोचने की जरूरत नहीं, और अगर आप local के साथ 1:1 match करने वाली complex infrastructure चाहते हैं, तो यह अच्छा fit है
      लेकिन अगर आपके पास 100 से कम developers हैं और आप AWS पर सिर्फ containers deploy कर रहे हैं, तो 2024 में ECS + Fargate के बजाय EKS इस्तेमाल करना मेरे हिसाब से समझदारी नहीं है
    • अगर आप कई छोटे और जटिल custom e-commerce shopping malls चलाते हैं, तो Kubernetes में multi-tenancy की कमी को कैसे handle करते हैं, यह जानने की उत्सुकता है

  • infrastructure foundation को बेहतर बनाने के लिए migration अपने-आप में अच्छी बात है। लेकिन यह हैरानी की बात थी कि motivations में से एक यह था कि teams Terraform में convert करने के बजाय Helm charts इस्तेमाल करें
    मैंने वास्तव में शायद ही कभी arbitrary Helm charts को बिना बदलाव के reliably इस्तेमाल होते देखा है, और अगर उनके उपयोग को encourage किया जाए तो अंततः teams charts को fork और modify करती हैं। Helm इतना भयानक tool है कि मैं custom Helm charts maintain नहीं करना चाहूँगा
    मुझे लगता है कि Terraform में फिर से लिखना local version maintain करने के लिहाज से बेहतर है। अगर कोई counterexample हो तो सुनना चाहूँगा। हो सकता है इन दिनों Helm का indent 4 वाला पागलपन और multi-stage string templating की समस्या खत्म हो गई हो

    • Helm charts और Terraform अलग-अलग चीज़ें हैं, ऐसा मैं मानता हूँ। Terraform S3 buckets, EKS clusters, EKS workers, RDS जैसे cloud resources deploy करने के लिए ज्यादा उपयुक्त है
      Kubernetes workloads को Terraform से manage किया जा सकता है, लेकिन मैं इसकी सलाह नहीं दूँगा। Kubernetes की अपनी state होती है, और अगर Terraform की भी state हो तो Terraform + Kubernetes combination दर्दनाक हो जाता है। Helm Kubernetes के लिए बनाया गया है, Terraform नहीं
      इसका मतलब यह नहीं कि मुझे Helm पसंद है। templated YAML मुझे पसंद नहीं, और indent 4 वाला पागलपन अब भी है। Kustomize simple cases में अच्छा है, लेकिन app जटिल हो जाए तो मुझे यह Helm से भी खराब लगता है। उदाहरण के लिए, अगर कई environments के लिए Ingress, TLS certificate और external-dns वाला app deploy करना हो, तो जहाँ एक variable को तीन जगह इस्तेमाल कर देना काफी होता, वहाँ resources को तीन बार patch करना पड़ता है
      Helm और Terraform दोनों लोकप्रिय हैं इसलिए उनका बहुत जिक्र होता है, लेकिन अंततः मुझे लगता है कि इन दोनों की जगह लेने वाला कोई ऐसा tool आएगा जो अभी mainstream नहीं हुआ है
    • जिस BigCo में मैं अभी काम करता हूँ, वहाँ infrastructure और deployments दोनों को Terraform से बेतुके scale पर manage किया जाता है, और यह nightmare है
      Terraform की समस्या यह है कि workspace design करते समय per workspace recommended resource count, यानी लगभग 100–200 resources, से ऊपर न जाएँ। वरना जिन databases या networks को आपने छुआ भी नहीं और छूने का इरादा भी नहीं है, उन्हें check करने में plan बहुत धीमा हो जाता है और deployment time बढ़ जाता है
      वास्तविकता में आप एक-दूसरे को trigger करने वाले Terraform workspaces की grid बना बैठते हैं, और इसे ठीक से support करने वाला अच्छा open source tool फिलहाल नहीं है
      अभी मुझे सबसे अच्छा तरीका यह लगता है कि Terraform, ArgoCD जैसे continuous deployment tool को infrastructure के हिस्से के रूप में install करे, और रोजमर्रा के deployments CD tool संभाले। और अधिकांश CD tools deployment को Helm जैसी किसी चीज़ में package करने को कहते हैं
    • Helm की बात करें तो, निजी तौर पर अब मुझे इससे गहरी नफरत हो गई है। जब यह पहली बार आया था तो शानदार था और एक जरूरी gap भरता था
      लेकिन इसमें इतने ज्यादा pitfalls हैं कि दूसरे engineers के बनाए काम को फिर से करने और debug करने में समय लग जाता है
      उम्मीद है कि timoni नाम का नया tool momentum पकड़े। यह Helm को लेकर मेरी लगभग सारी शिकायतें हल करता है। अगर आप बेहतर solution ढूँढ रहे हैं, तो timoni देखना worthwhile है
    • हमारी team ने भी public Helm charts में बताई गई समस्याएँ झेली हैं। अपने environment में सही से चलाने के लिए हमेशा कुछ न कुछ customize करना पड़ता है
      हमने public Helm charts को वैसे ही रखने और customization को kustomize —enable-helm से handle करने का तरीका चुना
    • मैं मानता हूँ कि Helm charts लिखना कोई खास मजेदार काम नहीं है, लेकिन उन्हें use करना काफी ठीक हो सकता है
      हमारे case में reasonable defaults देने वाला single application/service based Helm chart है, और सभी deployments उसे extend करते हैं। इस्तेमाल करने वाले side पर जरूरी Helm values configuration न्यूनतम है, और अपने templates डालने की नौबत भी शायद ही आई है। वजह यह है कि base chart पर्याप्त adjustment points expose करता है
      third-party charts में से काफी को हम वैसे ही deploy कर पाए, और कभी-कभी जरूरी functionality upstream में PR के तौर पर add की। बहुत कम cases में wrap या fork करना पड़ा, लेकिन वैसे ही deploy किए गए third-party charts कहीं ज्यादा हैं
      custom charts maintain करते समय helm unittest (https://github.com/helm-unittest/helm-unittest) regressions से बचने में बहुत मदद करता है
      Terraform से हम ArgoCD सहित कुछ Kubernetes resources manage जरूर करते हैं, लेकिन आम तौर पर ArgoCD के जरिए Helm charts deploy करना कहीं ज्यादा manageable और productive रहा है

  • HN पर इतनी ज़्यादा anti-Kubernetes भावना देखकर हैरानी होती है। सोचता हूँ कि क्या ज़्यादातर commenters ऐसे developers हैं जो Heroku, fly.io, render.com जैसी services के आदी हैं, या फिर वे VM पर apps चलाते हैं

    • पिछले करीब 10 सालों में software में अनावश्यक complexity के विस्फोट से बहुत लोग तंग आ चुके हैं, और यह जायज़ भी है
      यह किसी एक खास case तक सीमित समस्या नहीं है, बल्कि पूरे industry में बुरी तरह बिगड़े incentives और कुछ हद तक low-interest-rate दौर की gold rush से बनी समस्या है
      सच कहूँ तो अपने मौजूदा रूप में हम दूसरे क्षेत्रों में काफी बेकार कारीगर जैसे दिखेंगे। tools और meta work को लेकर unhealthy obsession रखते हुए, किसी खास tool का इस्तेमाल करने के लिए reasonable resource usage को लगातार खिड़की से बाहर फेंकते रहते हैं। यह एक तरह की “थोड़े समय के लिए मुश्किल हालात में फँसे FAANG engineer” वाली स्थिति है
    • निजी तौर पर मुझे काल्पनिक theoretical business requirements—जैसे कि किसी दिन multi-cloud की ज़रूरत पड़ सकती है या on-premises deployment चाहिए हो सकता है—के नाम पर Kubernetes इस्तेमाल करने की बात थोड़ी चिढ़ाती है
      AWS में उपलब्ध deployment models, जैसे EC2 की VM images, Elastic Beanstalk, ECS/Fargate, Lambda के बजाय Kubernetes पर build करने में कितना ज़्यादा समय लगेगा, कितनी ज़्यादा expertise चाहिए होगी, कितना ज़्यादा fragile होगा और कितना ज़्यादा पैसा लगेगा—यह समझाना मुश्किल है
      मैं खुद ELK stack या Prometheus install और maintain नहीं करना चाहता। CNI plugin, Kafka, high-availability Postgres, Argo, Helm, control plane upgrades से जूझना भी नहीं चाहता। AWS की equivalent services से लगभग तुरंत शुरुआत की जा सकती है, maintenance भी लगभग नहीं के बराबर होती है, और cost भी आम तौर पर शून्य के पास से linear तरीके से शुरू होती है
      business problem को कहीं ज़्यादा तेज़ और efficient तरीके से solve किया जा सकता है। यह expectations से काफी आगे निकल सकने वाली स्थिति और पूरी team के कई quarters पीछे रह जाने वाली स्थिति के बीच का फर्क है
      हालांकि अगर सचमुच multi-cloud या on-premises requirement है, तो Kubernetes के अलावा कुछ इस्तेमाल नहीं करना चाहूँगा। ऐसी बड़ी company में जहाँ Kubernetes समझने वाले बहुत skilled engineers हों, यह शायद इतना बुरा भी न हो। कम से कम जिन जगहों पर मैंने काम किया, वहाँ ऐसा नहीं था
    • बहुत लोगों का नापसंद करना एक तरह से सफलता का संकेत भी है
      companies को मुख्य रूप से open source infrastructure की ओर जाते देखना अच्छा लगता है। उनमें से काफी कुछ CNCF (https://landscape.cncf.io), ASF, और GitHub के कई projects से आता है
    • कुछ situations में यह इस्तेमाल करने लायक है, लेकिन यह उन technologies में से एक है जिन्हें बहुत बार cargo cult की तरह adopt किया जाता है
    • मेरे लिए VM वाला issue बड़ा है। kernel vulnerability हो तो malicious code container से escape करके Kubernetes host में ताक-झाँक कर सकता है—यह विचार असहज करता है
      kata-containers शायद उस चिंता को दूर कर दे और Kubernetes को मेरे लिए enjoyable बना दे
      कुल मिलाकर Kubernetes में मुझे निजी तौर पर कुछ भी cool नहीं लगता। containers, load balancers, megabytes भर YAML—ये सब पहले ही देख चुका हूँ, और इसे try करने लायक interesting नहीं लगता

  • इस scale की company में यह normal हो सकता है, लेकिन ऐसे बड़े migration या technology projects के decision-making को follow करना मुश्किल है। क्योंकि decision users या company की ज़रूरतों से निकला हुआ नहीं दिखता
    Figma ने पहले database से जुड़े जिस मिलते-जुलते post को डाला था, उसमें भी मुझे यही महसूस हुआ था
    उदाहरण के लिए, अगर Kubernetes पर जाने की वजह यह है कि ECS में etcd/Helm इस्तेमाल नहीं कर सकते, तो पहले यह पूछना चाहिए कि etcd/Helm इस्तेमाल करना क्यों चाहते हैं। क्या वह सच में इतना महत्वपूर्ण है? company के goals हासिल करने का तरीका सचमुच ठीक वही एक तरीका है?
    decision अगर users की needs पर आधारित हो तो नीचे के decisions validate करना आसान होता है, लेकिन अगर वह technical desire पर आधारित हो, तो उस technical desire के context में नीचे के decisions सही लग सकते हैं, फिर भी user context में वे valid हैं या नहीं, यह अनिश्चित रहता है
    या तो मैं इस scale के organization को समझ नहीं पा रहा हूँ, या फिर इस scale के organization के लिए valuable काम पहचानना और उसके बारे में reason करना ही fundamentally मुश्किल है—मुझे इन दोनों में से कोई एक बात लगती है

    • मैं लेखक हूँ; यह अच्छा सवाल है और framing भी अच्छी है। कम से कम इस decision समेत कुछ बड़े decisions में मैं इस बात से सहमत हूँ कि “इस scale के organization के लिए valuable काम पहचानना और उसके बारे में reason करना fundamentally मुश्किल है”
      हम मूलतः platform team हैं, और अक्सर उन दूसरी platform teams के लिए tools बनाते हैं जो असली product experience बनाने वाले Figma developers को support करने वाले tools बनाती हैं। end user से जितना दूर जाते हैं, सही decision के बारे में reason करना उतना कठिन होता है, लेकिन साथ ही leverage भी बड़ा हो जाता है
      platform सही बनाया जाए तो उसका असर बाकी सभी engineers की efficient और effective तरीके से काम करने की क्षमता पर पड़ता है। इनमें से बहुत से effects indirect होते हैं
      यह option साफ़ था कि हम कह सकते थे कि etcd और Helm support नहीं कर सकते, इसलिए कोई दूसरा workaround ढूँढ़ो। लेकिन ये दोनों ऐसे extra data points थे जिन्होंने हमें इस निष्कर्ष की ओर धकेला कि हम Compute platform को गलत building blocks के ऊपर चला रहे हैं
      reasoning कठिन हो, फिर भी उसे अच्छी तरह करने की कोशिश करना बहुत valuable है। क्योंकि platform team के रूप में यही तरीका है जिससे हम सुनिश्चित करते हैं कि सबसे अच्छे platform तक पहुँचने के लिए सही चीज़ें कर रहे हैं। इसलिए हमने यह decision लेने में बहुत समय लगाया, और इसे लिखने लायक interesting subject माना
    • लोग ECS से Kubernetes पर इसलिए जाते हैं ताकि cloud provider से बंधे न रहने वाले tools और products इस्तेमाल कर सकें
      बड़ी companies के Kubernetes migrations में से काफी multi-cloud या on-premises hybrid की चाह, cost·availability·lock-in risk कम करने से driven होने की संभावना है
    • 500 से ज़्यादा VM manage करना बहुत काम है
      VM upgrades, certification, backup, log rotation वगैरह सब align करना पड़ता है
      Kubernetes में हर किसी को namespace, policy, volume दिया जा सकता है, और DaemonSet तथा Kubernetes/cloud native stack की वजह से automatic log aggregation भी संभव है
      self-healing वगैरह भी है, और यह कितना बेहतर हो जाता है, समझाना भी मुश्किल है
    • मुझे Helm पसंद नहीं है, लेकिन etcd के अच्छे alternatives आश्चर्यजनक रूप से कम हैं
      उदाहरण के लिए distributed environment में .pid file के equivalent के तौर पर इस्तेमाल करने लायक high-availability और consistent data store बहुत कम हैं। जो याद आता है वह Zookeeper है, लेकिन operations के लिहाज़ से वह सचमुच दर्दनाक है, पुराने JVM versions मांगता है, और फिर भी कुल मिलाकर unstable है
    • ऐसा क्यों होता है, इस पर एक theory यहाँ है: https://lethain.com/grand-migration/

  • Terraform कोड लागू होने के बाद, 0 instances वाला ECS task set बनाकर service template खड़ा करना, और फिर डेवलपर द्वारा service deploy करते समय इस template task set को clone करके कई manual steps करने पड़ते थे—यह हिस्सा ECS की समस्या से ज़्यादा Terraform + ECS deployment management के तरीके को जरूरत से ज़्यादा जटिल बनाने जैसा लगता है
    असली deployment से पहले validation के लिए template बनाना समझ में आता है। लेकिन यह थोड़ा अस्पष्ट है

    • मैं ही लेखक हूँ, और पूरी तरह सहमत हूँ कि यह ECS की कोई मूलभूत सीमा नहीं है। इस setup को लगातार बेहतर बनाकर कुछ ज्यादा अच्छा बनाया जा सकता था
      इसलिए मैंने जानबूझकर इसे migration प्रक्रिया में शामिल करने वाले काम के रूप में रखा, और migration शुरू करने के मूल कारणों में नहीं रखा
    • सहमत हूँ। ECS deployment काफ़ी painless और सरल है
      हालांकि कुछ scenarios की कल्पना कर सकता हूँ जहाँ यह तरीका जरूरी हो जाता है। जैसे ECS पर deploy की गई services बहुत अधिक हों और Terraform state का size बढ़ जाए। तब plan और apply काफी धीमे हो जाते हैं, और template-based तरीके से configuration को जस-का-तस replicate करके Terraform state को shard करना कहीं ज्यादा सुरक्षित हो सकता है
    • बिल्कुल सहमत। मैंने दो कंपनियों में Terraform से ECS infrastructure बनाया है, और ऐसे कामों में कोई manual step नहीं था
      बस environment variables को Terraform file में जोड़ना, merge करना, और फिर CI से deploy करवा देना—इतना ही था। हमारे ज्यादातर configuration changes इसी प्रक्रिया से हो जाते थे

  • “Kubernetes पर migrate करने में कई साल लग सकते हैं”—आखिर मैं क्या पढ़ रहा हूँ, समझ नहीं आ रहा
    किसके लिए ऐसा है? कंपनियाँ ऐसी migration करने की जहमत क्यों उठाती हैं, यह भी ठीक से समझ नहीं आता। business value कहाँ है, और customers को क्या फायदा मिलता है? क्या यह Figma का “art for art’s sake” जैसा project है, क्योंकि वे कर सकते हैं इसलिए कर रहे हैं?

    • मैं भी इस वाक्य से काफी हैरान हुआ, और 1 साल के भीतर Kubernetes पर जाने को जैसे उपलब्धि बताने वाले हिस्से से भी हैरानी हुई
      लगभग 30 साल पुरानी, अपने साथ baggage वाली, बहुत established कंपनी में भी हमने Kubernetes पर इससे कहीं कम समय में migration किया था। हालांकि हमने सब कुछ Kubernetes पर ले जाने की कोशिश नहीं की; केवल वही ले गए जहाँ फायदा मिल सकता था
      हमारा प्रस्ताव मोटे तौर पर यह था: Kubernetes पर migrate करोगे तो साल के अंत में planned datacenter relocation के समय checking के अलावा कुछ नहीं करना पड़ेगा। वरना नए machines या VMs पर apps को redeploy करना होगा और उससे जुड़ी तमाम परेशानियाँ संभालनी होंगी। अगर आपका app पहले से containerized नहीं है, तो अभी containerize कर दीजिए, बाकी हम संभाल लेंगे
      अधिकतर लोग migrate हो गए और परिणामों से बहुत संतुष्ट थे। वहीं latency-sensitive या high-performance computing वाले services को जबरन migrate करने की कोई वजह नहीं थी, और हमने उन्हें fit कराने की कोशिश भी नहीं की
    • यह “हाल ही में acquisition हुआ है, और इस्तेमाल करने के लिए बहुत resources हैं” वाली समस्या हल कर देता है

  • इससे बाहर निकलने में कितना समय लगेगा?

    • यह इस पर निर्भर करता है कि कितना Kubernetes-native code है। कुछ applications ऐसी भी होती हैं जो Kubernetes API का काफी इस्तेमाल करती हैं और Kubernetes पर चलने के लिए ही design की गई होती हैं
      अगर app पहले से microservices में बंटा हुआ है, तो वापस लौटना भी आसान नहीं है

  • जब किसी blog post में दिखने में साधारण feature पाने के लिए 6 ऐसे CNCF projects का सहजता से ज़िक्र होता है जिनके fancy नाम मैंने पहली बार सुने हों, तो मुझे लगता है कि मैं समय से पीछे रह गया हूँ
    सच में सोचने लगता हूँ कि क्या professional software development से उम्र के कारण बाहर होने का समय आ गया है

    • ऐसा नहीं है। individual contributor का काम अब भी बहुत है
      इसका मतलब सिर्फ इतना है कि आप संगठन को scale करने के एक approach से परिचित नहीं हैं, जहाँ platform team hardware, logging, retries वगैरह को abstract करती है
      यह अकेला approach नहीं है, इसलिए हो सकता है आप दूसरे तरीकों से परिचित हों

  • यह लेख अच्छा है क्योंकि यह Kubernetes से मिलने वाले फायदे और कारणों को साफ और व्यवस्थित तरीके से समझाता है
    कई teams बिना यह जाने कूद पड़ती हैं कि उन्हें क्या मिलेगा, या इसकी जरूरत भी है या नहीं; लेकिन यहाँ दिए गए कारण ठीक लगते हैं

  • शुद्ध जिज्ञासा है: कौन-सा दूसरा modern system या service है जिसके लिए कोई समझदार व्यक्ति 1 साल के भीतर migrate कर लिया कहकर शेखी बघार सकता है?

    • जवाब देना मुश्किल सवाल है। हर system scale, scope और impact के मामले में समान नहीं होता
      Kubernetes जैसा system आम तौर पर infrastructure के core में होता है, इसलिए चल रही हर चीज़ को प्रभावित करता है। इसमें लेख में बताई गई team constraints भी जोड़ दें, तो 1 साल इतना बुरा नहीं लगता
      तुरंत याद आने वाला उदाहरण है कि पहले Amazon ने Oracle से पूरी तरह Amazon/open-source relational databases पर migration किया था। हालांकि मुझे याद है कि उसमें कई साल लगे थे। अगर उन्होंने 1 साल में खत्म किया होता, तो निश्चित रूप से शेखी बघारते
    • 1 साल से ज्यादा चलने वाली migrations मैंने बहुत देखी हैं
      अक्सर मामला technology से ज्यादा technical debt, integration complexity और लगाए गए लोगों का होता है