Belajar Istio - Sejarah, Latar Belakang & Mengapa Membutuhkan Istio

#Pendahuluan

Sebelum kita menyentuh perintah istioctl, penting untuk menjawab pertanyaan paling mendasar: mengapa service mesh ada? Episode 1 ini membawa kalian memahami masalah yang coba dipecahkan Istio, bagaimana ekosistemnya berevolusi, dan mengapa Istio menjadi salah satu pilihan paling populer di dunia Kubernetes.

Kalian akan melihat bahwa service mesh lahir dari sebuah pergeseran: aplikasi monolit yang sederhana mulai dipecah menjadi puluhan atau ratusan microservices. Di titik itu, komunikasi antar layanan berubah dari masalah yang sepele menjadi masalah yang kompleks — dan di situlah Istio masuk sebagai solusi.

#Masalah yang Dipecahkan Service Mesh

#Observability Antar Layanan

Ketika sebuah permintaan pengguna berpindah dari satu service ke service lain, melacak di mana permintaan itu melambat menjadi sangat sulit. Di monolit, semuanya ada di satu proses; di microservices, trace harus disatukan dari banyak proses yang berbeda.

Istio menyelesaikannya dengan memasang Envoy proxy sebagai sidecar di setiap Pod. Sidecar ini mencatat metrik seperti jumlah request, durasi, dan status response untuk setiap pasangan layanan, tanpa kalian harus mengubah kode aplikasi. Hasilnya adalah peta trafik yang lengkap: siapa bicara ke siapa, berapa cepat, dan seberapa sukses.

Buktinya bisa kalian lihat langsung di Pod yang sudah masuk mesh — setiap Pod kini punya dua container: aplikasi dan proxy:

kubectl get pod productpage-abc123 -o jsonpath="{.spec.containers[*].name}"
kubectl exec productpage-abc123 -c istio-proxy -- curl localhost:15000/stats/prometheus | head -5

kubectl exec ... -c istio-proxy mengakses container sidecar secara langsung. Ini pola verifikasi yang akan kalian pakai di hampir semua episode observability.

#Traffic Control

Tanpa service mesh, mengatur rute traffic antar versi layanan memerlukan logika tambahan di aplikasi, gateway khusus, atau server konfigurasi. Istio memindahkan kontrol ini ke luar aplikasi: kalian cukup mendefinisikan routing, weight antar versi, retry, timeout, dan circuit breaker lewat CRD tanpa menyentuh kode service.

#Security Antar Layanan

Di jaringan internal, komunikasi antar service biasanya plaintext. Istio mengaktifkan mutual TLS (mTLS) sehingga setiap komunikasi antar layanan dienkripsi dan diautentikasi dua arah. Ditambah kebijakan otorisasi berbasis identitas service, bukan sekadar alamat IP, serangan lateral di dalam cluster bisa ditekan.

#Evolusi Service Mesh dan Posisi Istio

#Dari Monolit ke Microservices

Perjalanan dimulai dari monolit: satu aplikasi, satu deploy, satu titik kegagalan. Microservices memecahnya menjadi service kecil yang bisa di-deploy dan diskalakan secara independen, tetapi memunculkan masalah baru: network reliability. Satu service yang lambat bisa menjatuhkan seluruh chain permintaan. Pola seperti retry, timeout, dan circuit breaker lalu dipindahkan dari library aplikasi ke lapisan jaringan — inilah cikal bakal service mesh.

#Lahirnya Envoy dan Istio

Envoy lahir di Lyft pada 2016 sebagai proxy berperforma tinggi yang ditulis dalam C++ dan dirancang untuk menjadi data plane yang fleksibel. Envoy bukan sekadar proxy biasa: ia punya API dinamis untuk konfigurasi runtime yang kelak dikenal sebagai xDS.

Istio diumumkan pada 2017 oleh Google, IBM, dan Lyft. Istio mengambil Envoy sebagai data plane dan membangun control plane di atasnya. Dengan begitu, kalian mendapat satu titik kontrol untuk seluruh mesh: kebijakan traffic, security, dan observability didefinisikan di satu tempat, lalu disebarkan ke setiap Envoy.

#Control Plane + Data Plane

Arsitektur Istio klasik memisahkan dua lapisan:

• Data plane: kumpulan Envoy proxy (sidecar) yang memproses traffic nyata antar Pod.
• Control plane: istiod yang menerjemahkan konfigurasi mesh menjadi aturan xDS, membagikan sertifikat mTLS, dan memonitor kesehatan proxy.

Sidecar memang memakai resource tambahan, tetapi ia memberikan kapabilitas yang sebelumnya harus dibangun manual di setiap aplikasi. Perbandingan ini akan kita bedah lebih dalam di episode 2.

#Trade-offs: Kompleksitas vs Kapabilitas

Tidak ada teknologi yang gratis. Mengadopsi Istio berarti menukar kompleksitas operasional dengan kapabilitas platform. Kompleksitas yang harus dibayar:

• Resource overhead: setiap Pod kini membawa sidecar yang memakai CPU dan memori.
• Kurva belajar: CRD Istio, model proxy, dan mekanisme injection butuh waktu untuk dikuasai.
• Surface area yang lebih besar: lebih banyak komponen berarti lebih banyak hal yang bisa gagal dan lebih banyak hal yang harus di-monitor.

Kapabilitas yang didapat:

• Traffic management terpusat dengan canary dan A/B tanpa ubah kode.
• mTLS dan authorization berbasis identitas secara default.
• Observability end-to-end lintas service dari satu platform.

Kuncinya adalah memutuskan berdasarkan kebutuhan. Jika aplikasi hanya beberapa service tanpa kebutuhan traffic control atau security yang ketat, Istio bisa jadi overkill.

kapabilitas platform - biaya operasional = nilai netto service mesh

#Kapan Memakai Istio dan Kapan Tidak

#Mulai Memakai Jika

• Jumlah service sudah banyak dan komunikasi lintas service sulit dipetakan.
• Butuh canary, retry, timeout, dan circuit breaker tanpa mengubah kode.
• Security antar service penting dan kalian ingin mTLS serta authorization terpusat.
• Sudah ada kebutuhan observability yang konsisten untuk seluruh traffic.

#Pertimbangkan Alternatif Jika

• Traffic sangat sederhana dan hanya butuh ingress gateway biasa.
• Resource cluster terbatas dan overhead sidecar tidak terjangkau.
• Tim belum siap mengoperasikan komponen tambahan di atas Kubernetes.

Jika masih ragu, jalankan eksperimen kecil di cluster staging: install Istio, onbarding satu service, lalu ukur overhead dan nilai yang didapat. Data itu jauh lebih meyakinkan daripada opini.

Pengambilan keputusan ini akan terus berlanjut di episode 22, ketika kita menyusun checklist hardening untuk produksi. Untuk sekarang, penting untuk membangun intuisi: service mesh memindahkan tanggung jawab networking dari aplikasi ke platform. Mulailah dari masalah yang nyata, ukur dampaknya, lalu putuskan apakah Istio layak menjadi bagian dari infrastruktur kalian.

#Penutup

Episode 1 menjelaskan mengapa Istio ada: microservices membuat masalah observability, traffic control, dan security antar layanan menjadi kompleks, dan Istio menjawabnya dengan memindahkan masalah tersebut dari aplikasi ke lapisan mesh yang terdiri dari data plane Envoy dan control plane istiod.

Inti yang harus dibawa pulang:

• Masalah utama service mesh: observability, traffic control, dan security antar layanan.
• Envoy adalah data plane; istiod adalah control plane.
• Istio mengatur traffic tanpa mengubah kode aplikasi.
• mTLS membuat komunikasi antar layanan terenkripsi dan terautentikasi.
• Service mesh menukar kompleksitas operasional dengan kapabilitas platform.
• Jangan adopsi Istio sebelum kebutuhannya jelas.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama — cara kerja control plane dan data plane secara detail, CRD Istio yang akan kalian pakai setiap hari, serta mekanisme xDS yang mengalirkan konfigurasi ke setiap Envoy proxy. Semua ini adalah bahasa dasar yang akan dipakai di seluruh episode berikutnya.