Workflows #

Dalam dunia pengembangan aplikasi mikro (microservices) dan komputasi awan, salah satu tantangan terbesar adalah mengelola koordinasi antara berbagai layanan independen untuk menyelesaikan satu proses bisnis yang utuh. Ketika sebuah proses membutuhkan pemanggilan beberapa API eksternal, fungsi serverless, database, dan sistem notifikasi secara berantai, menulis logika koordinasi tersebut di dalam kode aplikasi utama (hardcoded glue logic) sering kali berujung pada arsitektur yang kaku, sulit dipelihara, dan rentan terhadap kegagalan penanganan error transient.

Google Cloud Workflows hadir sebagai solusi serverless orchestration engine yang didesain khusus untuk menghubungkan, mengorkestrasi, dan memantau berbagai layanan Google Cloud serta HTTP API eksternal secara deklaratif menggunakan format YAML atau JSON. Dengan pendekatan serverless murni, Google Cloud Workflows tidak membebani kita dengan manajemen kluster atau server, dan kita hanya membayar per langkah eksekusi yang sukses dijalankan. Artikel ini akan membedah secara komprehensif konsep dasar, arsitektur, teknik penulisan instruksi alur kerja, hingga perbandingan dan best practice implementasi di tingkat produksi.

Konsep Dasar Orkestrasi vs. Koreografi #

Sebelum merancang sistem terdistribusi, kita harus memahami perbedaan antara dua paradigma utama dalam integrasi layanan: Orkestrasi dan Koreografi.

Koreografi (Event-Driven) #

Dalam pola koreografi, setiap layanan berkomunikasi secara asinkron menggunakan event broker (seperti Pub/Sub). Setiap layanan mendengarkan (listen) event tertentu, menjalankan logika bisnisnya, lalu mempublikasikan event baru tanpa memedulikan siapa yang akan memproses event tersebut berikutnya.

• Kelebihan: Sangat longgar hubungannya (loosely coupled) dan mudah dikembangkan secara independen.
• Kekurangan: Sulit untuk melacak status transaksi bisnis secara keseluruhan (end-to-end visibility). Jika terjadi kegagalan di tengah jalan, proses pembatalan (rollback/saga pattern) menjadi sangat rumit untuk dikoordinasikan secara asinkron.

Orkestrasi (Central Coordinator) #

Pola orkestrasi menggunakan satu koordinator pusat (seperti Google Cloud Workflows) yang bertindak sebagai konduktor musik. Koordinator ini memegang peta jalannya proses bisnis secara utuh, memanggil layanan A, menunggu respons, membuat keputusan logis berdasarkan hasil respons tersebut, kemudian memanggil layanan B atau C, serta menangani error jika salah satu layanan gagal merespons.

• Kelebihan: Visibilitas alur bisnis sangat jelas, pemantauan status transaksi tersentralisasi, dan penanganan error serta rollback dapat didefinisikan secara deklaratif di satu tempat.
• Kekurangan: Koordinator pusat bertindak sebagai controller yang harus dikelola konfigurasinya dengan hati-hati agar tidak menjadi titik kegagalan monolitik baru.

Pola Transaksi SAGA dalam Orkestrasi #

Pola Saga (Saga Pattern) digunakan untuk mengelola konsistensi data di seluruh microservices dalam transaksi terdistribusi tanpa menggunakan transaksi dua fase (two-phase commit). Orkestrasi Workflows sangat unggul dalam memfasilitasi Saga Pattern karena kita dapat melacak setiap langkah transaksi yang berhasil. Jika langkah ketiga (misal: booking hotel) gagal setelah langkah kedua (misal: pembayaran) berhasil, Workflows dapat menangkap eksepsi tersebut dan memicu langkah kompensasi (compensating transaction) secara terurut untuk membatalkan pembayaran di langkah kedua secara otomatis. Hal ini menjaga konsistensi state sistem tanpa menyebarkan logika pembatalan yang membingungkan di berbagai microservices.

Arsitektur Internal dan Posisi di Ekosistem GCP #

Google Cloud Workflows dirancang sebagai state machine terkelola yang sangat dioptimalkan untuk performa tinggi dengan overhead minimal.

flowchart TD
    Trigger["Event Trigger (HTTP/PubSub/Scheduler)"] -->|"Start Execution"| Start["GCP Workflows Orchestrator"]
    Start --> Step1["Step 1: Authenticate User (Cloud Function)"]
    Step1 --> Step2{"Step 2: Check Status?"}
    Step2 -- "Approved" --> Step3["Step 3: Process Payment (Cloud Run)"]
    Step2 -- "Rejected" --> Step4["Step 4: Cancel Order (Cloud Run)"]
    Step3 --> Step5["Step 5: Parallel Notification"]
    subgraph Parallel Notification
        direction LR
        NotifyEmail["Send Email API"]
        NotifySlack["Send Slack webhook"]
    end
    Step5 --> Step6["Step 6: Update Database (BigQuery/Firestore)"]
    Step4 --> Step6
    Step6 --> End["End Execution & Return Output"]

    style Step2 stroke:#0288d1,stroke-width:2px
    style Parallel Notification stroke:#0288d1,stroke-width:2px

1. State Management dan Durabilitas Eksekusi #

Setiap eksekusi (execution instance) dari suatu workflow bersifat stateful dan dapat berjalan hingga maksimum 1 tahun. Workflows melacak status variabel, parameter masukan, langkah yang sedang aktif, dan riwayat eksekusi secara otomatis. Data state ini disimpan secara redundan oleh Google Cloud, memastikan bahwa jika terjadi gangguan pada infrastruktur fisik GCP di latar belakang, eksekusi workflow kita akan dilanjutkan kembali dari langkah terakhir yang sukses tanpa kehilangan data state.

2. Pemisahan Data Plane dan Control Plane #

Satu aspek arsitektur terpenting adalah bahwa Workflows dirancang murni sebagai Control Plane (otak pengatur), bukan Data Plane (pemroses data). Workflows tidak didesain untuk melakukan pemrosesan data CPU-intensive seperti manipulasi gambar, kompresi file besar, atau kalkulasi matematika kompleks di dalam instruksi YAML-nya. Pekerjaan komputasi berat tersebut harus didelegasikan ke layanan komputasi seperti Cloud Run, Cloud Functions, atau BigQuery. Tugas Workflows hanyalah mengirim instruksi kerja ke layanan tersebut, memantau siklus hidupnya, menerima hasil akhir, dan melanjutkan ke langkah berikutnya.

3. Model Penagihan Berbasis Langkah (Execution Steps Billing) #

Struktur biaya Google Cloud Workflows dihitung secara transparan berdasarkan jumlah langkah (steps) yang dieksekusi. Tidak ada biaya tetap bulanan, dan tidak ada biaya saat workflow dalam kondisi idle (menunggu callback dari sistem eksternal). Google membagi langkah menjadi dua kategori:

• Langkah Internal: Langkah dasar seperti penetapan variabel (assign), percabangan kondisional (switch), dan manipulasi data lokal.
• Langkah Eksternal / Konektor: Pemanggilan HTTP API ke luar ekosistem GCP atau pemanggilan layanan GCP menggunakan GCP Connectors. Langkah eksternal ini memiliki tarif yang sedikit lebih tinggi karena melibatkan pemrosesan jaringan dan otentikasi. Dengan model ini, optimalisasi file YAML dengan menggabungkan beberapa penulisan variabel menjadi satu langkah assign dapat membantu menekan biaya operasional secara signifikan.

Mekanisme Pengendalian Alur (Control Flow Mechanics) #

Format YAML pada Google Cloud Workflows menyediakan struktur ekspresi yang kaya untuk mengendalikan alur eksekusi aplikasi secara dinamis menggunakan Common Expression Language (CEL).

1. Sintaksis CEL (Common Expression Language) #

CEL adalah bahasa ekspresi deklaratif yang aman, cepat, dan ringan yang digunakan oleh Google untuk mengevaluasi kondisi di dalam Workflows. Semua ekspresi CEL harus ditulis di dalam tanda kurung kurawal bersimbol dolar ${...}. Melalui CEL, kita dapat melakukan manipulasi string dasar, operasi matematika, pembacaan elemen array, pembacaan struktur objek JSON, serta konversi tipe data secara langsung tanpa perlu memicu cold start dari fungsi komputasi luar.

2. Conditional Branching (Percabangan Kondisional) #

Menggunakan blok switch, kita dapat menguji nilai variabel atau kode status HTTP respons dari langkah sebelumnya untuk menentukan cabang langkah mana yang akan dijalankan berikutnya.

# Contoh struktur percabangan di Workflows
- check_status:
    switch:
      - condition: ${response.body.status == "APPROVED"}
        next: process_payment
      - condition: ${response.body.status == "REJECTED"}
        next: cancel_order
    next: default_fallback

3. Looping (Perulangan) #

Workflows mendukung perulangan berbasis elemen (for-in loop) untuk melakukan iterasi pada array data. Hal ini sangat berguna jika kita ingin memproses daftar item yang dikembalikan oleh kueri database secara bertahap.

# Contoh looping di Workflows
- loop_items:
    for:
      value: item
      in: ${item_list}
      steps:
        - process_single_item:
            call: http.post
            args:
              url: https://my-service.run.app/process
              body:
                itemData: ${item}

4. Parallel Execution (Eksekusi Paralel) #

Untuk menghemat waktu pemrosesan total, kita dapat menjalankan beberapa langkah yang tidak saling bergantung secara bersamaan menggunakan blok parallel. Misalnya, mengirim notifikasi email dan push notification ke aplikasi mobile secara paralel.

# Contoh eksekusi paralel di Workflows
- send_notifications:
    parallel:
      shared: [email_status, sms_status]
      branches:
        - notify_via_email:
            steps:
              - send_email:
                  call: http.post
                  args:
                    url: https://email-service.run.app
        - notify_via_sms:
            steps:
              - send_sms:
                  call: http.post
                  args:
                    url: https://sms-service.run.app

5. Reusable Subworkflows #

Untuk menjaga kebersihan file kode YAML, Workflows mengizinkan pembuatan subworkflow yang bertindak seperti fungsi lokal. Subworkflow menerima argumen input, menjalankan blok langkah terisolasi, dan mengembalikan data output ke workflow utama. Hal ini sangat membantu mereduksi duplikasi kode deklarasi HTTP call yang berulang.

Konektor API (GCP Connectors) dan HTTP Calls #

Salah satu keunggulan terbesar Google Cloud Workflows adalah kemudahan integrasi dengan API internal GCP maupun API pihak ketiga secara aman.

1. GCP Connectors (Konektor Native) #

Menghubungkan satu layanan cloud dengan layanan lainnya sering kali terkendala masalah otentikasi IAM yang rumit. Workflows memecahkan masalah ini dengan menyediakan GCP Connectors bawaan untuk sebagian besar layanan inti GCP (seperti BigQuery, Cloud Storage, Secret Manager, Pub/Sub, dan Cloud Run). Konektor ini membungkus API REST GCP asli menjadi fungsi YAML sederhana. Kita tidak perlu menulis kode otentikasi token OAuth2 secara manual; Workflows akan menggunakan kredensial dari Service Account yang terasosiasi secara otomatis di latar belakang.

2. Panggilan HTTP Eksternal Kustom #

Selain layanan internal GCP, Workflows dapat memanggil HTTP endpoint apa pun di internet publik menggunakan konektor universal http.get, http.post, http.put, atau http.delete. Kita dapat mengonfigurasi header kustom, parameter kueri, timeout, serta mekanisme otentikasi seperti Basic Auth, Bearer Token, atau OIDC/OAuth2 token Google secara deklaratif.

Error Handling, Retry Policies, dan Exception Catching #

Ketahanan sistem terdistribusi sangat bergantung pada bagaimana kita menangani kegagalan jaringan sementara (transient errors) atau kegagalan logika bisnis.

1. Exception Catching (Blok Try/Catch) #

Kita dapat membungkus satu atau beberapa langkah penting di dalam blok try dan mendefinisikan langkah penanganan alternatif di dalam blok retry atau except jika terjadi kegagalan eksekusi.

# Struktur penangkapan error di Workflows
- try_payment_step:
    try:
      steps:
        - charge_card:
            call: http.post
            args:
              url: https://payment-gateway.com/charge
              body:
                amount: 500000
    except:
      as: error_info
      steps:
        - handle_failed_payment:
            call: http.post
            args:
              url: https://my-backend.run.app/payment-failed
              body:
                details: ${error_info}

2. Custom Retry Policies (Kebijakan Percobaan Ulang) #

Untuk menangani masalah rate limiting (HTTP 429) atau gangguan server sesaat (HTTP 503), kita dapat mengonfigurasi kebijakan retry otomatis dengan parameter exponential backoff yang sangat detail.

• Backoff Rate: Faktor pengali jeda waktu antar percobaan (misalnya 2.0, jeda waktu akan berlipat ganda setiap kali gagal).
• Max Retries: Jumlah maksimal percobaan ulang sebelum akhirnya melempar error permanen ke penangan eksepsi.

Contoh Implementasi Kode: YAML Workflow Definition #

Berikut adalah contoh lengkap file definisi workflow produksi (workflow.yaml) yang menerima input data order, melakukan validasi status user via Cloud Function, memproses pembayaran via Cloud Run dengan IAM auth, serta menangani error transient dengan kebijakan retry kustom.

# YAML definisi orkestrasi pemrosesan order
main:
  params: [input_data]
  steps:
    - init_variables:
        assign:
          - order_id: ${input_data.orderId}
          - amount: ${input_data.amount}
          - user_id: ${input_data.userId}
          - validation_status: ""

    # Langkah 1: Validasi user menggunakan Cloud Function Gen 2
    # Menggunakan OIDC token untuk otentikasi aman antar layanan internal GCP
    - validate_user_account:
        call: http.get
        args:
          url: ${"https://us-central1-my-project.cloudfunctions.net/validate-user?userId=" + user_id}
          auth:
            type: OIDC
        result: validation_response

    - parse_validation_result:
        assign:
          - validation_status: ${validation_response.body.status}

    # Langkah 2: Evaluasi kondisi status validasi
    - check_validation_decision:
        switch:
          - condition: ${validation_status == "ACTIVE"}
            next: process_credit_charge
          - condition: ${validation_status == "SUSPENDED"}
            next: reject_order_process
        next: default_unknown_error

    # Langkah 3: Eksekusi charge kartu menggunakan Cloud Run dengan Retry Policy kustom
    - process_credit_charge:
        try:
          call: http.post
          args:
            url: https://payment-processor-service-xyz.run.app/charge
            auth:
              type: OIDC
            body:
              orderId: ${order_id}
              chargeAmount: ${amount}
          result: payment_result
        retry:
          predicate: ${http.default_retry_predicate}
          max_retries: 5
          backoff:
            initial_delay: 2.0
            max_delay: 60.0
            factor: 2.0
        next: update_success_order_db

    # Langkah 4a: Update status order sukses ke database hilir
    - update_success_order_db:
        call: http.post
        args:
          url: https://order-db-service-xyz.run.app/update-status
          auth:
            type: OIDC
          body:
            orderId: ${order_id}
            status: "PAID"
            transactionId: ${payment_result.body.transactionId}
        next: return_success_output

    # Langkah 4b: Alur penolakan order jika user tidak aktif
    - reject_order_process:
        call: http.post
        args:
          url: https://order-db-service-xyz.run.app/update-status
          auth:
            type: OIDC
          body:
            orderId: ${order_id}
            status: "REJECTED"
            reason: "User account is suspended"
        next: return_rejected_output

    # Langkah Akhir: Return output sukses
    - return_success_output:
        return:
          status: "SUCCESS"
          message: "Transaksi order berhasil diproses secara penuh."
          orderId: ${order_id}

    - return_rejected_output:
        return:
          status: "REJECTED"
          message: "Transaksi ditolak karena akun user ditangguhkan."
          orderId: ${order_id}

    # Penanganan error fallback jika kondisi tidak terpenuhi
    - default_unknown_error:
        raise: ${"Validasi akun user mengembalikan status tidak dikenal: " + validation_status}

Perbandingan: GCP Workflows vs. Cloud Tasks vs. Cloud Composer #

Untuk arsitek infrastruktur yang bingung memilih layanan penjadwalan dan orkestrasi di Google Cloud, tabel di bawah membandingkan Workflows dengan dua alternatif utama lainnya.

Best Practice Desain Workflow #

Agar file YAML workflow kita tetap bersih, mudah dibaca, dan berkinerja tinggi di lingkungan produksi, terapkan beberapa rekomendasi desain berikut secara disiplin:

1. Jaga Ukuran File Workflow Tetap Ramping (Thin Workflow) #

Hindari menaruh logika bisnis yang kompleks atau manipulasi data JSON berukuran besar langsung di dalam ekspresi YAML Workflows.

• JANGAN memproses payload JSON berukuran belasan megabyte menggunakan manipulasi string internal YAML.
• BENAR: Delegasikan pekerjaan transformasi data tersebut ke fungsi Cloud Run kustom. Biarkan Workflows hanya menerima referensi data akhir yang bersih.

2. Terapkan Modularisasi Menggunakan Subworkflows #

Jika alur kerja kita memiliki ratusan baris kode YAML dengan logika penanganan error yang mirip di beberapa tempat, file tersebut akan sangat sulit dibaca dan dirawat.

• BENAR: Pecah bagian-bagian alur kerja yang sering digunakan kembali menjadi Subworkflows. Subworkflow bekerja seperti fungsi di dalam bahasa pemrograman biasa — memiliki parameter masukan, menjalankan serangkaian langkah, dan mengembalikan hasil ke alur utama.

3. Gunakan Service Account dengan Hak Akses Minimal (Least Privilege) #

Secara bawaan, jika kita tidak menentukan service account saat deployment, Workflows akan menggunakan Compute Engine default service account yang biasanya memiliki hak akses admin yang terlalu luas.

• BENAR: Selalu buat service account kustom khusus untuk setiap workflow (misalnya order-orchestrator-sa). Berikan hanya hak akses yang benar-benar dibutuhkan (misalnya role roles/run.invoker hanya untuk layanan Cloud Run yang dipanggil oleh workflow tersebut).

4. Optimasi Biaya dengan Penggabungan Langkah Assign #

Setiap kali kita memanggil instruksi assign di dalam YAML, Google Cloud mencatatnya sebagai satu langkah komputasi internal berbayar.

• JANGAN menulis blok assign yang terpisah secara berurutan untuk mendefinisikan beberapa variabel yang berbeda.
• BENAR: Gabungkan semua deklarasi variabel lokal kita ke dalam satu blok assign tunggal seperti contoh di file workflow.yaml di atas untuk mengurangi jumlah tagihan eksekusi langkah internal.

5. Tangani Transient Error dengan Predikat Bawaan #

Menulis filter penangkap error kustom untuk mengevaluasi kode HTTP status konektivitas jaringan secara manual dapat menjadi sangat panjang dan melelahkan.

• BENAR: Gunakan predikat bawaan ${http.default_retry_predicate} pada blok retry. Predikat ini secara otomatis mengenali error transient seperti kegagalan koneksi TCP, timeout DNS, serta kode status HTTP 429, 502, 503, dan 504 untuk langsung melakukan percobaan ulang secara otomatis.

Ringkasan #

• Google Cloud Workflows adalah state machine serverless untuk mengorkestrasi alur kerja HTTP APIs dan layanan GCP secara terpusat.
• Mengedepankan prinsip orkestrasi dibanding koreografi untuk mengembalikan visibilitas dan kontrol penanganan error di tingkat proses bisnis.
• Mendukung kontrol alur yang kaya termasuk percabangan (switch), perulangan (for), dan eksekusi paralel (parallel) langsung di YAML.
• Memiliki durabilitas eksekusi hingga 1 tahun dengan pelacakan state variabel yang disimpan secara redundan oleh Google Cloud.
• Gunakan GCP Connectors bawaan untuk menyederhanakan otentikasi IAM OAuth2/OIDC secara otomatis saat memanggil API Google Cloud lainnya.
• Pecah logika alur kerja besar menjadi subworkflow modular dan kelola infrastrukturnya menggunakan Terraform untuk versioning yang aman.

← Sebelumnya: Pub/Sub   Berikutnya: AppEngine →