Maestro: Netflix का Workflow Orchestrator

 (netflixtechblog.com)
4 पॉइंट द्वारा GN⁺ 2024-07-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Netflix ने बड़े पैमाने के Data/ML workflows के लिए horizontally scalable orchestrator Maestro को open source किया है, और internally लाखों workflows को न्यूनतम disruption के साथ migrate कर operate कर रहा है
  • DAG-केंद्रित orchestrators के विपरीत, यह acyclic और cyclic workflows दोनों को संभालता है, और foreach loops, subworkflows व conditional branches को engine-level patterns के रूप में देता है
  • पिछले 1 साल में executed tasks की संख्या 87.5% बढ़ी है, और अभी रोज़ औसतन हजारों workflow instances व करीब 5 लाख tasks चलाता है; busy दिनों में लगभग 20 लाख tasks पूरे करता है
  • JSON-आधारित definitions में execution strategies, parameters, SEL expressions, signals, breakpoints, timelines, retry policies और rollups को जोड़कर operational control और debugging को support करता है
  • Netflix जैसे environment में, जहां data tables एक single data warehouse में इकट्ठा हैं, workflows को कई clusters में बांटने से coordination cost और user experience में गिरावट बढ़ती है, इसलिए single orchestrator द्वारा पूरे flow को संभालना महत्वपूर्ण है

Maestro का खुलासा और Netflix में संचालन का पैमाना

  • Netflix ने Maestro GitHub repository के जरिए Maestro source code公開 किया है
  • Maestro data pipelines और machine learning model training pipelines जैसे बड़े पैमाने के Data/ML workflows को manage करने वाला horizontally scalable workflow orchestrator है
  • यह workflow की शुरुआत से अंत तक पूरी lifecycle manage करता है, और retries, queuing व compute engine को task distribution संभालता है
  • Users business logic को Docker images, notebooks, bash scripts, SQL, Python आदि कई formats में package कर सकते हैं
  • Netflix ने पहले इसका परिचय देने के बाद लाखों workflows को Maestro पर migrate किया, और transition के दौरान user disruption को minimum रखा
  • हालिया operating scale:
    • पिछले 1 साल में executed tasks की संख्या 87.5% बढ़ी
    • रोज़ औसतन हजारों workflow instances execute होते हैं
    • रोज़ औसतन करीब 5 लाख tasks execute होते हैं
    • busy दिनों में लगभग 20 लाख tasks पूरे होते हैं

single orchestrator से scalability और विविधता का support

  • Maestro Netflix के अंदर हजारों end users, applications और services को Workflow-as-a-Service देने वाला fully managed orchestrator है
  • यह ETL pipelines, ML workflows, AB test pipelines और कई storage systems के बीच data movement pipelines को support करता है
  • इसका horizontal scaling architecture workflows की बड़ी संख्या और किसी single workflow के अंदर tasks की बड़ी संख्या—दोनों को handle करने के लिए design किया गया है
  • Netflix के workflows आपस में बहुत tightly connected हैं, इसलिए उन्हें छोटे groups में बांटकर कई clusters में manage करने पर extra coordination mechanisms चाहिए होते हैं और user experience घटता है
  • चूंकि data tables एक single data warehouse में हैं, इसलिए इन्हें access करने वाले सभी workflows को single orchestrator द्वारा handle किया जाना चाहिए—यह Netflix का निष्कर्ष है

workflow definition model

  • Maestro की workflow definition JSON format में लिखी जाती है
  • user-provided fields और Maestro-managed fields को जोड़कर orchestration definition बनाई जाती है; उदाहरण Maestro repository wiki में है
  • workflow definition broadly दो हिस्सों में बंटी होती है
    • properties: author/owner की जानकारी और execution settings शामिल
    • versioned workflow: workflow metadata और graph definition शामिल
  • properties workflow version बदलने पर भी author/owner information, execution strategy और concurrency settings जैसे core attributes को preserve करती हैं
  • ownership बदलने पर नया workflow version बनाए बिना नया owner मौजूदा workflow की ownership ले सकता है
  • versioned workflow में unique identifier, name, description, tags, timeout settings, और prioritization के लिए low/medium/high criticality levels शामिल होते हैं
  • workflow में बदलाव नया version बनाता है, और default रूप से active version या latest version इस्तेमाल होता है
  • workflow user-defined graph के nodes यानी steps से बना होता है
    • step कोई task, subworkflow step के जरिए दूसरा workflow, या foreach step के जरिए loop दर्शा सकता है
    • step में unique identifier, step type, tags, input/output parameters, dependencies, retry policy, failure mode, step output आदि शामिल होते हैं
    • यह error type के हिसाब से configurable retry policies support करता है

execution order को control करने वाली Run Strategy

  • Maestro predefined run strategy के जरिए तय करता है कि नया workflow instance execute करना है या नहीं

  • Sequential Run Strategy

    • यह default strategy है, और FIFO order में एक बार में एक instance चलाती है
    • पिछले run की सफलता से independent होकर, जब instance success या failure जैसी terminal state में पहुंचता है, तब queue का अगला instance start होता है

  • Strict Sequential Run Strategy

    • triggered order में execute करती है, लेकिन अगर पिछले instance history में blocking error हो तो execution रोक देती है
    • जब तक failed instance को manually restart या unblock नहीं किया जाता, new instances queue में रहते हैं
    • यह कम time-sensitive लेकिन business-critical workflows के लिए useful है

  • First-only Run Strategy

    • running workflow पूरा होने से पहले new instance को queue में नहीं रखती
    • अगर कोई instance अभी running है, तो newly queued instance को हटा देती है, यानी queuing practically बंद हो जाती है
    • new instances जमा न होने से idempotency issues से बचने में मदद मिलती है

  • Last-only Run Strategy

    • हमेशा सबसे recently triggered instance को run करवाती है
    • अगर कोई existing running instance है, तो उसे terminate करके newly triggered instance चलाती है
    • यह उन cases में useful है जहां सिर्फ latest data चाहिए, जैसे workflows जो हर बार पूरी table का latest snapshot process करते हैं

  • Parallel with Concurrency Limit Run Strategy

    • predefined concurrency limit के भीतर कई instances को parallel में execute करती है
    • बहुत सारे data को limited time में process करने के लिए execution को fan-out और distribute किया जा सकता है
    • पुराने data backfill इसका common use case है

parameters और SEL expressions

  • Maestro में parameters execution logic control करने, workflow और steps के बीच state share करने, और upstream व downstream steps के बीच state share करने के लिए इस्तेमाल होते हैं
  • Maestro code injection वाले dynamic parameters को support करता है, जिससे complex parameterized workflows define किए जा सकते हैं
  • code injection security और stability risks पैदा कर सकता है
    • अगर user infinite loop लिखकर array में लगातार items जोड़ता रहे, तो server OOM होकर रुक सकता है
    • injected code को business logic में ले जाने से users पर बोझ बढ़ता है और workflow definition व business logic कसकर coupled हो जाते हैं
  • Netflix ने इसे mitigate करने के लिए अपनी expression language SEL(Simple, Secure, and Safe Expression Language) develop की
  • SEL Java Language Specifications की grammar और syntax follow करता है, लेकिन Maestro use cases के हिसाब से subset support करता है
  • SEL Maestro parameter types के data types, error generation, date/time handling और predefined utility methods support करता है
  • stability के लिए इसमें loop iteration limits, array size checks और object memory size limits जैसी runtime checks शामिल हैं
  • SEL documentation Maestro GitHub documentation में है

output parameters और parameterized workflows

  • Maestro callable step execution के जरिए user execution results को output parameters के रूप में system को वापस दे सकता है
  • output data Maestro REST API के जरिए भेजा जाता है, और step runtime Maestro database को directly access नहीं करता
  • static workflows simple होते हैं, लेकिन छोटे differences reflect करने के लिए उसी workflow को कई बार duplicate करना पड़ सकता है; parameters के बिना workflows और tasks state share नहीं कर सकते
  • fully dynamic workflows को manage और support करना मुश्किल होता है, और debugging, troubleshooting व reuse भी कठिन होते हैं
  • parameterized workflows user-defined parameters के आधार पर runtime पर step-by-step initialize होते हैं, जिससे execution-time control की flexibility और manageability दोनों मिलती हैं
  • Maestro का parameter support backfill data pipelines जैसे complex parameterized workflows बनाने को संभव बनाता है

Engine-level Workflow Execution Patterns

  • Maestro common dataflow और workflow patterns को सीधे engine में support करता है
  • Engine का direct support pattern optimization और consistent implementation approach को संभव बनाता है

  • Foreach

    • foreach pattern को मूल रूप से workflow definition के अंदर एक dedicated step के रूप में model किया गया था
    • foreach loop की हर iteration को internally एक अलग workflow instance के रूप में process किया जाता है
    • foreach definition block के अंदर step execution, यानी sub-graph execution, एक अलग workflow instance को delegate किया जाता है
    • foreach step हर iteration को संभालने वाले workflow instance की state को monitor और collect करता है
    • यह अक्सर data backfill या machine learning model tuning में इस्तेमाल होता है, जहाँ अलग-अलग parameters के साथ वही task चलाना होता है
    • users को workflow definition में सीधे लाखों iterations लिखने की जरूरत नहीं होती, और foreach range बदलने पर नया workflow बनाने की जरूरत भी कम हो जाती है

  • Conditional Branch

    • conditional branch upstream step की कोई खास condition पूरी होने पर ही आगे के steps चलाने देता है
    • condition SEL expression के रूप में define होती है और runtime पर evaluate की जाती है
    • audit check step fail होने पर recovery task चलाकर फिर task को दोबारा execute करने वाला flow बनाया जा सकता है

  • Subworkflow

    • subworkflow में एक workflow step दूसरे workflow को execute करता है, जिससे common functionality कई workflows में share की जा सकती है
    • “workflow as a function” के रूप में workflow graph बनाया जा सकता है
    • Netflix में कई teams द्वारा provide किए गए subworkflows को combine करके सैकड़ों tables का data process करने वाले, सैकड़ों subworkflows से बने complex workflows भी देखे गए हैं
    • foreach, conditional branch और subworkflow को साथ में combine किया जा सकता है
    • subworkflows के set को loop में process किया जा सकता है
    • nested foreach loops execute किए जा सकते हैं
    • conditional branch और subworkflow को साथ इस्तेमाल करके errors handle करने और tasks को automatically retry करने वाले auto-recovery workflows बनाए जा सकते हैं

Step Runtime और Parameter Merging

  • Maestro execution time पर task को describe करने के लिए step runtime का इस्तेमाल करता है
  • step runtime interface दो तरह की जानकारी define करता है
    • step instance के execution behavior को control करने वाला basic API set
    • step runtime state और execution result को track करने वाला simple data structure
  • Maestro foreach step runtime, subworkflow step runtime जैसे implementations provide करता है
  • हर implementation start, execute, terminate actions के लिए अपना logic define करता है
  • runtime state का इस्तेमाल step के अगले state transition को तय करने और failure या termination की स्थिति का आकलन करने के लिए किया जाता है
  • execution result में step artifacts और step execution history timeline होती है, जिसे बाद के steps access कर सकते हैं

  • Step Parameter Merging

    • Maestro step behavior को dynamically control करने के लिए runtime parameter और tag injection support करता है
    • step parameter map शुरुआत में empty होता है, और नीचे दिए order में merge होता है
    • Default General Parameters: workflow_instance_id, step_instance_uuid, step_attempt_id, step_id जैसे सभी steps के default parameters; ये Maestro के internal reserved values हैं और user इन्हें pass नहीं कर सकता
    • Injected Parameters: step runtime में dynamically generate होने वाले parameters; ये step type-specific schema के अनुसार बदल सकते हैं
    • Default Typed Parameters: किसी specific step type से जुड़े default parameters, जैसे foreach step के loop_params, loop_index आदि
    • Workflow and Step Info Parameters: workflow_id जैसी step और workflow से जुड़ी identifying information
    • Undefined New Parameters: workflow instance start या restart करते समय user द्वारा नए specify किए गए step parameters
    • Step Definition Parameters: definition time पर user द्वारा लिखे गए step parameters
    • Run and Restart Parameters: start या restart के समय existing definition parameters को override करने के लिए user द्वारा दिए गए values; इन्हें सबसे आखिर में merge किया जाता है

Step Dependencies और Signal

  • Maestro workflow graph के steps step dependency के जरिए execution dependencies express कर सकते हैं
  • step dependency, step execution के लिए जरूरी data-related conditions specify करती है
  • conditions आमतौर पर signal पर आधारित define होती हैं
  • signal एक message है जिसमें parameter values जैसी जानकारी होती है, और इसे step output या SNS·Kafka जैसे external systems के जरिए publish किया जा सकता है
  • signal का इस्तेमाल trigger pattern और publisher-subscriber type के signal dependency pattern, दोनों में होता है
  • एक step output signal publish करके उस signal पर depend करने वाले कई steps की execution unlock कर सकता है
  • signal definition mapped parameters की list शामिल करती है, और Maestro सिर्फ कुछ fields के आधार पर signal matching कर सकता है
  • Maestro signal parameter values के लिए <, > जैसे signal operators support करता है
  • Netflix ने signal concept के ऊपर कई abstractions बनाए हैं
    • जब ETL workflow table update करके signal भेजता है, तो उस data पर depend करने वाला downstream workflow step execute हो सकता है
    • signal lineage past signal instances और उन्हें publish या consume करने वाले workflow steps को explore करने देता है
    • signal trigger, एक या joined signal set को subscribe करने वाले workflows के लिए exactly-once execution guarantee करता है
  • workflow या step को सिर्फ specified signal conditions पूरी होने पर execute किया जाता है, इसलिए resources बचाए जा सकते हैं

Debugging और Execution Visibility

  • Breakpoint

    • Maestro workflow steps पर breakpoint set करने की सुविधा देता है
    • जब workflow instance breakpoint लगे step तक पहुँचता है, तो वह step paused state में चला जाता है
    • user के manually resume करने तक workflow graph की progress रुक जाती है
    • अगर उसी workflow step के कई instances breakpoint पर रुके हों, तो एक को resume करने पर सिर्फ वही instance प्रभावित होता है और बाकी paused state में रहते हैं
    • breakpoint delete करने पर रुके हुए सभी step instances resume हो जाते हैं
    • शुरुआती workflow development के दौरान step execution और output data inspect करने में यह useful है
    • foreach pattern में किसी single step पर breakpoint लगाने से सभी iterations उसी step पर रुक जाती हैं, जिससे debugging की जा सकती है
    • execution के दौरान human intervention या running step की state change support करने के लिए भी इसका इस्तेमाल किया जा सकता है

  • Timeline

    • Maestro step execution timeline शामिल करता है, जिसमें state machine changes और उनके reasons जैसे major events record होते हैं
    • example events में Created, Evaluating params जैसे transitions शामिल हैं
    • implemented step runtime end users को execution information दिखाने के लिए timeline events add कर सकता है
    • timeline example sample-step-instance-failed.json में है

Retry, Aggregated View, Rollup

  • Retry Policies

    • Maestro उन steps के लिए retry policy सपोर्ट करता है जो failure के साथ terminal state तक पहुँच चुके हों
    • उपयोगकर्ता retry की संख्या, retries के बीच delay, fixed-interval retry, और exponential backoff strategy सेट कर सकते हैं
    • retries को दो प्रकारों में बाँटा जाता है
    • platform retry: user logic से असंबंधित platform-level errors से निपटना
    • user retry: user-defined conditions के आधार पर retry
    • हर प्रकार की अलग retry policy हो सकती है
    • automatic retries ऐसे transient errors को संभालने में उपयोगी हैं जिन्हें user intervention के बिना हल किया जा सकता है
    • जिन steps में idempotency नहीं है, वे retries से बचने के लिए retry count को 0 पर सेट कर सकते हैं

  • Aggregated View

    • क्योंकि एक workflow instance के कई runs हो सकते हैं, उपयोगकर्ताओं को सभी steps की aggregated status देखने में सक्षम होना चाहिए
    • aggregated view की गणना base aggregated view और current run के step statuses को merge करके की जाती है
    • उदाहरण के लिए, अगर पहली run में step1·step2 सफल हों, step3 fail हो, और step4·step5 अभी शुरू न हुए हों, तो restart step3 से शुरू होता है और step1·step2 को उनकी पिछली successful status के कारण skip किया जा सकता है
    • जब सभी steps सफल हो जाते हैं, तो aggregated view पूरे steps की run status दिखाता है

  • Rollup

    • rollup workflow instance का higher-level summary देता है, जिसमें हर step की status और status के हिसाब से step count दिखता है
    • यह current instance और subworkflow·foreach जैसे nested non-inline workflows के steps को expand करके aggregate करता है
    • अगर किसी successful workflow में तीन steps हों, और उनमें से एक पाँच steps वाला subworkflow हो, तो rollup successful step count को 7 दिखाता है
    • rollup में सिर्फ leaf steps को aggregate किया जाता है, और बाकी steps को किसी concrete workflow की ओर इशारा करने वाले pointer के रूप में माना जाता है
    • unsuccessful steps के references भी सुरक्षित रखे जाते हैं, ताकि nested workflow के अंदर problem step तक पहुँचा जा सके
    • aggregated rollup की गणना current run के runtime data और base rollup को combine करके की जाती है
    • subworkflow step का rollup subworkflow instance के rollup को जैसा है वैसा reflect करता है
    • foreach step का rollup पिछली execution से restart-target iterations को छोड़कर base rollup और current execution में चल रहे iterations के rollups को combine करता है
    • इस प्रक्रिया के कारण rollup model eventually consistent होता है, और nested foreach और subworkflow कई levels तक हों तो calculation complex और recursive हो सकती है

Event Publishing और External Integration

  • जब workflow definition, workflow instance, या step instance बदलते हैं, तो Maestro events generate करता है और internal processing के बाद उन्हें external systems में publish करता है
  • Maestro events को internal events और external events में बाँटा जाता है
    • internal event: workflow, workflow instance, और step instance lifecycle के internal changes को track करता है और internal queue में publish होता है
    • external event: downstream services द्वारा consume की जाने वाली Maestro status change information रखता है और SNS·Kafka जैसी external queues में भेजा जाता है
  • Maestro event processor internal queue को subscribe करके internal events लाता है, event type के अनुसार उन्हें process करता है, और जरूरत पड़ने पर external event में convert करता है
  • आखिरी चरण का notification publisher external events publish करता है ताकि downstream services उन्हें consume कर सकें
  • downstream services ज्यादातर event-driven होती हैं, और Maestro event में Maestro के विभिन्न changes detect करने के लिए जरूरी messages होते हैं
  • change types को broadly दो categories में बाँटा जाता है
    • workflow change: workflow-level actions, जैसे workflow definition या properties में बदलाव
    • instance status change: workflow instance या step instance की status transition

शुरू करने का तरीका

  • Maestro code github.com/Netflix/maestro पर देखा जा सकता है
  • सवाल, राय या comments Maestro repository के GitHub issue में छोड़े जा सकते हैं
  • Netflix उम्मीद करता है कि Maestro की scalability और usability Netflix के बाहर workflow development को भी तेज कर सकेगी

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

1 टिप्पणियां

 
GN⁺ 2024-07-24
Hacker News की राय

  • पहले मैं ऐसे corporate tech blogs और internal proprietary systems से प्रभावित हो जाता था, लेकिन अब नहीं। क्योंकि code debt होता है
    cron/Celery/Airflow जैसी चीज़ों को फिर से बनाने के बजाय, मैं ऐसा स्थापित open source इस्तेमाल करना चाहूंगा जिसका maintenance और improvement का लंबा इतिहास हो। आखिर किसी को उसे maintain करना, bugs ठीक करना और features जोड़ना पड़ता है। हाँ, अगर उसके साथ promotion और salary/RSU बढ़ोतरी मिले तो बात अलग है
    यह समझना चाहिए कि जो code कंपनी के लिए पैसा कमाने वाले core काम का हिस्सा नहीं है, वह ध्यान भटकाने वाला और resources खा जाने वाला बोझ बन सकता है

    • शायद यही वजह है कि यह blog post आई है। वे इस software को open source कर रहे हैं ताकि अब इसे पूरी तरह internal तौर पर maintain न करना पड़े
      इसे इसलिए बनाया गया क्योंकि मौजूदा off-the-shelf open source उनकी ज़रूरत पूरी नहीं कर पा रहा था, और अब वे इसे फिर से स्थापित open source के रूप में बदलकर इस्तेमाल जारी रखते हुए maintenance का बोझ बाँटना चाहते हैं। ऐसे tools शुरू से अपने आप पैदा नहीं हो जाते, किसी न किसी को उन्हें बनाना ही पड़ता है
    • “code debt है” वाला नज़रिया बहुत ज़्यादा अतिवादी है, और दुनिया की हर चीज़ को MBA-शैली में min-max करने वाली सोच से गहराई से जुड़ा है
      अच्छा है कि अब भी ऐसे लोग हैं जो नए systems बनाने और नए ideas को आगे बढ़ाने से डरते नहीं। कंपनी के नज़रिए से भी सिर्फ साधारण और risk-averse solutions से काम नहीं चलता। सबसे ज़्यादा लाभ कमाने वाली कंपनियाँ अक्सर तकनीकी रूप से काफ़ी साहसी होती हैं
      code debt नहीं है, बल्कि वही कंपनी के gears चलाता है
    • स्थापित open source भी अक्सर बड़ी कंपनियों के internal tools को public करने का नतीजा होता है। आपने जिस Airflow का ज़िक्र किया, वह अच्छा उदाहरण है, और इस क्षेत्र में Temporal भी वैसा ही है। कुछ नया बनाने लायक “मूर्ख” किसी को तो होना पड़ता है
    • “maintenance और improvement का लंबा इतिहास” वाली बात अपने साथ बहुत बड़ा assumption लेकर चलती है
      यह जानने की जिज्ञासा है कि क्या आप खुद community में contribute करने की भी योजना रखते हैं। build बनाम buy की बहस हमेशा महत्वपूर्ण रहती है, लेकिन यह मान लेना कि ‘buy’ वाले विकल्प में maintenance और reliability की लागत बिल्कुल 0 है, काफ़ी भोला लगता है
    • “जो कंपनी के core business का हिस्सा नहीं है” यह शर्त महत्वपूर्ण है। performance-critical क्षेत्र में काम करने वाली अनुभवी टीम के लिए वह turning point ज़्यादा दूर नहीं होता जहाँ बाहरी code low-quality/low-control debt में बदल जाता है

  • सोचता हूँ कि engineers को workflow solutions से सच में संतुष्ट होने में और कितनी iterations लगेंगी। Netflix के पास Maestro से पहले भी Metaflow जैसे कई solutions थे, Uber ने भी कई solutions बनाए, और Amazon के भीतर कम से कम दर्जन भर internal workflow engines थे
    यह दिलचस्प है कि कई कंपनियों के इतने लोग workflow engine बनाना चाहते हैं। यह किसी या Netflix को नीचा दिखाने वाली बात नहीं है, बस हल्के-फुल्के तौर पर की जा सकने वाली एक observation है

    • समस्या यह है कि workflow orchestration बहुत व्यापक problem space है। कंपनियों को अलग-अलग तरह की समस्याएँ हल करनी पड़ती हैं, इसलिए कोई भी solution बहुत सारे संबंधित features वाला विशाल product बन जाता है, और बढ़ते-बढ़ते एक मज़बूत दर्शन वाला बड़ा monolith बन जाना आसान होता है। इसलिए लगभग कोई भी पूरी तरह संतुष्ट नहीं होता
      असल में पाँच मुख्य चिंताएँ हैं: resource scheduling, dependency resolution, tasks और workflows बनाने के लिए API/DSL, cron जैसी scheduled execution, और ETL या ML/AI workflows में domain information को सामने लाने वाली domain awareness
      ऐसा कोई एकल solution नहीं है जो यह सब कुछ साफ़-सुथरे ढंग से कर दे। इसलिए कंपनियाँ मौजूदा off-the-shelf विकल्पों की कमियाँ भरने के लिए खुद बनाती हैं या workaround करती हैं, और सबकी असंतुष्टि का यह चक्र चलता रहता है
      मुझे नहीं लगता कि यह ऐसा मसला है जिसे कोई एक startup “solution” बनाकर हल कर दे। इसे अच्छे plug-in modules से बने open source ecosystem के ज़रिए हल करना होगा
    • Metaflow, Maestro के ऊपर चलता है; दोनों में से कोई भी दूसरे का replacement नहीं है
      “Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code.” यह https://netflixtechblog.com/orchestrating-data-ml-workflows-... में लिखा है
      इस लेख के orchestration section(https://netflixtechblog.com/supporting-diverse-ml-systems-at...) में विस्तार से बताया गया है कि Metaflow, Maestro, Airflow, Argo Workflows, और Step Functions के साथ कैसे फिट बैठता है
    • हमने अपना workflow engine बनाया था, लेकिन उसमें इतने bugs थे और वह पर्याप्त flexible भी नहीं था कि उसने लगभग एक असंबंधित project को बिगाड़ ही दिया था
      अब मुझे लगने लगा है कि workflow engine कुछ हद तक design smell हो सकता है। एक बार कुछ reusable बना लेने पर यह आकर्षक लगता है कि उसे अनगिनत workflows में इस्तेमाल किया जा सकेगा, लेकिन दो से अधिक asynchronous stages की ज़रूरत होने के अलावा workflows में लगभग कुछ भी common नहीं होता
      data अलग होता है, API अलग होते हैं, और आगे बढ़ते रहने के लिए users या दूसरे systems से मिलने वाला feedback भी अलग होता है
    • शायद इसलिए कि अभी तक हमें ऐसा workflow engine/orchestrator नहीं मिला जो विविध तरह के काम संभाल सके और फिर भी समझने और चलाने में आसान हो
      किसी खास use case के लिए optimized custom workflow engine बनाना वास्तव में बहुत आसान है। अभी तक convergence न होने की वजह शायद यही है कि ऐसा tool अभी बना ही नहीं है
      हाल के उन tools को देखें जिन्होंने अपने-अपने क्षेत्रों पर तेज़ी से कब्ज़ा किया: Terraform ने IaC में और Kubernetes ने distributed computing की कठिन समस्याएँ हल कीं। दोनों बहुत complex हैं, लेकिन कठिन समस्याएँ सुलझाते हैं। इसके उलट, general-purpose workflow engines समझने में complex, operate करने में कठिन, और experience के स्तर पर भी अस्पष्ट हैं, इसलिए बहुत से लोग कोशिश ही नहीं करते
    • naming, cache invalidation, और workflow engines, है न? :)
      https://github.com/meirwah/awesome-workflow-engines

  • मैं https://windmill.dev का संस्थापक हूँ, और Windmill में Maestro से काफी समानताएँ हैं
    Maestro के विवरण में जो हिस्सा है — “बड़े पैमाने के workflows, data pipelines, और ML model training pipelines को मैनेज करने वाला general-purpose horizontally scalable workflow orchestrator” — उसे Windmill से बदल दें, तब भी वह बिल्कुल सही रहेगा। वे जिस rollup की बात कर रहे हैं, उसे हम openflow state कहते हैं
    मुख्य अंतर यह है कि Windmill Java की जगह Rust में लिखा गया है, और Maestro state storage के लिए CockroachDB का इस्तेमाल करता है, जबकि हम state और queue दोनों के लिए PostgreSQL इस्तेमाल करते हैं। हालांकि, CockroachDB इस्तेमाल करने की वजह समझ में आती है। Windmill को भी बहुत बड़े customer instances में horizontal scaling के लिए अपना sharding algorithm बनाना पड़ा था
    Maestro Apache 2.0 है और Windmill कम अनुकूल AGPL पर है। Netflix के समर्थन के कारण उनके पास लगभग असीमित funding है, जबकि हम revenue कमा रहे होने के बावजूद बहुत छोटी कंपनी हैं
    Maestro के पास Kubernetes या docker-compose आधारित self-hosting docs पर्याप्त नहीं हैं, और कुछ बनाने के लिए UI नहीं है, या कम-से-कम docs में अभी साफ़ दिखाई नहीं देता। फिर भी, कुल मिलाकर इसे open source के रूप में जारी करना काफ़ी शानदार है, और मैं इसे देखते रहूँगा और जितनी जल्दी हो सके benchmark करने की योजना है

    • अगर आप Windmill पर विचार कर रहे हैं, तो पहले यह देखना चाहिए: https://www.windmill.dev/docs/advanced/local_development
      समझ नहीं आता कि Windmill के साथ “sync” क्यों करना चाहिए, Windmill के अंदर IDE क्यों है, और यह इतना जटिल क्यों है। ऐसा लगता है जैसे अच्छे product या market fit खोजने से पहले ही lock-in effect को लक्ष्य बनाकर शुरुआत की गई हो
    • तुलना अच्छी है, लेकिन अगर Maestro Apache license पर होने के बावजूद CockroachDB पर निर्भर है, तो यह बहुत अच्छा नहीं है क्योंकि CockroachDB खुद open source नहीं है
      मेरी नज़र में non-open-source dependency से AGPL codebase बेहतर है। बेशक, समय के साथ कोई alternative database support जोड़ सकता है

  • यहाँ क्या हो रहा है, इसे लेकर मैं थोड़ा उलझन में हूँ। यह project Netflix/conductor [0] का इस्तेमाल करता दिखता है। लेकिन उस repository पर जाने पर एक संदेश दिखता है कि उसे archive कर दिया गया है, और उसे Netflix के internal non-open-source version और एक बिना नाम लिए गए community fork से बदल दिया गया है। शायद इसका मतलब Orkes Conductor [1] है
    लेकिन यह Orkes Conductor का इस्तेमाल नहीं करता दिखता, बल्कि बंद किए गए Netflix version com.netflix.conductor:conductor-core:2.31.5 [2] का इस्तेमाल करता लगता है। और वह भी काफ़ी पुराना version है
    [0] https://github.com/Netflix/conductor
    [1] https://github.com/conductor-oss/conductor
    [2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...

    • सही है। Netflix ने बहुत पहले Conductor को छोड़ दिया था [0]। दूसरी repository वही है जिसे Netflix के छोड़ने के बाद Orkes ने बनाया और maintain किया
      [0] https://techcrunch.com/2023/12/13/orkes-forks-conductor-as-n...

  • जानना चाहता हूँ कि क्या किसी ने ActiveBatch इस्तेमाल किया है। मेरे लिए यह ऐसा बेहतरीन software है जिसका non-enterprise users के लिए कोई बराबरी का विकल्प होना चाहिए
    मैं बार-बार दूसरे “competitors” आज़माना चाहता था, लेकिन ActiveBatch में बस एक साधारण MS SQL DB जोड़कर, Windows GUI और execution agents install करके, कुछ clicks में एक मज़बूत GUI-आधारित automation environment तैयार हो जाता है। आपको code लिखने की ज़रूरत नहीं होती, और चाहें तो किसी भी language में code लिख सकते हैं
    Airflow शक्तिशाली हो सकता है, लेकिन वह complexity की दीवार के पीछे छिपा रहता है, इसलिए उसकी असली क्षमता चाहे जो भी हो, ज़्यादातर लोग उसे देख नहीं पाते। दूसरे “open source” competitors के साथ भी यही बात है
    समझ नहीं आता कि कोई मज़बूत DB-based GUI-first system क्यों नहीं बना पाया। मैंने online services भी इस्तेमाल की हैं, लेकिन उनकी तुलना ही नहीं की जा सकती। हो सकता है कि सरल paid products इसलिए विफल होते हों क्योंकि extensions को maintain करने की लागत बहुत ज़्यादा होती है
    यह सचमुच अफ़सोस की बात है कि ActiveBatch एक बेवकूफ़ाना enterprise sales model के पीछे फँसा हुआ है। यही इस शानदार software को बड़े community तक पहुँचने से रोकता है। यह किसी छिपे हुए रहस्य जैसा है

  • सलाह के तौर पर कहूँ तो Netflix द्वारा open source किए गए tools पर निर्भर न रहना बेहतर है। announce करने के बाद support बंद कर देने की उनकी मिसालें लंबी रही हैं
    किसी को शायद इस blog post और code release से promotion scorecard पर एक check mark मिल गया होगा, लेकिन ऐसी solution पर business नहीं बनाना चाहिए

  • Temporal जैसे ज़्यादा स्थापित विकल्प के बजाय इसे क्यों consider करना चाहिए, यह समझ नहीं आ रहा। Maestro Java में लिखा गया है, और Temporal शायद Go में लिखा गया है

    • Temporal का Go code थोड़ा अजीब लगता है। लगता है पहले Java इस्तेमाल करता था, फिर Go पर बदला, और वह Go बहुत Java-जैसा दिखता है
      या हो सकता है कि मुझे Fx की अच्छी समझ न हो
      https://github.com/temporalio/temporal/blob/main/service/mat...
      Temporal के साथ बार-बार जो समस्या आई, वह यह है कि इसकी documentation बहुत कम है। यह ऐसी चीज़ है जिसे business core में install किया जाता है, लेकिन कई layers और बहुत कठिन documentation के बीच से गुजरकर वास्तव में क्या हो रहा है यह समझना सच में मुश्किल है
      Maestro में तो documentation है ही नहीं, ऐसा लगता है। अगर ऐसा है, तो Temporal की default जीत है
    • Netflix भी Temporal का उपयोग करता है: https://temporal.io/in-use/netflix
    • मुझे लगता है Maestro, Temporal का alternative नहीं बल्कि Airflow का alternative है। Temporal workflow orchestrator नहीं है। अंदरूनी structure में कुछ overlap है, लेकिन ये अलग use cases के लिए अलग design हैं
    • क्या Temporal के कुछ core हिस्से Rust में दोबारा नहीं लिखे गए थे?

  • यह सच में बहुत अच्छा दिखने वाला project है। जिन लगभग सभी ML + डेटा इंजीनियरिंग mixed projects पर मैंने काम किया है, उनमें मैंने इसके लगभग इसी तरह के, शायद इससे भी खराब version को बनाने पर कभी न कभी सोचा है
    इसे सीधे test करके देखने का इंतज़ार है

  • मैं इस क्षेत्र में orchestra बना रहा हूँ, तो अपनी राय लिखूँ तो open source बनाना और public में develop करना निश्चित रूप से शानदार है। लेकिन जैसा यह खुद भी कहता है, यह एक orchestrator है, और Airflow वगैरह सहित इस क्षेत्र में पहले से ही बहुत कुछ मौजूद है
    इसलिए commercial environment में शायद कोई इस्तेमाल न करे, ऐसे एक और विकल्प को जोड़ने के अलावा यह इस क्षेत्र में वास्तव में क्या नया जोड़ता है, यह देखना मुश्किल है
    बेशर्म प्रचार: https://getorchestra.io

  • जिज्ञासा है कि क्या यह पहले archive किए गए Conductor से किसी मायने में अलग है। Code को सरसरी तौर पर देखने पर काफी समानताएँ दिखती हैं, और workflow definition language के लिए JSON इस्तेमाल करने वाली बात भी वही है