3.16 API gateway dan service mesh

Tinjauan dan motivasi

Begitu Anda memecah satu program menjadi banyak layanan, muncul pertanyaan baru: siapa yang bertanggung jawab atas lalu lintas di antara mereka, dan lalu lintas yang masuk dari luar? Anda dapat menjawabnya dengan buruk dengan menebarkan perhatian yang sama (autentikasi, retry, timeout, pembatasan laju, pencatatan) ke setiap layanan secara manual, atau menjawabnya dengan baik dengan mendorong perhatian itu ke lapisan bersama yang diwarisi setiap layanan secara gratis. Bab ini tentang dua lapisan semacam itu. API gateway berdiri di pintu depan dan mengelola lalu lintas yang masuk dari klien. Service mesh berdiri di antara layanan Anda dan mengelola lalu lintas yang mengalir di antara mereka. Keduanya menyelesaikan masalah terkait di tempat berbeda, dan mencampuradukkan keduanya adalah kesalahan umum yang mahal.

Industri menamai kedua arah lalu lintas dengan metafora kompas. Lalu lintas utara-selatan (north-south) adalah lalu lintas yang melintasi batas sistem Anda: aplikasi seluler, peramban, atau mitra yang memanggil masuk. Lalu lintas timur-barat (east-west) adalah lalu lintas yang tetap di dalam sistem Anda: layanan A memanggil layanan B memanggil layanan C untuk memenuhi satu permintaan. API gateway adalah spesialis utara-selatan. Service mesh adalah spesialis timur-barat. Menjaga pembedaan itu tajam adalah gagasan paling berguna dalam bab ini, karena ia memberi tahu alat mana yang memiliki kebijakan mana, dan mencegah Anda melakukan pekerjaan yang sama dua kali.

Bagi tim besar, lapisan ini adalah cara Anda menegakkan kebijakan sekali alih-alih seratus kali. Ketika autentikasi, enkripsi saat transit, dan pembatasan laju hidup di lapisan bersama, perbaikan keamanan dikirim ke setiap layanan pada hari Anda men-deploy lapisan itu, alih-alih menunggu seratus backlog. Dalam pengaturan enterprise dan pemerintah, sentralisasi itu sering kali intinya: auditor menginginkan satu tempat yang dapat dibuktikan di mana akses diperiksa dan lalu lintas dienkripsi, dan gateway atau mesh bersama memberi mereka persis titik penegakan kebijakan itu. Bab ini bertumpu pada gaya arsitektural bab 3.2, kenyataan sistem terdistribusi bab 3.3, dan dasar-dasar jaringan bab 3.13, dan mengubahnya menjadi panduan konkret tentang siapa yang menangani lalu lintas Anda.

Prinsip utama

Pisahkan utara-selatan (gateway) dari timur-barat (mesh); biarkan masing-masing memiliki arahnya.
Dorong perhatian lintas bidang ke lapisan bersama agar Anda menulisnya sekali, bukan per layanan.
Adopsi service mesh hanya ketika jumlah layanan membuat pengkabelan per layanan menjadi biaya yang lebih besar.
Tetapkan satu titik penegakan kebijakan per perhatian; jangan pernah membiarkan gateway dan mesh sama-sama mengerjakan tugas yang sama.
Jaga layanan tetap tipis: platform menangani transpor, layanan menangani logika bisnis.
Pilih jaringan zero-trust berbasis identitas daripada kepercayaan berdasarkan lokasi jaringan.
Beli kompleksitas operasional mesh dengan mata terbuka, dan ukur apakah ia membayar.

Rekomendasi

Pahami apa yang dilakukan API gateway

API gateway adalah satu titik masuk yang berdiri di depan layanan Anda dan memediasi setiap permintaan dari dunia luar. Paling sederhana ia reverse proxy cerdas (server yang menerima permintaan klien dan meneruskannya ke backend yang tepat), tetapi gateway layak namanya dengan melakukan jauh lebih banyak daripada meneruskan. Ia merutekan setiap permintaan ke layanan yang benar berdasarkan path, host, atau header. Ia mengautentikasi pemanggil (memverifikasi siapa mereka) dan mengotorisasi permintaan (memeriksa apa yang boleh mereka lakukan), sehingga layanan di belakangnya dapat memercayai bahwa permintaan sudah melewati pintu depan. Ia menegakkan pembatasan laju (membatasi permintaan per klien seiring waktu) dan kuota (membatasi total pemakaian dalam jendela lebih panjang) agar satu klien berisik atau kasar tidak dapat membuat sisanya kelaparan.

Gateway juga membentuk ulang lalu lintas. Transformasi permintaan menulis ulang header, menerjemahkan antarprotokol, atau menyesuaikan format klien lama dengan ekspektasi layanan baru. Komposisi API memungkinkan gateway menyebarkan satu permintaan masuk ke beberapa layanan dan menjahit respons mereka menjadi satu, sehingga klien membuat satu panggilan alih-alih enam. Dukungan pembuatan versi memungkinkan Anda menjalankan v1 dan v2 API berdampingan dan merutekan setiap klien ke versi yang diharapkannya, yang membeli ruang untuk berevolusi tanpa merusak siapa pun. Memusatkan perhatian ini di tepi menjaga layanan Anda terfokus pada logika bisnis dan memberi Anda satu tempat untuk mengamati, mengamankan, dan membatasi segala yang masuk. Desain API yang difasadkan gateway adalah topik bab 2.3, dan pemeriksaan identitas yang dilakukannya bersandar pada bab 4.7.

Gunakan pola backend-for-frontend untuk klien yang berbeda

Satu API serba guna sering melayani aplikasi web, aplikasi seluler, dan integrasi mitra sekaligus, dan melayani semuanya sedikit buruk. Klien seluler menginginkan muatan kecil dan sedikit round trip karena bandwidth dan baterai langka; klien web dapat menangani respons lebih cerewet dan kaya; mitra menginginkan kontrak stabil yang tidak pernah mengejutkan mereka. Pola backend for frontend (BFF) menyelesaikan ketegangan ini dengan memberi setiap kelas klien gateway tipisnya sendiri, disesuaikan dengan kebutuhan klien itu, berdiri di depan layanan bersama di belakangnya.

BFF adalah gateway dengan audiens lebih sempit. BFF seluler menyusun dan memangkas respons agar aplikasi membuat satu panggilan efisien; BFF web mengekspos bentuk yang lebih penuh; BFF mitra memegang kontrak yang bergerak lambat dan berversi hati-hati. Setiap tim dapat mengembangkan BFF-nya sendiri tanpa menunggu yang lain, yang sering kali kemenangan sebenarnya, karena memisahkan tim klien satu sama lain. Biayanya lebih banyak bagian bergerak dan sebagian logika terduplikasi di seluruh BFF, jadi sisihkan pola ini untuk kasus di mana kebutuhan klien benar-benar menyimpang. Ketika semua klien menginginkan hal yang sama, satu gateway lebih sederhana dan lebih baik.

Pahami apa yang dilakukan service mesh

Service mesh mengelola lalu lintas timur-barat antarlayanan Anda, dan melakukannya tanpa meminta layanan itu mengubah kodenya. Mesh klasik bekerja dengan men-deploy proksi sidecar (proses proksi kecil yang berjalan di samping setiap instans layanan dan mencegat seluruh lalu lintas jaringannya). Layanan Anda mengira ia berbicara langsung dengan layanan lain; kenyataannya ia berbicara dengan sidecar lokalnya, yang menangani panggilan jaringan sebenarnya. Karena setiap permintaan kini mengalir melalui proksi yang dikendalikan platform, mesh dapat menegakkan perilaku seragam di setiap layanan, dalam bahasa apa pun, tanpa pustaka bersama untuk dijaga sinkron.

Apa yang ditegakkannya? Pertama, mutual TLS (mTLS), di mana kedua sisi setiap koneksi menunjukkan sertifikat dan mengenkripsi lalu lintas, sehingga panggilan antarlayanan terautentikasi dan privat secara bawaan. Kedua, manajemen lalu lintas: mesh dapat menggeser persentase kecil lalu lintas ke versi baru untuk rilis kenari (canary), membagi lalu lintas menurut header untuk pengujian, atau mencerminkan lalu lintas ke layanan bayangan. Ketiga, ketahanan: retry, timeout, dan circuit breaking (pola bab 2.20) yang diterapkan di lapisan platform, dikonfigurasi lewat kebijakan alih-alih dikodekan ke setiap layanan. Keempat, observabilitas: karena setiap permintaan melewati proksi, mesh memancarkan metrik, log, dan jejak terdistribusi yang konsisten untuk semua lalu lintas antarlayanan, memberi makan praktik observabilitas bab 9.2. Penulis layanan tidak menulis apa pun dari ini dan mendapat semuanya.

Kenali pola sidecar dan alternatif tanpa sidecar

Model sidecar elegan tetapi tidak gratis. Setiap instans layanan kini menjalankan kontainer proksi tambahan yang memakan memori dan CPU, dan setiap panggilan membuat dua lompatan jaringan ekstra (masuk ke sidecar lokal dan keluar dari sidecar jarak jauh), menambah sedikit latensi. Pada segelintir layanan beban ini tak terlihat; di ribuan pod ia menjadi baris nyata dalam tagihan komputasi dan anggaran latensi Anda. Biaya itu telah mendorong gelombang pendekatan tanpa sidecar, atau tanpa proksi.

Dua arah penting. Satu memindahkan fungsi mesh dari sidecar per pod ke proksi per node, sehingga banyak layanan pada mesin yang sama berbagi satu proksi alih-alih masing-masing menjalankan miliknya; ini menukar sebagian isolasi dengan penurunan besar beban. Yang lain, pendekatan tanpa proksi, menanamkan logika mesh langsung ke layanan lewat pustaka tipis atau runtime, menghapus lompatan ekstra sepenuhnya dengan biaya dependensi per bahasa. Perkembangan lebih baru mendorong sebagian fungsi mesh ke dalam kernel sistem operasi memakai eBPF (teknologi untuk menjalankan program tersandbox di dalam kernel Linux), yang dapat menegakkan kebijakan dan mengumpulkan telemetri dengan beban lebih rendah daripada proksi ruang pengguna. Anda tidak perlu bertaruh pada satu pemenang hari ini. Anda perlu tahu bahwa pajak sidecar itu nyata, bahwa alternatif ada, dan bahwa pilihan platform Anda tidak boleh mengunci Anda dari mengadopsinya kelak. Pola ini berada di atas fondasi orkestrasi kontainer bab 8.3.

Putuskan kapan mesh layak kompleksitasnya

Service mesh ampuh dan benar-benar rumit untuk dijalankan. Ia menambah control plane untuk dioperasikan, proksi untuk ditingkatkan, sertifikat untuk dirotasi, dan lapisan baru untuk di-debug ketika permintaan hilang. Kompleksitas itu layak dibeli ketika Anda punya cukup layanan sehingga mengkabel perhatian ini dengan tangan, per layanan dan per bahasa, berbiaya lebih daripada mengoperasikan mesh. Sinyal kasarnya adalah skala dan keberagaman poliglot: puluhan atau ratusan layanan, ditulis dalam beberapa bahasa, di mana pustaka bersama untuk mTLS dan retry akan menjadi mimpi buruk untuk dijaga konsisten. Pada skala itu, mesh membayar dirinya dalam keseragaman dan keamanan yang dapat dibuktikan.

Mesh tidak layak kompleksitasnya ketika Anda punya segelintir layanan, satu bahasa, atau tim kecil. Untuk sistem sederhana, pustaka atau kerangka kerja yang baik dapat memberi Anda mTLS, retry, dan metrik dengan beban operasional jauh lebih ringan daripada mesh penuh, dan gateway biasa plus pustaka klien yang masuk akal sering mencakup semua yang Anda butuhkan. Mengadopsi mesh karena modis, sebelum skala Anda menuntutnya, adalah cara umum menghabiskan setahun mengoperasikan infrastruktur yang menyelesaikan masalah yang tidak Anda punya. Mulai dengan gateway, tambahkan pola ketahanan dalam kode atau pustaka, dan raih mesh ketika jumlah layanan dan bahasa membuat pendekatan per layanan lebih mahal. Ini disiplin “apakah ia layak kompleksitasnya” yang sama yang dikunjungi berulang oleh bab cloud dan sistem terdistribusi (3.11 dan 3.3).

Hindari penanganan ganda di mana gateway dan mesh tumpang tindih

Gateway dan mesh tumpang tindih, dan tumpang tindih itu adalah tempat tim melukai diri sendiri. Keduanya dapat melakukan retry, keduanya dapat menegakkan timeout, keduanya dapat memeriksa identitas, keduanya dapat mengumpulkan telemetri. Jika gateway mencoba ulang permintaan tiga kali dan mesh juga mencobanya tiga kali di setiap lompatan internal, satu retry klien dapat meledak menjadi puluhan panggilan backend dan mengubah gangguan kecil menjadi badai retry. Jika kedua lapisan menegakkan timeout dan yang dalam lebih panjang daripada yang luar, yang luar menyerah sementara yang dalam terus bekerja, membuang upaya untuk respons yang tak akan dibaca siapa pun.

Perbaikannya adalah pembagian kerja yang jelas yang dituliskan dan disepakati. Tetapkan setiap perhatian ke tepat satu lapisan. Gateway memiliki perhatian utara-selatan: autentikasi pengguna akhir, batas laju dan kuota eksternal, transformasi permintaan, dan komposisi API untuk klien. Mesh memiliki perhatian timur-barat: mTLS antarlayanan, retry dan circuit breaking internal, dan pergeseran lalu lintas antarversi layanan. Di tempat perhatian dapat hidup di salah satunya, pilih satu pemilik dan buat lapisan lain meneruskan. Konfigurasikan anggaran retry dan hierarki timeout agar timeout luar selalu lebih panjang daripada pekerjaan dalam yang ditunggunya. Tujuannya setiap permintaan punya tepat satu tempat yang menangani setiap perhatian, dan tak ada permintaan yang dicoba ulang, diautentikasi, atau dicatat dua kali secara tak sengaja.

Perlakukan gateway dan mesh sebagai titik penegakan kebijakan untuk zero trust

Alasan terdalam menjalankan lapisan ini adalah arsitektur keamanan. Zero trust adalah prinsip bahwa tak ada permintaan yang dipercaya karena dari mana ia berasal; setiap permintaan harus membuktikan identitas dan otorisasinya, bahkan di dalam jaringan Anda sendiri. Model lama memercayai apa pun yang sudah di dalam perimeter, yang berarti satu layanan yang terbobol dapat berkeliaran bebas. Zero trust menggantikan kepercayaan lokasi jaringan dengan kepercayaan berbasis identitas pada setiap lompatan, dan gateway serta mesh adalah titik penegakan alami tempat identitas itu diperiksa.

Gateway adalah titik penegakan kebijakan untuk identitas eksternal: ia memverifikasi pengguna akhir atau mitra sebelum apa pun mencapai layanan Anda. Mesh adalah titik penegakan kebijakan untuk identitas beban kerja: setiap layanan mendapat identitas kriptografis, mTLS membuktikannya pada setiap panggilan, dan kebijakan memutuskan layanan mana boleh berbicara dengan mana. Bersama-sama mereka memberi Anda pertahanan berlapis, di mana permintaan diperiksa di tepi dan lagi antarlayanan, sehingga kompromi satu layanan tidak memberi gerak bebas ke yang lain. Dalam deployment multiklaster dan multiwilayah, mesh dapat memperluas jalinan identitas ini melintasi batas klaster, sehingga layanan di satu klaster mengautentikasi ke layanan di klaster lain dengan jaminan mTLS yang sama seperti yang dipakainya secara lokal, memberi Anda jaringan zero-trust yang konsisten bahkan saat jejak menyebar. Fondasi identitas di sini terhubung langsung dengan bab 4.7.

Trade-off: kelebihan dan kekurangan

Pendekatan	Kelebihan	Kekurangan
API gateway	Satu tempat untuk authn, batas laju, komposisi, pembuatan versi	Titik sempit tunggal untuk diskalakan dan dijaga sangat tersedia
Backend for frontend	Setiap klien mendapat API yang disesuaikan dan berkembang independen	Lebih banyak gateway untuk dijalankan; logika terduplikasi di seluruh BFF
Service mesh (sidecar)	mTLS seragam, retry, observabilitas tanpa perubahan kode	Beban proksi, latensi, dan control plane untuk dioperasikan
Mesh tanpa sidecar / tanpa proksi	Beban dan latensi lebih rendah daripada sidecar per pod	Kurang matang; isolasi lebih lemah atau dependensi per bahasa
Ketahanan berbasis pustaka	Sederhana dijalankan; tanpa infrastruktur tambahan	Duplikasi per bahasa; sulit dijaga konsisten pada skala besar
Mesh lintas klaster	Identitas zero-trust konsisten di mana-mana	Kompleksitas operasional dan jaringan signifikan

Ketegangan pusatnya adalah keseragaman versus biaya operasional. Lapisan bersama membeli konsistensi, keamanan yang dapat dibuktikan, dan kebijakan yang ditulis sekali, tetapi ia sistem nyata yang harus Anda jalankan, skalakan, amankan, dan debug, dan ia menyisipkan diri ke jalur setiap permintaan. Selesaikan ketegangan menurut skala dan kebutuhan. Gateway hampir selalu membayar begitu Anda punya klien eksternal, karena perhatian yang dipusatkannya tak dapat dihindari. Mesh membayar lebih lambat, ketika jumlah layanan dan bahasa membuat pengkabelan per layanan menjadi jalur yang lebih mahal. Di bawah ambang itu, pustaka dan gateway biasa memberi sebagian besar manfaat dengan sebagian kecil biaya. Di atasnya, keseragaman mesh layak bobotnya. Kekeliruan ke kedua arah adalah mengadopsi karena mode alih-alih kebutuhan: mesh terlalu dini adalah setahun yak-shaving, dan mesh yang dilewatkan terlalu lama adalah seratus implementasi mTLS buatan tangan yang tidak konsisten.

Pertanyaan untuk didiskusikan dengan tim Anda

Untuk setiap perhatian lintas bidang (autentikasi, retry, timeout, pembatasan laju, enkripsi, telemetri), lapisan tunggal mana yang memilikinya, dan dapatkah semua orang menyebut pemiliknya tanpa menebak? Ini pertanyaan yang mencegah penanganan ganda, dan kebanyakan tim belum pernah menjawabnya secara eksplisit, yang berarti jawabannya berbeda menurut layanan dan penulis. Bawa daftar konkret perhatian di sisi kiri dan lapisan Anda (pustaka klien, gateway, mesh, layanan individual) di bagian atas, dan isi grid bersama-sama. Tempat di mana dua sel diperiksa untuk satu perhatian adalah badai retry dan inversi timeout Anda yang menunggu terjadi. Baris kosong adalah perhatian yang tidak ditangani siapa pun sama sekali. Keluarannya satu tabel yang disepakati, diterbitkan di tempat setiap tim dapat melihatnya, yang mengatakan tepat satu lapisan memiliki setiap perhatian dan yang lain meneruskan. Tabel itu lebih berharga daripada konfigurasi gateway atau mesh sebanyak apa pun, karena ia yang menjaga kedua lapisan tidak saling bertarung.
Apakah kita benar-benar punya cukup layanan dan keberagaman bahasa untuk membenarkan service mesh, atau kita hendak membeli control plane untuk menyelesaikan masalah yang tidak kita punya? Mesh adalah komitmen operasional serius, dan jawaban jujur bagi banyak tim adalah bahwa pustaka yang baik plus gateway akan melayani mereka lebih baik hari ini. Bawa jumlah nyata layanan Anda, jumlah bahasa yang dipakai menulisnya, dan penilaian jujur seberapa banyak logika jaringan terduplikasi benar-benar menyakiti Anda sekarang. Lalu bawa sisi lainnya: siapa yang akan mengoperasikan mesh, meningkatkan proksinya, merotasi sertifikatnya, dan dipanggil ketika ia salah merutekan permintaan. Jika rasa sakit pengkabelan per layanan lebih kecil daripada biaya menjalankan mesh, Anda punya jawabannya, dan itu menunggu. Jika Anda tenggelam dalam kode mTLS dan retry yang tidak konsisten di puluhan layanan poliglot, mesh layak dipertahankan. Intinya memutuskan atas bukti, bukan atas seperti apa mesh tampak dalam ceramah konferensi.
Di mana batas zero-trust kita hari ini, dan apa yang terjadi jika satu layanan internal terkompromi? Banyak sistem masih memercayai apa pun yang sudah di dalam jaringan, yang berarti satu layanan yang terbobol dapat bergerak lateral dan menjangkau segala yang lain, dan tim sering menemukan ini hanya selama insiden. Telusuri radius ledakan dengan jujur: jika penyerang menguasai salah satu layanan Anda, apa yang dapat dipanggilnya, apa yang dapat dibacanya, dan apa yang menghentikannya? Bawa jawaban Anda saat ini tentang bagaimana panggilan antarlayanan diautentikasi dan dienkripsi, dan spesifiklah panggilan mana yang dilindungi mTLS dan mana yang kepercayaan teks biasa berdasarkan berada di jaringan yang sama. Tindakan yang menyusul adalah rencana yang disengaja untuk akses berbasis identitas pada setiap lompatan, dengan gateway memeriksa identitas eksternal dan mesh atau padanannya memeriksa identitas beban kerja, agar kompromi terkandung alih-alih katastrofik. Bahkan jika Anda belum siap menjalankan mesh penuh, menamai di mana batas kepercayaan sebenarnya berada adalah langkah jujur pertama.
Jika tingkat API gateway kita gagal sekarang, berapa banyak sistem yang gelap, dan sudahkah kita menguji kegagalan itu alih-alih mengasumsikannya hilang? Gateway memusatkan begitu banyak sehingga pemadamannya membuat segalanya di belakangnya offline, dan tim besar cenderung kurang berinvestasi pada redundansinya justru karena ia bekerja diam-diam sampai tidak. Timbang tarikan yang bersaing: satu gateway sederhana mudah dinalar dan murah dijalankan, sementara tingkat yang diskalakan horizontal dan multizona berbiaya lebih dan menambah konfigurasi failover dan kompleksitasnya sendiri. Bawa angka nyata ke diskusi, termasuk berapa instans berjalan hari ini, di berapa zona ketersediaan, berapa waktu failover, dan kapan terakhir kali Anda menjalankan game day yang mematikan gateway dengan sengaja. Untuk platform enterprise dan pemerintah yang membawa komitmen uptime atau tingkat layanan undang-undang, tambahkan penalti kontraktual atau regulasi untuk pemadaman, karena pintu depan tanpa redundansi adalah risiko ketersediaan yang diam-diam telah Anda terima atas nama setiap layanan dan setiap warga di belakangnya.
Sudahkah kita mengukur pajak sidecar yang sebenarnya dikenakan mesh kita, dan apakah kita punya rencana untuk alternatif tanpa sidecar dan eBPF, atau kita membayarnya secara buta? Pada skala besar beban proksi per pod dalam komputasi dan latensi berhenti tak terlihat dan menjadi baris nyata dalam anggaran, namun banyak tim menjalankan ribuan sidecar tanpa pernah mengukur biayanya. Ketegangannya antara kematangan dan isolasi model sidecar di satu sisi dan beban lebih rendah proksi per node, pustaka tanpa proksi, atau pendekatan eBPF kernel di sisi lain, yang lebih baru dan menukar sebagian isolasi atau menambah dependensi per bahasa. Bawa angka terukur: memori dan CPU yang dimakan proksi di seluruh armada, latensi ekor tambahan per lompatan, dan berapa pecahan tagihan komputasi Anda yang diwakili mesh. Untuk enterprise besar yang menjalankan mesh di ribuan pod, atau platform pemerintah di bawah pengawasan anggaran, ini keputusan pengeluaran yang pada akhirnya akan ditanyakan pengawasan, sehingga mengetahui pajak dan apakah pilihan platform Anda menjaga alternatif yang lebih murah tetap terbuka adalah uji tuntas dasar.
Apakah setiap kelas klien benar-benar membutuhkan backend for frontend-nya sendiri, atau kita hendak menduplikasi logika di seluruh gateway untuk klien yang sebenarnya menginginkan hal yang sama? Pola BFF memisahkan tim klien dan memungkinkan masing-masing mengembangkan kontrak yang disesuaikan, tetapi setiap BFF baru adalah gateway lain untuk dijalankan, diamankan, dan dijaga sinkron, dan logika terduplikasi di antaranya diam-diam menjadi pajak pemeliharaan. Pertimbangan yang bersaing adalah otonomi tim dan efisiensi khusus klien versus biaya operasional dan penyimpangan banyak gateway yang nyaris identik. Bawa bukti seberapa jauh kebutuhan klien benar-benar menyimpang: ukuran muatan, jumlah round trip, irama pembuatan versi, dan seberapa sering perubahan satu klien akan memblokir klien lain di bawah satu gateway bersama. Dalam organisasi besar dengan banyak tim klien, atau platform pemerintah yang melayani aplikasi web publik, aplikasi seluler, dan integrasi mitra sekaligus, pertanyaan jujurnya apakah penyimpangan itu membenarkan proliferasi, karena BFF per klien yang semuanya menginginkan bentuk yang sama adalah sebaran yang akan Anda bayar untuk dipelihara selama bertahun-tahun.

Lensa sektor

Startup. Kirim API gateway dan lewati mesh. Dengan segelintir layanan dan tim kecil, satu gateway menangani autentikasi, batas laju, dan komposisi, sementara pustaka klien bersama memberi Anda mTLS dan retry dengan sebagian kecil biaya control plane. Sumber daya Anda yang paling langka adalah perhatian rekayasa, jadi mesh yang tidak sanggup Anda operasikan adalah liabilitas, bukan parit. Jaga gateway cukup redundan untuk selamat dari matinya satu node, dan tinjau ulang mesh hanya ketika jumlah layanan dan keberagaman bahasa benar-benar memaksa pertanyaannya.

Bisnis kecil. Anda tidak punya tim platform untuk menjalankan mesh, jadi bersandarlah pada apa yang diberikan platform hosting atau produk gateway Anda secara langsung: TLS terkelola, pembatasan laju bawaan, dan gateway ter-hosting alih-alih yang Anda tambal sendiri. Bingkai pilihan sebagai beli versus bangun, dan belilah, karena API gateway terkelola berbiaya lebih rendah daripada jam insinyur untuk mengoperasikan milik sendiri. Perlakukan enkripsi antarlayanan internal sebagai fitur yang disediakan platform Anda, bukan proyek yang Anda isi stafnya.

Enterprise. Dengan ratusan layanan di banyak tim dan bahasa, mesh layak kompleksitasnya, dan kerja sebenarnya adalah tata kelola: satu pembagian kerja tertulis agar gateway dan mesh tidak pernah menangani ganda suatu perhatian, mTLS dan telemetri seragam, dan tim platform yang memiliki peningkatan proksi dan rotasi sertifikat. Auditor menginginkan satu titik penegakan yang dapat dibuktikan untuk akses dan enkripsi, jadi bakukan antarmuka dan jadikan kebijakan sesuatu yang diwarisi tim alih-alih diimplementasikan ulang. Kelola pajak sidecar sebagai baris anggaran nyata, dan jaga opsi tanpa sidecar tetap terbuka agar Anda tidak terkunci keluar dari pendekatan yang lebih murah kelak.

Pemerintah. Aturan pengadaan, transparansi, dan akuntabilitas publik membentuk arsitektur. Perlakukan gateway dan mesh sebagai tulang punggung zero-trust yang diharapkan regulator: setiap warga dan mitra diautentikasi di pintu depan, setiap panggilan internal diautentikasi dan dienkripsi oleh identitas beban kerja, dan jejak audit di setiap titik penegakan membuktikan di mana akses diperiksa dan di mana lalu lintas dienkripsi. Pilih standar terbuka dan konfigurasi portabel daripada lock-in proprietari yang mungkin dilarang aturan pengadaan, dan terbitkan, bila sesuai, bagaimana platform melindungi data warga saat melintasi setiap batas.

Contoh

Startup. Sebuah startup dua belas orang menjalankan delapan layanan di balik satu API gateway. Gateway menangani semua pekerjaan utara-selatan: ia mengautentikasi pengguna dengan pemeriksaan token, menegakkan batas laju per paket agar pengguna tingkat gratis tidak membanjiri sistem, dan menyusun beberapa endpoint cerewet menjadi panggilan ramah-seluler tunggal. Untuk lalu lintas timur-barat mereka dengan sengaja melewati service mesh, karena delapan layanan dalam dua bahasa tidak membenarkan control plane. Sebagai gantinya mereka mendapat mTLS dan retry dari pustaka klien bersama dan manajemen sertifikat bawaan platform mereka, dan mereka mengumpulkan jejak dengan agen ringan. Ketika kemudian menambah klien seluler khusus dengan kebutuhan muatan lebih ketat, mereka memperkenalkan backend for frontend seluler di samping gateway web yang ada. Mereka meninjau ulang pertanyaan mesh setiap tahun dan terus memutuskan, dengan tepat, bahwa mereka belum melewati ambang di mana ia akan membayar.

Enterprise. Sebuah bank multinasional menjalankan beberapa ratus layanan di banyak tim dan bahasa, dan di sini service mesh layak kompleksitasnya. Setiap layanan mendapat identitas beban kerja dan mTLS secara bawaan, sehingga semua lalu lintas internal diautentikasi dan dienkripsi tanpa tim mana pun menulis kode kripto, yang memuaskan organisasi keamanan sekaligus auditor yang menginginkan satu titik penegakan yang dapat dibuktikan. Mesh menerapkan retry, timeout, dan circuit breaking seragam lewat kebijakan, dan menggeser lalu lintas secara bertahap untuk rilis kenari sehingga deploy buruk menyentuh satu persen pengguna sebelum menyentuh semuanya. Tingkat API gateway menghadapi lalu lintas eksternal dan mitra, memiliki autentikasi, kuota, dan pembuatan versi, dengan aturan tertulis tegas bahwa retry internal hidup hanya di mesh dan batas laju eksternal hidup hanya di gateway, sehingga kedua lapisan tidak pernah menangani ganda suatu permintaan. Telemetri konsisten dari setiap proksi memberi makan platform observabilitas pusat yang memungkinkan satu insinyur on-call melacak permintaan melintasi puluhan lompatan layanan.

Pemerintah. Sebuah otoritas pajak nasional memodernisasi platform pengajuan yang menghadap warga dan memperlakukan gateway dan mesh sebagai tulang punggung arsitektur zero-trust yang dituntut regulator. API gateway adalah pintu depan terkendali: setiap warga dan setiap mitra diautentikasi dan diotorisasi di sana, batas laju eksternal melindungi sistem selama lonjakan tenggat pengajuan, dan format klien lama ditransformasi di tepi agar integrasi warisan tetap berfungsi. Di belakangnya, service mesh memberi setiap layanan internal identitas kriptografis dan menegakkan mTLS pada setiap panggilan, sehingga tak ada layanan yang dipercaya semata karena berada di dalam jaringan, dan kebijakan akses secara eksplisit mendaftar layanan mana boleh memanggil mana. Karena platform mencakup beberapa pusat data untuk ketahanan, mesh memperluas jaminan identitas dan enkripsi yang sama melintasi klaster, memberi jaringan zero-trust yang konsisten di seluruh negeri. Setiap titik penegakan memancarkan jejak audit, sehingga otoritas dapat membuktikan kepada badan pengawas persis di mana akses diperiksa dan di mana lalu lintas dienkripsi.

Kasus bisnis: motivasi, ROI, dan TCO

Imbal hasil gateway mudah terlihat dan biasanya besar. Alih-alih setiap layanan mengimplementasikan ulang autentikasi, pembatasan laju, dan pencatatan permintaan, Anda membangun itu sekali di tepi dan setiap layanan mewarisinya. Perbaikan keamanan atau kebijakan batas laju baru dikirim dalam satu deploy alih-alih seratus, yang memperpendek waktu menutup kerentanan dan menurunkan biaya setiap audit, karena ada satu tempat untuk diperiksa. Fitur komposisi dan pembuatan versi memangkas round trip klien dan memungkinkan Anda mengembangkan API tanpa merusak pemanggil, yang mengurangi biaya latensi maupun pajak koordinasi antartim. Untuk hampir sistem mana pun dengan klien eksternal, gateway membayar dirinya dengan cepat.

Service mesh punya kasus bisnis yang lebih halus, karena total biaya kepemilikannya nyata dan berkelanjutan. Anda membayar komputasi dan latensi proksi, insinyur yang mengoperasikan control plane, dan kurva belajar men-debug lapisan baru. Biaya itu dibenarkan ketika alternatifnya (implementasi mTLS, retry, dan telemetri per layanan dan per bahasa) akan lebih besar dan, lebih buruk, tidak konsisten dengan cara yang menciptakan celah keamanan dan pemadaman. Pada skala tinggi mesh mengubah seratus solusi buatan tangan yang rapuh menjadi satu yang seragam dan dapat dibuktikan, dan ROI muncul sebagai insiden keamanan lebih sedikit, deployment aman lebih cepat lewat pergeseran lalu lintas, dan observabilitas yang jauh lebih baik. Di bawah skala itu, perhitungan jujur sering mendukung pustaka dan gateway, dan langkah disiplinnya adalah menunggu. Untuk mengajukan kasus kepada pimpinan, hubungkan gateway dengan metrik yang sudah mereka lacak (waktu memperbaiki kerentanan, biaya audit, beban koordinasi API) dan hubungkan mesh dengan penahanan insiden keamanan, keselamatan deployment, dan biaya duplikasi poliglot yang digantikannya.

Anti-pola dan jebakan

Mesh sebelum Anda membutuhkannya: mengadopsi service mesh penuh pada segelintir layanan, membeli control plane untuk menyelesaikan masalah yang belum Anda punya.
Retry ganda: gateway dan mesh sama-sama mencoba ulang, sehingga satu panggilan klien berlipat menjadi badai retry backend yang memperkuat pemadaman.
Inversi timeout: timeout dalam yang lebih panjang daripada yang luar, sehingga pemanggil menyerah sementara yang dipanggil terus mengerjakan respons yang tak akan dibaca siapa pun.
Gateway sebagai monolit: menjejalkan logika bisnis ke gateway sampai ia menjadi hambatan bersama yang harus dikoordinasikan setiap tim untuk diubah.
Titik kegagalan tunggal: menjalankan satu instans gateway tanpa redundansi, sehingga pintu depan yang gagal menjatuhkan setiap layanan di belakangnya.
Memercayai jaringan: memperlakukan apa pun di dalam perimeter sebagai aman, sehingga satu layanan terkompromi dapat bergerak lateral dan menjangkau segalanya.
Kepemilikan tumpang tindih: tanpa pembagian kerja tertulis, sehingga perhatian yang sama ditangani di kedua lapisan secara tak sengaja dan tak ada yang tahu mana yang berwenang.
Sebaran BFF: membuat backend for frontend per klien padahal klien menginginkan hal yang sama, melipatgandakan gateway dan menduplikasi logika tanpa keuntungan.
Mengabaikan pajak sidecar: men-deploy ribuan sidecar tanpa mengukur beban komputasi dan latensi, lalu bertanya-tanya ke mana anggaran pergi.

Model kematangan

Tingkat 1, Memulai: Layanan berbicara satu sama lain langsung tanpa lapisan bersama. Autentikasi, retry, dan timeout dikodekan tangan per layanan dan tidak konsisten. Lalu lintas internal sering teks biasa dan dipercaya karena berada di jaringan, dan tidak ada satu tempat untuk menegakkan kebijakan atau mengamati lalu lintas. Keputusan reaktif, dibuat layanan demi layanan ketika masalah muncul.
Tingkat 2, Mengembangkan: API gateway menghadapi lalu lintas eksternal dan memusatkan autentikasi, pembatasan laju, dan perutean, tetapi perhatian timur-barat ditangani pustaka bersama dengan adopsi tidak merata. Sebagian layanan punya mTLS; banyak yang tidak. Tim mengenali pembedaan utara-selatan versus timur-barat, namun kepemilikan informal dan praktik berbeda dari satu tim ke tim lain.
Tingkat 3, Membakukan: Perhatian utara-selatan dan timur-barat dipisahkan dengan bersih dengan pembagian kerja tertulis yang diterapkan di seluruh organisasi. Gateway memiliki identitas eksternal, kuota, dan komposisi; mesh atau lapisan pustaka konsisten memiliki mTLS internal, retry, dan telemetri. Tumpang tindih diselesaikan sehingga tak ada perhatian yang ditangani ganda, lalu lintas internal dienkripsi dan diperiksa identitasnya secara bawaan, dan standar terdokumentasi serta ditegakkan alih-alih diserahkan pada kebijaksanaan setiap tim.
Tingkat 4, Mengelola: Lapisan lalu lintas diukur dan dikendalikan terhadap garis dasar. Anda melacak pajak sidecar dalam komputasi dan latensi ekor per lompatan, ketersediaan gateway dan mesh terhadap anggaran galat, insiden amplifikasi retry dan inversi timeout, cakupan mTLS sebagai persentase panggilan internal, dan waktu mendorong perubahan kebijakan ke seluruh armada. Metrik menggerbangi keputusan: peningkatan proksi, anggaran retry baru, atau aturan kenari dinilai atas data terhadap garis dasar alih-alih intuisi, dan penyimpangan apa pun dari standar memicu perbaikan.
Tingkat 5, Mengorkestrasi: Gateway dan mesh adalah titik penegakan kebijakan untuk arsitektur zero-trust yang matang, dengan identitas diperiksa pada setiap lompatan lintas klaster dan wilayah. Pergeseran lalu lintas menggerakkan pengiriman progresif yang aman, observabilitas seragam dan kaya, dan organisasi terus mengevaluasi serta mengadopsi pendekatan tanpa sidecar, tanpa proksi, dan eBPF di tempat mereka membayar. Lapisan lalu lintas terintegrasi dengan keamanan, pengiriman, dan perencanaan kapasitas, dan beradaptasi seiring bergesernya skala, bahasa, dan gambaran risiko.

Gagasan untuk didiskusikan

Jika API gateway tunggal Anda mati sekarang, berapa banyak layanan yang menjadi tak terjangkau, dan apa rencana Anda untuk membuat pintu depan redundan?
Perhatian mana dalam sistem Anda yang saat ini ditangani di gateway dan di layanan (atau pustaka), dan bagaimana Anda akan membuktikan ia tidak ditangani ganda?
Pada jumlah layanan dan bahasa berapa tim Anda akan sepakat bahwa mesh akhirnya layak kompleksitasnya, dan seberapa jauh Anda dari garis itu?
Jika penyerang mengkompromikan satu layanan internal besok, layanan lain mana yang dapat dijangkaunya, dan pemeriksaan identitas apa yang akan menghentikannya?
Apakah pendekatan mesh tanpa sidecar atau berbasis eBPF sudah cukup matang untuk platform Anda, dan apa yang akan Anda ukur untuk memutuskan?
Apakah setiap klien Anda yang berbeda benar-benar membutuhkan backend for frontend sendiri, atau Anda hendak menduplikasi logika yang dapat tetap bersama?

Poin-poin utama

Pisahkan lalu lintas utara-selatan (ditangani API gateway) dari timur-barat (ditangani service mesh); masing-masing memiliki arahnya, dan mencampuradukkannya menyebabkan penanganan ganda.
Gateway memusatkan perutean, autentikasi, otorisasi, pembatasan laju, kuota, transformasi permintaan, komposisi, dan pembuatan versi, agar layanan tetap tipis dan kebijakan hidup di satu tempat.
Service mesh memberi Anda mTLS, pergeseran lalu lintas, retry dan circuit breaking tingkat platform, dan observabilitas seragam tanpa mengubah kode layanan, secara klasik lewat proksi sidecar.
Adopsi mesh hanya ketika jumlah layanan dan bahasa membuat pengkabelan per layanan menjadi jalur yang lebih mahal; di bawah itu, pustaka plus gateway menang, dan pajak sidecar cukup nyata untuk diawasi.
Perlakukan gateway dan mesh sebagai titik penegakan kebijakan arsitektur zero-trust, tetapkan setiap perhatian lintas bidang ke tepat satu lapisan, dan periksa identitas pada setiap lompatan lintas klaster.

Referensi dan bacaan lanjutan

Sam Newman, Building Microservices: Designing Fine-Grained Systems
Chris Richardson, Microservices Patterns: With Examples in Java
Lee Calcote dan Zack Butcher, Istio: Up and Running
Ken Owens, Alois Reitbauer, dan lainnya; CNCF Cloud Native Landscape dan dokumentasi service mesh
Evan Gilman dan Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Scott Rose, Oliver Borchert, Stu Mitchell, dan Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
Susan Fowler, Production-Ready Microservices