Belajar Envoy Proxy - Sejarah, Latar Belakang & Mengapa Membutuhkan Envoy

#Pendahuluan

Sebelum memahami cara kerja Envoy, kalian perlu tahu dari mana dia berasal dan masalah apa yang dia selesaikan. Episode 1 membuka series ini dengan sejarah dan latar belakang Envoy: mengapa Lyft membangun proxy-nya sendiri pada 2016, bagaimana Envoy berevolusi menjadi standar data plane untuk microservices, dan mengapa dia dipakai sebagai fondasi Istio dan banyak service mesh modern.

Kalian juga akan melihat bagaimana Envoy diposisikan dibandingkan tool lain yang mungkin sudah kalian kenal: NGINX, HAProxy, dan data plane service mesh. Ini penting karena pilihan tool memengaruhi arsitektur. Setelah episode ini, kalian akan punya alasan kuat mengapa mempelajari Envoy layak menghabiskan 23 episode.

#Evolusi Envoy sebagai Modern Proxy Layer-7

#Kelahiran di Lyft

Pada tahun 2015, tim Lyft menghadapi masalah klasik arsitektur microservices: ratusan service saling berbicara, dan setiap service perlu menangani discovery, retry, timeout, TLS, dan observability secara berulang. Solusi yang mereka pilih bukan library per bahasa, melainkan sebuah proxy terpisah yang ditempelkan di setiap service.

Hasilnya adalah Envoy, ditulis dalam C++ oleh Matt Klein, dan dirilis open-source pada September 2016. Kurang dari setahun kemudian, pada November 2017, Envoy didonasikan ke CNCF dan menjadi salah satu proyek yang paling cepat diadopsi. Hari ini Envoy adalah basis dari Istio, Gloo, AWS App Mesh, dan banyak platform service mesh.

#Desain yang Berfokus pada Jaringan Modern

Envoy dirancang bukan untuk menggantikan web server, tapi untuk menjadi proxy data plane yang sangat fleksibel:

• Mendukung HTTP/1.1, HTTP/2, dan HTTP/3 dengan baik.
• Konfigurasi dinamis melalui protokol xDS tanpa restart.
• Observability yang kaya: metrics, tracing, dan access log built-in.
• Arsitektur filter yang bisa diperluas untuk HTTP, TCP, dan kini WASM.

envoy --version
curl -s localhost:9901/server_info

Perintah envoy --version menampilkan versi binary, sementara server_info dari admin interface memperlihatkan informasi runtime. Keduanya berguna untuk memastikan image yang kalian pakai adalah versi yang sesuai.

#Envoy vs NGINX vs HAProxy

#Tiga Generasi Proxy

Agar adil, mari bandingkan dengan dua proxy populer:

• NGINX adalah web server dan reverse proxy yang sangat efisien untuk HTTP, dengan ekosistem konfigurasi yang matang. Cocok untuk edge dan serving konten.
• HAProxy adalah load balancer TCP/HTTP yang legendaris dengan performa tinggi dan fitur keamanan yang solid.
• Envoy fokus pada dynamic configuration, observability mendalam, dan ekstensibilitas, sehingga lebih cocok sebagai data plane dalam arsitektur microservices yang cepat berubah.

Perbedaan kunci ada pada cara konfigurasi: NGINX dan HAProxy umumnya dimuat ulang saat ada perubahan, sedangkan Envoy bisa menerima perubahan listener, cluster, dan route secara live via xDS tanpa restart.

#Mengapa Tim Modern Memilih Envoy

Ada beberapa alasan teknis yang membuat Envoy menang dalam banyak arsitektur:

• Observability bawaan: setiap request bisa dicatat dengan metadata lengkap, plus metrics per listener dan per cluster.
• Load balancing canggih: dukungan ring hash, maglev, least request, dan consistency hashing.
• Resilience: circuit breaking, retry, timeout, dan outlier detection secara native.
• Ekstensibilitas: filter chain yang bisa dipasang untuk HTTP, TCP, dan kini WASM.
• Kematangan ekosistem: dipakai Istio, Gloo, dan banyak platform sebagai engine data plane.

Ekosistem ini bukan sekadar daftar nama: Istio, Gloo, dan AWS App Mesh semuanya menurunkan fondasi Envoy yang sama — protokol xDS, filter chain, TLS context, dan model listener-cluster-route. Karena itu keterampilan yang kalian pelajari di series ini bisa langsung dipakai di platform service mesh mana pun tanpa belajar dari nol. Inilah nilai terbesar belajar Envoy: satu mesin yang sama, banyak platform yang menggunakannya.

Nilai tersebut juga menjadi alasan komunitas dan vendor terus berinvestasi: dokumentasi yang kaya, filter yang terus bertambah, serta dukungan WASM untuk memperluas kemampuan tanpa mengubah inti Envoy. Dengan mempelajari Envoy, kalian membeli keterampilan yang tidak cepat usang, karena fondasi protokol dan model konfigurasinya stabil meskipun tooling di sekitarnya berubah.

#Control Plane, Data Plane, dan Service Mesh

#Posisi Envoy dalam Service Mesh

Service mesh biasanya memisahkan dua komponen: control plane yang menentukan kebijakan, dan data plane yang menjalankan kebijakan tersebut terhadap traffic. Envoy berada di sisi data plane: dialah yang benar-benar menerima request, melakukan routing, autentikasi, dan mencatat telemetry.

Istio, misalnya, memakai Envoy sebagai sidecar di setiap pod, sementara control plane-nya (istiod) meneruskan konfigurasi ke Envoy melalui protokol xDS. Pola yang sama dipakai Gloo dan Linkerd (dengan varian sendiri). Dengan memahami Envoy, kalian sebenarnya sedang memahami mesin di balik service mesh paling populer.

#Apakah Kalian Membutuhkan Envoy Langsung?

Jika arsitektur kalian masih sederhana, NGINX atau HAProxy mungkin cukup. Envoy baru terasa unggul saat:

• Banyak service yang perlu routing dinamis dan discovery.
• Kebutuhan observability yang konsisten di semua service.
• Enkripsi mTLS antar service.
• Traffic yang perlu di-canary, dimirror, atau di-fault-inject.

docker image inspect envoyproxy/envoy:v1.31.0 --format '{{.Config.Env}}'

Perintah docker image inspect membaca metadata image, termasuk environment variable bawaan yang dipakai konfigurasi default Envoy. Ini contoh kecil betapa banyak informasi yang bisa diekspos dari image yang sama.

#Kelebihan Inti Envoy yang Akan Kita Pelajari

#Empat Pilar Utama

Sepanjang series ini, empat kemampuan ini akan terus muncul:

• Observability: metrics Prometheus, distributed tracing, dan access log yang kaya.
• Load balancing canggih: round robin, least request, ring hash, dan maglev.
• Circuit breaking: melindungi backend dari ledakan request.
• Configurability: statis maupun dinamis via xDS, plus filter yang bisa disusun bebas.
• Ekstensibilitas: native C++ filter maupun WASM yang bisa ditulis tanpa kompilasi Envoy.

Keempat pilar ini akan kita bedah satu per satu mulai episode 3 hingga 22. Tidak ada proxy lain yang menawarkan kombinasi lengkap ini dengan cara yang sama. Ingat baik-baik pilar ini, karena setiap episode di series ini mengulang salah satu dari pilar tersebut dari sudut pandang yang berbeda.

#Penutup

Episode 1 menempatkan Envoy dalam konteks sejarah dan ekosistem: lahir dari kebutuhan Lyft, menjadi standar data plane CNCF, dan kini mendukung service mesh paling besar di dunia. Kalian juga sudah memahami posisi Envoy dibanding NGINX dan HAProxy.

Inti yang harus dibawa pulang:

• Envoy lahir di Lyft pada 2016 dan menjadi proyek CNCF pada 2017.
• Envoy adalah data plane proxy layer-7 untuk microservices, bukan web server.
• NGINX dan HAProxy tetap hebat, tapi Envoy unggul di dynamic config dan observability.
• Service mesh memisahkan control plane dan data plane; Envoy adalah data plane-nya.
• Empat pilar Envoy: observability, load balancing, circuit breaking, configurability.
• Image Envoy resmi bisa dijalankan lewat docker run tanpa build apa pun.

Di episode 2 selanjutnya kita akan membahas konsep dasar dan arsitektur utama Envoy — listener, cluster, route, filter chain, dan endpoint, plus model konfigurasi bootstrap serta peran control plane versus data plane dan protokol xDS. Ini adalah fondasi mental yang akan kalian pakai di seluruh episode berikutnya.