Belajar LocalStack - Production-Ready Development Workflow

#Pendahuluan

Di episode 20 kita memetakan rilis 2026: calendar versioning, image tunggal, dan fitur stabil 2026.07.0. Tapi memiliki emulator yang hebat belum berarti workflow tim menjadi hebat. Pertanyaan sebenarnya: di titik mana LocalStack masuk ke siklus hidup pengembangan (SDLC), dan bagaimana cara keluar darinya dengan mulus?

Episode ini membangun jembatan itu. Kalian akan melihat peran LocalStack di setiap fase SDLC, strategi migrasi bertahap ke AWS asli tanpa mengubah kode secara drastis, golden path yang bisa dipakai seluruh tim, serta fitur Pro dan Ultimate yang membuat kolaborasi antar developer jauh lebih praktis.

#LocalStack dalam SDLC

#Development Loop

Ini penggunaan paling dasar: server berjalan, kode berubah, testing cepat. Di fase ini kecepatan adalah segalanya — LocalStack memberikan feedback loop dalam hitungan detik, bukan menit, dan tanpa biaya AWS sama sekali.

localstack start
awslocal sts get-caller-identity
awslocal sqs create-queue --queue-name orders-dev

#Unit Testing

Unit test menargetkan satu komponen, dan di sini mocking (misalnya moto) masih wajar karena kita menguji logika murni. Tetapi begitu sebuah test menyentuh interaksi antar service — S3 mentrigger Lambda yang menulis ke DynamoDB — mocking mulai berbohong. Di titik itulah LocalStack masuk.

#Integration Testing dengan Testcontainers

Untuk integration test, pendekatan paling rapi adalah Testcontainers: container LocalStack dibangkitkan otomatis saat test dimulai dan dihancurkan saat selesai. Setiap test suite mendapat emulator bersih, tanpa port conflict antar test paralel. Ini menjaga isolasi yang menjadi tema episode 15.

Pola umumnya: image localstack/localstack:stable dibuat sekali per test run, health endpoint /_localstack/health ditunggu, lalu test berjalan. Satu-satunya yang berubah pada kode aplikasi adalah endpoint URL.

#Migrasi ke AWS Asli

#Endpoint Adalah Satu-satunya Perbedaan

Desain LocalStack sejak awal: kode yang sama berjalan di lokal dan di AWS — hanya endpoint yang berbeda. Jika kalian konsisten memakai AWS_ENDPOINT_URL di SDK modern, atau menyimpan endpoint di satu titik konfigurasi, migrasi ke staging hanyalah masalah menghapus endpoint tersebut.

# Lokal: menunjuk ke emulator
export AWS_ENDPOINT_URL=http://localhost:4566
# Staging: hapus variabel, SDK memakai AWS asli
unset AWS_ENDPOINT_URL

#Strategi Bertahap

Jangan pindahkan semuanya sekaligus. Urutan yang sehat:

1. Verifikasi parity di lokal dulu — test yang sama harus lulus di emulator sebelum menyentuh AWS.
2. Deploy ke staging dengan satu service paling sederhana (misalnya S3 bucket + Lambda) dan bandingkan hasilnya.
3. Perluas bertahap ke service lain, sambil mencatat perbedaan perilaku yang ditemukan.
4. Simpan catatan parity — service yang sudah diverifikasi, batasan yang ditemukan, dan versi LocalStack yang dipakai.

Di CI, jalankan LocalStack sebagai service container dengan image dan versi yang sama persis seperti lokal:

jobs:
  test:
    services:
      localstack:
        image: localstack/localstack:stable
        env:
          SERVICES: s3,sqs,dynamodb
        ports:
          - 4566:4566

Tunggu health endpoint siap sebelum test dimulai: curl http://localhost:4566/_localstack/health — pola yang sama dengan episode 19. Untuk memantau error, pakai localstack logs --follow | grep -i error.

#Golden Path untuk Tim

"Works on my machine" lahir dari konfigurasi yang berbeda-beda. Golden path menghapus variasi itu dengan satu sumber kebenaran:

• Satu file docker-compose.yml yang di-version yang dipakai semua developer, termasuk CI.
• Variabel environment di dokumen bersama (bukan di shell masing-masing): SERVICES, PERSISTENCE, DEBUG.
• Skrip bootstrap yang menunggu health check sebelum aplikasi dijalankan.
• Versi LocalStack di-pin dan di-update secara sengaja, bukan diam-diam.

Hasilnya: setiap anggota tim — dan robot CI — menguji hal yang persis sama. Perbedaan perilaku yang muncul hanya karena perbedaan versi, bukan karena setup.

#Fitur Pro dan Ultimate

#Cloud Pods

Cloud Pods adalah snapshot state LocalStack yang bisa dibagikan lintas mesin. Alih-alih mensimulasikan ulang bug yang rumit, seorang developer cukup menyimpan pod dan rekan lain memuatnya.

localstack cloudpod create bug-repro-orders
localstack cloudpod save bug-repro-orders
localstack cloudpod load bug-repro-orders

Use case paling berharga: bug reproduction lintas tim dan lintas CI. Pod menyimpan seluruh state — tabel, queue, object — sehingga "reproduce di environment ini" menjadi satu perintah.

#Web Application

Web Application (app.localstack.cloud) memberi tampilan grafis atas instance: melihat service yang aktif, resource yang dibuat, hingga mengelola Cloud Pods dari browser. Untuk observability cepat saat debugging, ini jauh lebih nyaman daripada menebak dari log.

#AWS Replicator

AWS Replicator (episode 17) menarik resource dari akun AWS asli ke LocalStack — SNS, RDS, VPC, IAM, dan lainnya. Ini mengubah regression testing: alih-alih data sintetis, kalian menguji terhadap struktur resource yang nyata.

awslocal replicator all --sns --iam --region us-east-1

#LocalStack untuk Snowflake dan Azure

Ekosistemnya meluas melampaui AWS: LocalStack for Snowflake dan LocalStack for Azure memakai pendekatan emulasi yang sama untuk ekosistem lain. Jika tim kalian multi-cloud, berarti satu pola pengembangan — emulasikan, test, migrasikan — berlaku di mana-mana.

#Dukungan Enterprise

Semua fitur di atas berjalan di balik lisensi Pro/Ultimate, dengan dukungan enterprise: SLA, deployment internal, dan akses langsung ke tim engineering. Untuk startup dan tim kecil, fitur Community sudah menutupi sebagian besar kebutuhan; pindah ke Pro ketika kolaborasi state dan parity lanjutan mulai menjadi kebutuhan.

#Penutup

Ringkasan episode ini:

• LocalStack melayani development loop, unit test, dan terutama integration test dengan Testcontainers.
• Migrasi ke AWS asli cukup mengubah endpoint; lakukan bertahap dan catat parity.
• CI menjalankan LocalStack sebagai service container dengan image yang di-pin.
• Golden path menyatukan konfigurasi seluruh tim dan CI dalam satu sumber kebenaran.
• Fitur Pro seperti Cloud Pods, Web Application, dan AWS Replicator menyederhanakan kolaborasi dan testing realistis.

LocalStack bukan pengganti AWS, melainkan jembatan menuju AWS. Di episode 22 — episode terakhir seri ini — kita membandingkan LocalStack dengan alternatif lain (moto, SAM Local, Testcontainers Cloud, akun sandbox), merekap seluruh perjalanan dari episode 0 sampai 22, dan menutupnya dengan checklist emulation production-grade serta arah masa depan emulasi cloud. Sampai jumpa di penutup!