Belajar Cloud Engineer - Edge & Serverless Advanced

#Pendahuluan

Di episode 11 kita membangun serverless pertama, dan di episode 18 kita memakai CDN untuk menyajikan konten statis. Keduanya bertemu di satu tren yang semakin dominan tahun ini: komputasi di edge — menjalankan kode sedekat mungkin dengan user, bukan hanya di region pusat. Alasan utamanya sederhana: latensi. CDN menyimpan konten di edge; edge computing menjalankan logika di edge.

Episode 24 membahas edge & serverless advanced: evolusi dari CDN statis ke edge functions (CloudFront Functions, Cloudflare Workers, Lambda@Edge), pola serverless di edge, dan IoT cloud — jutaan perangkat yang mengirim data dari tepi ke pusat. Kalian akan membangun workload edge yang merespons user dalam milidetik.

#Mengapa Edge, Mengapa Sekarang

Mari lihat matematikanya. User di Jakarta memanggil API di region us-east-1 — data pulang pergi lintas benua, latensi dasar sekitar 200-300 ms, belum termasuk pemrosesan. Padahal untuk kasus seperti personalisasi, redirect, atau authentication check, logikanya tipis — tidak perlu jauh-jauh ke region pusat.

Aturan praktis memilih edge:

1. Logic tipis, sering dipanggil → edge. Contoh: A/B testing, geolocation redirect, autentikasi ringan.
2. State penuh, database, komputasi berat → region pusat. Contoh: transaksi, ML inference berat (episode 23).
3. Konten statis & cacheable → CDN biasa (episode 18), bukan function.

Edge bukan pengganti region — ia adalah filter pintar di depan region. Sebagian besar request selesai di edge; sisanya diteruskan.

#Evolusi: CDN → Edge Functions

Dari episode 18, CDN hanya menyimpan konten. Edge computing membuat CDN juga menjalankan kode di titik terdekat:

Pola klasik yang bisa dipindah ke edge — redirect berbasis lokasi:

Edge function: redirect berdasarkan negara (konsep)

export function handler(event) {
  const country = event.viewer.country;
  const path = event.request.uri;
  if (country === "ID" && path.startsWith("/en")) {
    return { statusCode: 301, headers: { location: { value: "/id" + path } } };
  }
  return event.request;
}

Perhatikan yang menjalankan fungsi ini adalah edge location terdekat user, bukan region pusat. Tidak ada VM, tidak ada cold start yang lama (episode 11), dan biayanya dihitung per request — pola serverless yang diperluas ke geografis.

#Serverless di Edge: Arsitektur dan Batasannya

Membangun workload edge perlu kesadaran penuh akan batasannya:

1. Batas runtime — waktu eksekusi terbatas (CloudFront Functions: milidetik; Workers: subdetik sampai detik). Tidak untuk loop berat.
2. Keterbatasan library — lingkungan edge bukan Node penuh; waspada dependensi yang tidak tersedia.
3. State terbatas — edge bersifat stateless per-request; state lintas request butuh storage eksternal (atau Durable Objects).
4. Deploy terpisah — edge function di-deploy ke jaringan edge, bukan sekadar ke region; proses release dan rollbacknya sendiri (episode 14).

wrangler deploy                      # Cloudflare Workers
aws cloudfront publish-function     # CloudFront Functions

Prinsip desain yang sehat: edge memproses apa yang bisa diputuskan sendiri, meneruskan sisanya — filter, cache, dan arahkan. Ini pola yang membuat keseluruhan sistem cepat dan murah.

#IoT Cloud: Jutaan Perangkat di Tepi

IoT adalah kasus edge yang paling masif: perangkat (sensor, kamera, kendaraan) tersebar di lapangan, mengirim data terus-menerus. Cloud bertugas menerima, memproses, dan menyimpan aliran data itu:

Alur khas IoT di cloud:

Kekuatan cloud di sini adalah skala dan decoupling (episode 13): sejuta perangkat → satu broker → event pipeline → banyak konsumen (dashboard, alarm, training model di episode 23). Perangkat hanya perlu tahu satu alamat, tidak perlu tahu siapa pun yang akan memakai datanya.

Karena perangkat berdaya kecil, protokolnya ringan — MQTT adalah standar de facto: publikasi/subscription dengan overhead jauh lebih kecil daripada HTTP.

#Praktik: Edge Workload

Mari bangun workload edge sederhana yang nyata:

1. Cache statis dulu: pindahkan asset statis aplikasi ke CDN (episode 18), ukur cache hit ratio.
2. Tambahkan edge function: redirect berbasis negara (kode di atas) — ukur perbedaan latensi dengan versi region.
3. Pindahkan logika tipis: header keamanan, cache control, A/B test ringan — kerjakan di edge, bukan region.
4. Simulasikan IoT: kirim event telemetri dari script ke broker IoT, alirkan ke stream, dan pasang alarm anomali (episode 9, 13).
5. Ukur hasil: bandingkan latensi request yang dipenuhi edge vs region; dokumentasikan angka-angkanya.

time curl -s https://edge.example.com/api/health
time curl -s https://origin.example.com/api/health   # bandingkan!

Target praktik ini: kalian bisa menyebutkan angka pasti berapa milidetik yang dihemat — karena keputusan "pakai edge atau tidak" di dunia kerja selalu butuh angka, bukan perasaan.

#Kesalahan Umum (Common Pitfalls)

1. Semua logika dipindah ke edge — fungsi edge menunggu database di region = latency dua kali lipat; simpan logika yang cocok saja.
2. Melebihi batas runtime edge — loop berat timeout diam-diam; kenali limit layanan yang dipakai.
3. Edge function tanpa versi/rollback — satu deploy rusak berdampak ke semua user global; siapkan rollback (episode 14).
4. IoT tanpa decoupling — perangkat menulis langsung ke database; harus lewat broker + stream (episode 13).
5. Mengabaikan egress & quota — jutaan request IoT = biaya transfer besar; arsitektur hemat bandwidth (episode 16).
6. Lupa edge bukan region — menguji di region tapi production di edge (atau sebaliknya); perilakunya berbeda.

#Penutup

Inti yang harus dibawa pulang:

• Edge computing menjalankan logika di titik terdekat user — dari CDN statis ke edge functions.
• Aturan memilih: logika tipis & sering → edge; state & komputasi berat → region.
• Edge function berjalan di batas ketat (runtime, library, state) — desain dengan sadar akan itu.
• IoT cloud: jutaan perangkat → broker (MQTT) → stream → aplikasi/alarm, semuanya decoupled.
• Keputusan edge harus didukung angka latensi nyata, bukan tren.

Di episode 25 selanjutnya kita akan memastikan semua yang dibangun berkinerja: performance & load testing — menguji beban di cloud, tuning performa, dan observability lanjutan, lalu melakukan benchmark untuk workload kalian. Sampai jumpa di episode 25!