Maestro: Orkestrator Workflow Netflix

 (netflixtechblog.com)
4 poin oleh GN⁺ 2024-07-24 | 1 komentar | Bagikan ke WhatsApp
  • Netflix merilis Maestro, orkestrator yang dapat diskalakan secara horizontal untuk workflow Data/ML skala besar sebagai open source, dan secara internal telah memigrasikan serta mengoperasikan ratusan ribu workflow dengan gangguan minimal
  • Berbeda dari orkestrator yang berpusat pada DAG, Maestro menangani workflow asiklik dan siklik sekaligus, serta menyediakan pola seperti loop foreach, subworkflow, dan percabangan kondisional di tingkat engine
  • Selama satu tahun terakhir, jumlah pekerjaan yang dieksekusi naik 87,5%, dan saat ini menjalankan ribuan instance workflow per hari serta sekitar 500 ribu pekerjaan, dengan sekitar 2 juta pekerjaan selesai pada hari-hari sibuk
  • Definisi berbasis JSON menggabungkan strategi eksekusi, parameter, ekspresi SEL, sinyal, breakpoint, timeline, kebijakan retry, dan rollup untuk mendukung kontrol operasional dan debugging
  • Di lingkungan seperti Netflix, tempat tabel data terkonsentrasi dalam satu data warehouse, membagi workflow ke beberapa cluster meningkatkan biaya koordinasi dan menurunkan pengalaman pengguna, sehingga arsitektur dengan satu orkestrator yang menangani seluruh alur menjadi penting

Pembukaan kode Maestro dan skala operasional di Netflix

  • Netflix membuka kode sumber Maestro melalui Maestro GitHub repository
  • Maestro adalah orkestrator workflow yang dapat diskalakan secara horizontal untuk mengelola workflow Data/ML skala besar seperti pipeline data dan pipeline pelatihan model machine learning
  • Maestro mengelola seluruh siklus hidup workflow dari awal hingga akhir, termasuk menangani retry, queueing, dan distribusi pekerjaan ke compute engine
  • Pengguna dapat mengemas logika bisnis dalam berbagai format seperti image Docker, notebook, skrip bash, SQL, dan Python
  • Setelah sebelumnya memperkenalkannya, Netflix telah memigrasikan ratusan ribu workflow ke Maestro dan meminimalkan gangguan pengguna selama proses transisi
  • Skala operasional terbaru:
    • Selama satu tahun terakhir, jumlah pekerjaan yang dieksekusi naik 87,5%
    • Menjalankan ribuan instance workflow per hari secara rata-rata
    • Menjalankan sekitar 500 ribu pekerjaan per hari secara rata-rata
    • Menyelesaikan sekitar 2 juta pekerjaan pada hari-hari sibuk

Mendukung skalabilitas dan keragaman dengan satu orkestrator

  • Maestro adalah orkestrator terkelola penuh yang menyediakan Workflow-as-a-Service untuk ribuan end user, aplikasi, dan layanan di internal Netflix
  • Mendukung pipeline ETL, workflow ML, pipeline pengujian AB, serta pipeline perpindahan data antar berbagai storage
  • Arsitektur skala horizontal dirancang untuk menangani baik jumlah workflow yang besar maupun jumlah pekerjaan yang besar di dalam satu workflow
  • Workflow di Netflix saling terhubung erat, sehingga jika dibagi ke kelompok kecil dan dikelola di beberapa cluster, akan dibutuhkan mekanisme koordinasi tambahan dan pengalaman pengguna menurun
  • Karena tabel data berada dalam satu data warehouse, Netflix menilai semua workflow yang mengaksesnya harus ditangani oleh satu orkestrator

Model definisi workflow

  • Definisi workflow Maestro ditulis dalam format JSON
  • Definisi orkestrasi disusun dengan menggabungkan field yang disediakan pengguna dan field yang dikelola Maestro, dengan contoh di Maestro repository wiki
  • Definisi workflow secara garis besar dibagi menjadi dua area
    • properties: memuat informasi author/pemilik dan pengaturan eksekusi
    • versioned workflow: memuat metadata workflow dan definisi graph
  • properties mempertahankan atribut inti seperti informasi author/pemilik, strategi eksekusi, dan pengaturan konkurensi meskipun versi workflow berubah
  • Jika kepemilikan berubah, pemilik baru dapat mengambil alih kepemilikan workflow yang ada tanpa membuat versi workflow baru
  • versioned workflow mencakup identifier unik, nama, deskripsi, tag, pengaturan timeout, dan tingkat criticality low, medium, high untuk prioritisasi
  • Perubahan workflow dibuat sebagai versi baru, dan secara default versi aktif atau versi terbaru yang digunakan
  • Workflow terdiri dari step yang menjadi node pada graph yang didefinisikan pengguna
    • Step dapat merepresentasikan pekerjaan, workflow lain melalui subworkflow step, atau loop melalui foreach step
    • Step mencakup identifier unik, tipe step, tag, parameter input/output, dependensi, kebijakan retry, mode kegagalan, dan output step
    • Mendukung kebijakan retry yang dapat dikonfigurasi menurut jenis error

Run Strategy untuk mengontrol urutan eksekusi

  • Maestro menggunakan run strategy yang telah ditentukan sebelumnya untuk memutuskan apakah instance workflow baru akan dijalankan

  • Sequential Run Strategy

    • Merupakan strategi default, menjalankan satu per satu dalam urutan FIFO
    • Terlepas dari keberhasilan eksekusi sebelumnya, instance berikutnya di antrean akan dimulai ketika sebuah instance mencapai status akhir seperti sukses atau gagal

  • Strict Sequential Run Strategy

    • Menjalankan sesuai urutan pemicu, tetapi akan memblokir eksekusi jika riwayat instance sebelumnya memiliki blocking error
    • Instance baru tetap berada di antrean sampai instance yang gagal di-restart secara manual atau di-unblock
    • Berguna untuk workflow yang sensitivitas waktunya rendah tetapi penting bagi bisnis

  • First-only Run Strategy

    • Tidak menyimpan instance baru di antrean sebelum workflow yang sedang berjalan selesai
    • Jika ada instance yang sedang berjalan, instance baru yang masuk antrean akan dihapus sehingga queueing praktis dimatikan
    • Membantu menghindari masalah idempotensi karena tidak menumpuk instance baru

  • Last-only Run Strategy

    • Memastikan instance yang paling baru dipicu selalu yang dijalankan
    • Jika sudah ada instance yang sedang berjalan, instance tersebut dihentikan dan instance yang baru dipicu dijalankan
    • Berguna saat hanya data terbaru yang dibutuhkan, seperti pada workflow yang memproses snapshot terbaru dari seluruh tabel setiap kali berjalan

  • Parallel with Concurrency Limit Run Strategy

    • Menjalankan beberapa instance secara paralel dalam batas konkurensi yang telah ditentukan
    • Dapat melakukan fan-out dan mendistribusikan eksekusi agar banyak data diproses dalam batas waktu tertentu
    • Backfill data lama adalah kasus penggunaan yang umum

Parameter dan ekspresi SEL

  • Di Maestro, parameter digunakan untuk mengontrol logika eksekusi, berbagi status antara workflow dan step, serta berbagi status antara step upstream dan downstream
  • Maestro mendukung parameter dinamis dengan code injection, sehingga memungkinkan definisi workflow dengan parameterisasi yang kompleks
  • Code injection dapat menimbulkan risiko keamanan dan stabilitas
    • Jika pengguna menulis loop tak berujung yang terus menambahkan item ke array, server bisa berhenti karena OOM
    • Jika kode injeksi dipindahkan ke dalam logika bisnis, beban pengguna meningkat dan definisi workflow menjadi sangat terikat dengan logika bisnis
  • Untuk meredam hal ini, Netflix mengembangkan bahasa ekspresi sendiri bernama SEL (Simple, Secure, and Safe Expression Language)
  • SEL mengikuti grammar dan sintaks Java Language Specifications, tetapi hanya mendukung subset yang disesuaikan untuk use case Maestro
  • SEL mendukung tipe data untuk tipe parameter Maestro, penanganan error, pemrosesan tanggal dan waktu, serta utility method bawaan
  • Demi stabilitas, SEL mencakup pemeriksaan runtime seperti batas iterasi loop, pemeriksaan ukuran array, dan batas ukuran memori objek
  • Dokumentasi SEL tersedia di Maestro GitHub documentation

Parameter output dan workflow terparameterisasi

  • Maestro memungkinkan hasil eksekusi pengguna dikembalikan ke sistem sebagai parameter output melalui callable step execution
  • Data output dikirim melalui Maestro REST API, dan runtime step tidak mengakses database Maestro secara langsung
  • Workflow statis memang sederhana, tetapi untuk mencerminkan perbedaan kecil mungkin perlu menduplikasi workflow yang sama berkali-kali, dan tanpa parameter workflow serta pekerjaan tidak dapat berbagi status
  • Workflow yang sepenuhnya dinamis sulit dikelola dan didukung, serta menyulitkan debugging, troubleshooting, dan penggunaan ulang
  • Workflow terparameterisasi diinisialisasi per step pada saat runtime berdasarkan parameter yang ditentukan pengguna, sehingga memberikan fleksibilitas kontrol saat eksekusi sekaligus kemudahan pengelolaan
  • Dukungan parameter di Maestro memungkinkan pembuatan workflow terparameterisasi yang kompleks seperti pipeline data backfill

Pola eksekusi workflow di tingkat engine

  • Maestro mendukung langsung dataflow umum dan pola workflow di dalam engine
  • Dukungan langsung dari engine memungkinkan optimasi pola dan cara implementasi yang konsisten

  • Foreach

    • Pola foreach awalnya dimodelkan sebagai step khusus di dalam definisi workflow
    • Setiap iterasi dalam loop foreach secara internal diproses sebagai instance workflow terpisah
    • Eksekusi step di dalam blok definisi foreach, yaitu eksekusi sub-graph, didelegasikan ke instance workflow terpisah
    • Step foreach memantau dan mengumpulkan status instance workflow yang menangani tiap iterasi
    • Sering digunakan untuk backfill data atau tuning model machine learning yang menjalankan pekerjaan yang sama dengan parameter berbeda per iterasi
    • Pengguna tidak perlu menulis ratusan ribu iterasi langsung di definisi workflow, dan kebutuhan membuat workflow baru saat cakupan foreach berubah juga berkurang

  • Conditional Branch

    • Percabangan kondisional membuat step berikutnya hanya dijalankan ketika kondisi tertentu dari step upstream terpenuhi
    • Kondisi didefinisikan dengan ekspresi SEL dan dievaluasi saat runtime
    • Dapat menyusun alur yang melakukan pekerjaan pemulihan saat step audit check gagal, lalu menjalankan kembali pekerjaan tersebut

  • Subworkflow

    • subworkflow memungkinkan satu step workflow menjalankan workflow lain sehingga fungsi umum bisa dibagikan di beberapa workflow
    • Dapat menyusun graf workflow dalam bentuk “workflow as a function”
    • Di Netflix, juga ditemukan workflow kompleks yang terdiri dari ratusan subworkflow untuk memproses data dari ratusan tabel dengan mengombinasikan subworkflow yang disediakan beberapa tim
    • foreach, percabangan kondisional, dan subworkflow dapat digabungkan bersama
    • Sekumpulan subworkflow dapat diproses dalam loop
    • Loop foreach bertingkat dapat dijalankan
    • Dengan memakai percabangan kondisional dan subworkflow bersama, dapat dibuat workflow pemulihan otomatis yang menangani error dan me-retry pekerjaan secara otomatis

Step Runtime dan penggabungan parameter

  • Maestro menggunakan step runtime untuk mendeskripsikan pekerjaan pada saat eksekusi
  • Antarmuka step runtime mendefinisikan dua jenis informasi
    • Kumpulan API dasar yang mengontrol perilaku eksekusi dari instance step
    • Struktur data sederhana yang melacak status runtime step dan hasil eksekusi
  • Maestro menyediakan implementasi seperti foreach step runtime dan subworkflow step runtime
  • Tiap implementasi mendefinisikan logikanya sendiri untuk perilaku start, execute, dan terminate
  • Status runtime digunakan untuk menentukan transisi status berikutnya dari step dan menilai apakah terjadi kegagalan atau terminasi
  • Hasil eksekusi memuat artefak step dan timeline riwayat eksekusi step, dan dapat diakses oleh step berikutnya

  • Step Parameter Merging

    • Maestro mendukung runtime parameter dan injeksi tag untuk mengontrol perilaku step secara dinamis
    • Map parameter step pada awalnya kosong, lalu digabungkan dalam urutan berikut
    • Default General Parameters: parameter dasar untuk semua step seperti workflow_instance_id, step_instance_uuid, step_attempt_id, step_id, dan dipakai sebagai nilai reservasi internal Maestro sehingga tidak bisa diberikan oleh pengguna
    • Injected Parameters: parameter yang dibuat secara dinamis di step runtime dan dapat berbeda menurut schema tiap tipe step
    • Default Typed Parameters: parameter default yang terkait dengan tipe step tertentu, misalnya loop_params dan loop_index pada step foreach
    • Workflow and Step Info Parameters: informasi identifikasi terkait step dan workflow seperti workflow_id
    • Undefined New Parameters: parameter step baru yang ditentukan pengguna saat memulai atau me-restart instance workflow
    • Step Definition Parameters: parameter step yang ditulis pengguna saat definisi dibuat
    • Run and Restart Parameters: nilai yang diberikan pengguna saat start atau restart untuk menimpa parameter definisi yang sudah ada, dan digabungkan paling akhir

Step Dependencies dan Signal

  • Step dalam graf workflow Maestro dapat mengekspresikan ketergantungan eksekusi dengan step dependency
  • step dependency menetapkan kondisi terkait data yang dibutuhkan untuk eksekusi step
  • Kondisi biasanya didefinisikan berdasarkan signal
  • Signal adalah pesan yang memuat informasi seperti nilai parameter, dan dapat dipublikasikan melalui output step atau sistem eksternal seperti SNS dan Kafka
  • Signal digunakan baik pada pola trigger maupun pada pola signal dependency berbentuk publisher-subscriber
  • Satu step dapat menerbitkan output signal untuk membuka eksekusi beberapa step yang bergantung pada signal tersebut
  • Signal definition mencakup daftar parameter yang dipetakan, dan Maestro dapat melakukan signal matching hanya dengan sebagian field
  • Maestro mendukung signal operators seperti < dan > untuk nilai parameter signal
  • Netflix membangun beberapa abstraksi di atas konsep signal
    • Saat workflow ETL memperbarui tabel dan mengirim signal, step workflow downstream yang bergantung pada data tersebut dapat dijalankan
    • signal lineage memungkinkan penelusuran instance signal terdahulu dan step workflow yang menerbitkan atau mengonsumsi signal tersebut
    • signal trigger menjamin exactly-once execution untuk workflow yang berlangganan satu signal atau sekumpulan signal yang digabungkan
  • Karena workflow atau step hanya dijalankan saat kondisi signal yang ditentukan terpenuhi, resource dapat dihemat

Debugging dan visibilitas eksekusi

  • Breakpoint

    • Maestro memungkinkan pengaturan breakpoint pada step workflow
    • Ketika instance workflow mencapai step yang diberi breakpoint, step tersebut masuk ke status paused
    • Progres graf workflow berhenti sampai pengguna melanjutkannya secara manual
    • Jika beberapa instance dari step workflow yang sama berhenti di breakpoint, melanjutkan satu instance hanya memengaruhi instance itu saja dan sisanya tetap dalam status paused
    • Jika breakpoint dihapus, semua instance step yang sempat berhenti akan dilanjutkan
    • Berguna untuk memeriksa eksekusi step dan data output selama pengembangan awal workflow
    • Dalam pola foreach, jika breakpoint dipasang pada satu step, semua iterasi akan berhenti di step tersebut untuk debugging
    • Juga dapat digunakan untuk mendukung intervensi manusia selama eksekusi atau perubahan status step saat berjalan

  • Timeline

    • Maestro menyertakan timeline eksekusi step yang mencatat event penting seperti perubahan state machine dan alasannya
    • Contoh event mencakup transisi seperti Created dan Evaluating params
    • step runtime yang diimplementasikan dapat menambahkan event timeline untuk menampilkan informasi eksekusi kepada pengguna akhir
    • Contoh timeline tersedia di sample-step-instance-failed.json

Retry, Aggregated View, Rollup

  • Kebijakan Retry

    • Maestro mendukung kebijakan retry untuk step yang berakhir gagal dan mencapai status terminal
    • Pengguna dapat mengatur jumlah retry, jeda antar-retry, retry dengan interval tetap, dan strategi exponential backoff
    • Retry dibagi menjadi dua jenis
    • platform retry: penanganan error tingkat platform yang tidak terkait dengan logika pengguna
    • user retry: retry berdasarkan kondisi yang ditentukan pengguna
    • Masing-masing jenis dapat memiliki kebijakan retry terpisah
    • Retry otomatis berguna untuk menangani error sementara yang dapat diselesaikan tanpa campur tangan pengguna
    • Untuk step yang tidak idempoten, jumlah retry dapat diatur ke 0 agar retry dihindari

  • Aggregated View

    • Karena satu workflow instance dapat memiliki beberapa run, pengguna harus bisa melihat status agregat dari semua step
    • aggregated view dihitung dengan menggabungkan aggregated view dasar dan status step dari run saat ini
    • Misalnya, jika pada eksekusi pertama step1 dan step2 berhasil, step3 gagal, dan step4 serta step5 belum dimulai, maka restart akan dimulai dari step3 dan step1 serta step2 dapat dilewati karena status berhasil sebelumnya
    • Jika semua step berhasil, aggregated view akan menampilkan status run dari seluruh step

  • Rollup

    • rollup memberikan ringkasan tingkat tinggi dari workflow instance, serta menampilkan status tiap step dan jumlah step per status
    • Rollup dihitung dengan membuka step pada instance saat ini dan workflow non-inline bertingkat seperti subworkflow dan foreach
    • Jika sebuah workflow yang berhasil memiliki tiga step, dan salah satunya adalah subworkflow dengan lima step, maka rollup akan menampilkan jumlah step berhasil sebanyak 7
    • Dalam rollup, hanya leaf step yang dihitung, sementara step lainnya diperlakukan sebagai pointer yang mengarah ke workflow tertentu
    • Referensi ke step yang tidak berhasil juga dipertahankan agar pengguna dapat berpindah ke step bermasalah di dalam workflow bertingkat
    • Aggregated rollup dihitung dengan menggabungkan runtime data dari run saat ini dan base rollup
    • Rollup dari subworkflow step langsung mencerminkan rollup dari subworkflow instance
    • Rollup dari foreach step menggabungkan base rollup dari eksekusi sebelumnya, dengan mengecualikan iterasi yang menjadi target restart, dan rollup dari iterasi yang sedang berjalan pada eksekusi saat ini
    • Karena proses ini, model rollup bersifat eventually consistent, dan jika nested foreach serta subworkflow masuk beberapa tingkat, perhitungannya bisa menjadi kompleks dan rekursif

Penerbitan event dan integrasi eksternal

  • Saat definisi workflow, workflow instance, atau step instance berubah, Maestro membuat event, memprosesnya secara internal, lalu menerbitkannya ke sistem eksternal
  • Event Maestro dibagi menjadi event internal dan event eksternal
    • internal event: melacak perubahan internal dalam siklus hidup workflow, workflow instance, dan step instance, lalu diterbitkan ke antrean internal
    • external event: memuat informasi perubahan status Maestro yang dikonsumsi layanan downstream, lalu dikirim ke antrean eksternal seperti SNS dan Kafka
  • Maestro event processor berlangganan ke antrean internal untuk mengambil internal event, memprosesnya sesuai jenis event, lalu jika perlu mengubahnya menjadi external event
  • Pada tahap terakhir, notification publisher menerbitkan event eksternal agar dapat dikonsumsi oleh layanan downstream
  • Layanan downstream sebagian besar berbasis event, dan event Maestro memuat pesan yang diperlukan untuk mendeteksi berbagai perubahan di Maestro
  • Jenis perubahan secara umum dibagi menjadi dua kategori
    • workflow change: tindakan tingkat workflow seperti perubahan definisi workflow atau properties
    • instance status change: transisi status pada workflow instance atau step instance

Cara memulai

  • Kode Maestro dapat dilihat di github.com/Netflix/maestro
  • Pertanyaan, masukan, dan komentar dapat disampaikan melalui GitHub issue di repositori Maestro
  • Netflix berharap skalabilitas dan kemudahan penggunaan yang ditawarkan Maestro juga dapat mempercepat pengembangan workflow di luar Netflix

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-24
Opini Hacker News

  • Dulu saya kagum pada blog teknologi perusahaan seperti ini dan sistem internal yang proprietary, tetapi sekarang tidak lagi. Karena kode adalah utang
    Daripada membuat ulang sesuatu seperti cron/Celery/Airflow, saya lebih ingin memakai open source yang sudah jadi dengan riwayat pemeliharaan dan peningkatan yang panjang. Sebab harus ada orang yang memelihara, memperbaiki bug, dan menambahkan fitur. Tentu saja pengecualiannya jika itu diikuti promosi serta kenaikan gaji/RSU
    Kita perlu menyadari bahwa kode yang bukan pekerjaan inti yang menghasilkan uang bagi perusahaan adalah sesuatu yang memecah perhatian dan menghabiskan sumber daya

    • Sepertinya justru karena itulah posting blog ini muncul. Mereka ingin menjadikan perangkat lunak ini open source agar tidak lagi harus memeliharanya sepenuhnya hanya secara internal
      Mereka membuatnya karena ada kebutuhan yang tidak bisa dipenuhi oleh open source siap pakai yang sudah ada, dan sekarang prosesnya adalah mengubahnya kembali menjadi open source siap pakai agar tetap bisa digunakan sambil berbagi beban pemeliharaan. Bagaimana alat seperti ini bisa muncul sejak awal kalau tidak begitu; seseorang harus membuatnya
    • Sudut pandang “kode adalah utang” terlalu ekstrem, dan sangat terkait dengan pola pikir ala MBA yang ingin meminimalkan-memaksimalkan segala hal di dunia
      Untung ada orang-orang yang tidak takut membangun sistem baru dan mendorong ide baru. Dari sudut pandang perusahaan pun, solusi yang biasa-biasa saja dan menghindari risiko punya batas. Perusahaan yang paling menguntungkan cenderung cukup berani secara teknis
      Kode bukanlah utang, melainkan sesuatu yang memutar roda gigi perusahaan
    • Open source siap pakai pun sering kali merupakan hasil perusahaan besar membuka alat internal mereka. Airflow yang disebut langsung adalah contoh bagus, dan di area ini Temporal juga sama. Harus ada seseorang yang cukup “bodoh” untuk membuat sesuatu yang baru
    • Ungkapan “riwayat pemeliharaan dan peningkatan yang panjang” memikul asumsi yang sangat besar
      Saya penasaran apakah Anda juga berencana berkontribusi ke komunitas sendiri. Membuat atau membeli selalu merupakan diskusi penting, tetapi menganggap biaya pemeliharaan dan reliabilitas di pihak ‘membeli’ tepat 0 terasa naif
    • Syarat “yang bukan pekerjaan inti perusahaan” itu penting. Untuk tim berpengalaman di area yang kinerjanya penting, titik balik ketika kode eksternal berubah menjadi utang berkualitas rendah/kontrol rendah tidak terlalu jauh

  • Saya penasaran berapa iterasi lagi yang dibutuhkan sampai para engineer puas dengan solusi workflow. Netflix bahkan sebelum Maestro sudah punya beberapa solusi seperti Metaflow, Uber juga membuat beberapa solusi, dan di Amazon setidaknya ada belasan workflow engine internal
    Menarik bahwa banyak individu di berbagai perusahaan ingin membuat workflow engine. Ini bukan bermaksud merendahkan seseorang atau Netflix, hanya pengamatan yang layak dibicarakan ringan

    • Masalahnya adalah orkestrasi workflow merupakan ruang masalah yang sangat luas. Perusahaan harus menyelesaikan berbagai masalah yang berbeda-beda, sehingga solusi apa pun menjadi produk raksasa dengan banyak fitur terkait, dan seiring tumbuh mudah berubah menjadi monolit besar dengan filosofi yang kuat. Akibatnya hampir tidak ada yang puas
      Pada praktiknya ada lima perhatian inti: penjadwalan sumber daya, penyelesaian dependensi, API/DSL untuk membuat task dan workflow, eksekusi terjadwal seperti cron, serta kesadaran domain yang menampilkan informasi domain dalam workflow ETL atau ML/AI
      Tidak ada satu solusi tunggal yang menangani semua ini dengan rapi. Karena itu perusahaan membuat sendiri atau mencari jalan memutar untuk menutupi kekurangan produk siap pakai yang ada, dan siklus di mana semua orang terus tidak puas berlanjut
      Saya rasa ini bukan masalah yang bisa dibuat oleh satu startup sebagai “solusi”. Ini harus diselesaikan lewat ekosistem open source yang terdiri dari komponen modular plug-in yang baik
    • Metaflow berjalan di atas Maestro, dan salah satu dari keduanya tidak menggantikan yang lain
      Di https://netflixtechblog.com/orchestrating-data-ml-workflows-... tertulis, “Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code.”
      Bagian orkestrasi di artikel ini (https://netflixtechblog.com/supporting-diverse-ml-systems-at...) menjelaskan secara rinci bagaimana Metaflow terhubung dengan Maestro, Airflow, Argo Workflows, dan Step Functions
    • Saya pernah membuat workflow engine sendiri, tetapi bug-nya terlalu banyak dan terlalu tidak fleksibel sehingga hampir merusak satu proyek yang tidak terkait
      Saya mulai berpikir workflow engine sampai batas tertentu bisa jadi bau desain. Begitu membuat sesuatu yang dapat digunakan ulang, ia tampak menarik seolah bisa dipakai untuk banyak workflow, tetapi workflow-workflow itu hampir tidak punya kesamaan selain membutuhkan lebih dari satu tahap asinkron
      Datanya berbeda, API-nya berbeda, dan feedback yang harus diterima dari pengguna atau sistem lain agar bisa terus berjalan juga berbeda
    • Kemungkinan besar karena kita belum menemukan workflow engine/orkestrator yang bisa menangani beragam pekerjaan sekaligus mudah dipahami dan dioperasikan
      Membuat workflow engine khusus yang dioptimalkan untuk use case tertentu itu benar-benar mudah. Menurut saya alasan konvergensi belum terjadi adalah karena alat seperti itu belum dibuat
      Jika melihat alat-alat yang belakangan cepat mendominasi bidang masing-masing, Terraform memecahkan IaC, Kubernetes memecahkan masalah sulit dalam komputasi terdistribusi. Keduanya sangat kompleks, tetapi menyelesaikan masalah yang sulit. Sebaliknya, workflow engine serbaguna rumit untuk dipahami, sulit dioperasikan, dan pengalamannya pun ambigu, sehingga banyak orang tidak mencobanya sama sekali
    • Penamaan, invalidasi cache, dan workflow engine, ya? :)
      https://github.com/meirwah/awesome-workflow-engines

  • Saya adalah pendiri https://windmill.dev, dan Windmill punya banyak kesamaan dengan Maestro
    Bagian dalam penjelasan Maestro yang menyebut “orkestrator workflow serbaguna yang dapat diskalakan horizontal untuk mengelola workflow skala besar, pipeline data, dan pipeline pelatihan model ML” juga tepat sekali jika diganti menjadi Windmill. Apa yang mereka sebut rollup adalah hal yang kami sebut openflow state
    Perbedaan utamanya, Windmill ditulis dalam Rust alih-alih Java, dan Maestro memakai CockroachDB untuk penyimpanan state, sedangkan kami memakai PostgreSQL untuk state maupun antrean. Namun saya paham alasan mereka memakai CockroachDB. Windmill juga harus membuat algoritma sharding sendiri untuk penskalaan horizontal pada instance pelanggan yang sangat besar
    Maestro berlisensi Apache 2.0, sedangkan Windmill memakai AGPL yang kurang ramah. Dengan dukungan Netflix, pendanaannya praktis tak terbatas, sementara kami, meski sudah menghasilkan pendapatan, adalah perusahaan yang jauh lebih kecil
    Maestro belum punya dokumentasi self-hosting berbasis Kubernetes atau docker-compose yang memadai, dan tidak ada UI untuk membuat sesuatu, atau setidaknya belum tampak jelas di dokumentasinya. Meski begitu, secara keseluruhan cukup keren bahwa ini dirilis sebagai open source, dan kami akan terus memantau serta mencoba melakukan benchmark secepat mungkin

    • Jika mempertimbangkan Windmill, sebaiknya lihat ini dulu: https://www.windmill.dev/docs/advanced/local_development
      Saya tidak mengerti mengapa harus “sinkronisasi” dengan Windmill, mengapa ada IDE di dalam Windmill, dan mengapa semuanya serumit ini. Terlihat seperti sejak awal menargetkan lock-in bahkan sebelum membuat produk yang bagus atau menemukan kecocokan pasar
    • Perbandingannya bagus, tetapi meskipun Maestro berlisensi Apache, jika bergantung pada CockroachDB, itu kurang bagus karena CockroachDB sendiri bukan open source
      Menurut saya codebase AGPL masih lebih baik daripada dependensi yang bukan open source. Tentu saja, seiring waktu seseorang bisa saja menambahkan dukungan database alternatif

  • Saya agak bingung apa yang terjadi di sini. Proyek ini tampaknya memakai Netflix/conductor [0]. Namun kalau melihat repositori itu, statusnya sudah diarsipkan, dengan pesan bahwa ia digantikan oleh versi internal Netflix yang tidak open source dan sebuah fork komunitas yang tidak disebutkan. Mungkin yang dimaksud adalah Orkes Conductor [1]
    Namun ini tampaknya tidak memakai Orkes Conductor, melainkan memakai versi Netflix yang sudah dihentikan, com.netflix.conductor:conductor-core:2.31.5 [2]. Itu pun versi lama
    [0] https://github.com/Netflix/conductor
    [1] https://github.com/conductor-oss/conductor
    [2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...

  • Saya penasaran apakah ada yang pernah memakai ActiveBatch. Bagi saya, ini adalah perangkat lunak terbaik yang saya harap punya produk setara untuk pengguna non-korporat
    Saya terus mencoba “produk pesaing” lain, tetapi dengan ActiveBatch, cukup hubungkan DB MS SQL sederhana, pasang GUI Windows dan agen eksekusi, lalu dengan beberapa klik saja Anda mendapat lingkungan otomatisasi berbasis GUI yang solid. Tidak perlu menulis kode, dan jika mau Anda juga bisa menulis kode dalam bahasa apa pun
    Airflow bisa saja kuat, tetapi tersembunyi di balik penghalang kompleksitas sehingga kebanyakan orang tidak pernah melihat kemampuan aslinya. “Produk pesaing” open source lainnya juga sama
    Saya tidak mengerti mengapa tidak ada yang bisa membuat sistem berbasis DB yang kokoh dan mengutamakan GUI. Saya juga sudah mencoba layanan online, tetapi tidak sebanding. Mungkin alasan produk berbayar yang lebih sederhana gagal adalah biaya pemeliharaan ekstensi
    Sangat disayangkan ActiveBatch terkurung di balik model penjualan enterprise yang konyol. Itu mencegah perangkat lunak hebat ini menyebar ke komunitas yang lebih luas. Rasanya seperti rahasia tersembunyi

  • Sebagai saran, sebaiknya jangan bergantung pada alat yang dirilis Netflix sebagai open source. Mereka punya rekam jejak panjang dalam mengumumkan sesuatu lalu menghentikan dukungannya
    Seseorang mungkin mendapatkan centang di formulir evaluasi promosi berkat tulisan blog dan rilis kode ini, tetapi jangan membangun bisnis di atas solusi semacam ini

  • Saya tidak paham mengapa harus mempertimbangkan ini dibanding sesuatu yang sudah lebih mapan seperti Temporal. Maestro ditulis dengan Java, sedangkan Temporal tampaknya ditulis dengan Go

    • Kode Go milik Temporal agak aneh. Dulu sepertinya memakai Java, lalu beralih ke Go, dan Go-nya terlihat sangat bergaya Java
      Atau mungkin saya saja yang tidak terlalu paham Fx
      https://github.com/temporalio/temporal/blob/main/service/mat...
      Masalah yang berulang kali saya temui di Temporal adalah dokumentasinya sangat kurang. Ini sesuatu yang dipasang di inti bisnis, tetapi sangat sulit memahami apa yang sebenarnya terjadi setelah melewati banyak lapisan dan dokumentasi yang sangat membingungkan
      Maestro tampaknya tidak punya dokumentasi. Kalau begitu Temporal menang secara default
    • Netflix juga menggunakan Temporal: https://temporal.io/in-use/netflix
    • Menurut saya Maestro bukan alternatif untuk Temporal, melainkan alternatif untuk Airflow. Temporal bukan workflow orchestrator. Ada bagian yang tumpang tindih dalam struktur internalnya, tetapi desainnya berbeda untuk use case yang berbeda
    • Bukankah sebagian inti Temporal ditulis ulang dengan Rust?

  • Ini proyek yang terlihat sangat bagus. Di hampir semua proyek campuran ML + data engineering yang pernah saya tangani, saya pernah mempertimbangkan membuat sesuatu yang hampir sama seperti ini, mungkin versi yang lebih buruk
    Saya menantikan untuk mencobanya langsung

  • Karena saya sedang membuat orchestra di area ini, saya akan menuliskan pendapat saya: menjadikannya open source dan mengembangkannya secara terbuka jelas hal yang bagus. Namun, seperti yang mereka katakan sendiri, ini adalah orchestrator, dan sudah terlalu banyak pendahulunya seperti Airflow dan lainnya
    Jadi, selain menambahkan satu opsi lagi yang tidak akan dipakai siapa pun di lingkungan komersial, sulit melihat apa yang benar-benar ditambahkan ke area ini
    Promosi tanpa malu-malu: https://getorchestra.io

  • Saya penasaran apakah ini berbeda secara bermakna dari Conductor yang dulu diarsipkan. Setelah menelusuri kodenya, terlihat cukup banyak kemiripan, dan sama-sama memakai JSON sebagai bahasa definisi workflow