Latest / M365.FM – Podcast Microsoft 365, Copilot & AI Bahasa Indonesia / API Gateway dijelaskan: routing, keamanan, dan rate limiting untuk microservices – apakah Anda membutuhkannya? (Sulih Suara AI)

Transcript

API Gateway dijelaskan: routing, keamanan, dan rate limiting untuk microservices – apakah Anda membutuhkannya? (Sulih Suara AI) · M365.FM – Podcast Microsoft 365, Copilot & AI Bahasa Indonesia

• 0:00
  Siap untuk 10 hari pembahasan Microsoft 365, Copilot, AI, Azure, dan para penggerak, masa depan dunia kerja.
• 0:07
  Januari ini, M365-Con kembali hadir dan kami tampil lebih besar.
• 0:12
  Bergabunglah untuk sesi langsung, demo dunia nyata dan pengetahuan praktis dari MVP serta pakar industri dunia.
• 0:19
  Tanpa jargon yang tak ada habisnya, kami menangani tantangan nyata.
• 0:23
  Copilot Studio, agen AI, fabrik, keamanan, tata kelola, dan otomatisasi.
• 0:28
  Baik Anda seorang profesional IT, pengembang, atau pemimpin bisnis ada sesi yang dirancang khusus untuk Anda.
• 0:35
  Selama 10 hari penuh, Anda bisa menjelajahi berbagai teknologi dan terhubung dengan komunitas global.
• 0:40
  Taksikan langsung dan bawa pulang keopasan praktis untuk organisasi Anda.
• 0:45
  Januari 2027, 10 hari, satu komunitas Microsoft.
• 0:49
  Pendaftaran sudah dibuka sekarang.
• 0:51
  Kunjungi M365-Con.net dan amankan tempat Anda hari ini.
• 0:56
  Itu di M365-Con.net.
• 0:58
  Daftar sekarang di M365-Con.net dan sampai jumpa langsung di bulan Januari.
• 1:05
  Anda telah membangun aplikasi yang berfungsi, lalu menambah layanan lain lagi, dan tiba-tiba mengarahkan lalu lintas antar layanan menjadi MVP buruk.
• 1:11
  Jadi apa sebenarnya API Gateway itu dan apakah Anda benar-benar membutuhkannya?
• 1:14
  Di akhir episode ini, Anda akan paham fungsi API Gateway mengapa,
• 1:17
  yang mengatasi kekacauan manajemen banyak layanan dan cara mengetahui apakah Anda membutuhkannya.
• 1:22
  Mari mulai dengan masalahnya, lalu komponennya, dan bagaimana semua itu sering berkaitan.
• 1:26
  Masalahnya, terlalu banyak pintu.
• 1:29
  Bayangkan Anda menjalankan perusahaan yang berkembang besar.
• 1:32
  Anda punya tim sales di lantai tiga, akutan CD, ruang bawah tanah, dan IT di side belakang.
• 1:37
  Sekarang, bayangkan setiap departemen itu punya pintu depan sendiri,
• 1:39
  nomor telepon sendiri, dan satpam sendiri, dan satpam sendiri yang tidak berkomunikasi satu sama.
• 1:42
  Jika Anda seorang pengunjung yang ingin mengantar paket, semoga berhasil.
• 1:46
  Anda harus tahu persis pintu mana yang digunakan,
• 1:47
  satpam mana yang diajak bicara, dan apa yang harus dilakukan saat satpam sedang istri.
• 1:51
  Itulah yang terjadi saat aplikasi Anda memiliki banyak layanan back-end,
• 1:53
  dan setiap klien memanggilnya satu per satu secara langsung.
• 1:56
  Klien, baik itu aplikasi seluler, situs web, atau layanan lain,
• 1:59
  harus tahu di mana setiap layanan berada, cara autentikasi dengan tiap layanan,
• 2:02
  dan apa yang harus dilakukan saat ada masalah.
• 2:04
  Setiap layanan harus menangani keamanannya sendiri,
• 2:07
  pembatasan kecepatannya sendiri, dan penanganan errornya sendiri.
• 2:09
  Itu adalah pekerjaan duplikat, dan mudah sekali bagi sistem untuk menjadi tidak konsisten.
• 2:12
  Contohnya ambil bank sebagai contoh.
• 2:14
  Mereka memiliki layanan terpisah untuk rekening pembayaran, pinjaman, dan deteksi penipuan.
• 2:17
  Dengan cara lama, setiap layanan terekspos secara langsung.
• 2:19
  Sebuah aplikasi seluler harus mengetahui 4 URL berbeda,
• 2:22
  4 metode autentikasi berbeda, dan 4 cara berbeda untuk menangani kesalahan.
• 2:25
  Itu berarti kompleksitas 4 kali lipat, dan risiko kesalahan 4 kali lebih besar,
• 2:29
  dan kekacauan itulah yang dirancang untuk diperbaiki oleh API Gateway.
• 2:32
  Jadi, apa solusinya?
• 2:34
  Apa itu API Gateway?
• 2:34
  Bayangkan API Gateway seperti resepsionis di sebuah hotel.
• 2:38
  Saat Anda masuk, Anda tidak perlu tahu di lantai mana bagian kebersihan berada,
• 2:41
  di mana dapurnya, atau cara menghubungi tim pemeliharaan.
• 2:44
  Anda cukup menghampiri meja resepsionis?
• 2:46
  Sampaikan apa yang Anda butuhkan, dan mereka yang akan mengurus sisanya.
• 2:48
  Mereka meneruskan permintaan Anda ke orang yang tepat,
• 2:50
  meriksa izin Anda, bahkan menangani permintaan dasar secara mandiri.
• 2:54
  API Gateway melakukan hal yang sama untuk perangkat lunak Anda.
• 2:57
  Ini adalah satu titik masuk yang berada di antara klien dan layanan backend.
• 3:01
  Setiap permintaan harus melalui Gateway terlebih dahulu.
• 3:03
  Gateway memutuskan ke mana permintaan dikirim, apakah diizinkan,
• 3:06
  dan apa yang harus dikirim kembali.
• 3:07
  Sekarang ini bukanlah ide baru.
• 3:09
  Reverse proxy sudah ada selama puluhan tahun,
• 3:11
  tetapi iGateway menjadi sangat penting dengan adanya microservices.
• 3:14
  Saat Anda memicau aplikasi menjadi banyak, layanan kecil Anda tiba-tiba memiliki banyak.
• 3:17
  Gateway memberi Anda satu pintu depan.
• 3:19
  Di dunia Azure, Azure API Management adalah platform lengkap,
• 3:21
  dan Gateway adalah komponen inti yang menangani lalu lintas.
• 3:25
  Namun polanya tetap sama di mana saja.
• 3:27
  Satu titik masuk, kontrol terpusat.
• 3:29
  Setiap permintaan masuk, Gateway memeriksanya, merutekannya,
• 3:31
  dan mengirimkan respons kembali.
• 3:33
  Klien tidak pernah berkomunikasi langsung dengan LMPK Anda.
• 3:35
  Klien hanya berkomunikasi dengan Gateway.
• 3:37
  Mari kita berdapat arti sebenarnya dari hal tersebut.
• 3:39
  Dimulai dengan tugas paling mendasar, yaitu perutean.
• 3:42
  Bagian pertama, merutekan lalu lintas.
• 3:44
  Tugas paling sederhana dari API Gateway adalah perutean,
• 3:46
  yaitu mengarahkan setiap permintaan kelayanan yang tepat.
• 3:49
  Pikirkan tentang cara kerjas web.
• 3:50
  Saat Anda mengeklik tautan, perang-perang Anda mengirimkan permintaan.
• 3:53
  Permintaan tersebut memiliki jalur.
• 3:54
  Jika jalurnya adalah pengguna, Gateway tahu untuk mengirimkannya kelayanan pengguna.
• 3:57
  Jika jalurnya adalah pesanan, permintaan diarahkan kelayanan.
• 3:59
  Gateway membaca jalur tersebut, menentukan kemana harus pergi, lalu meneruskannya.
• 4:03
  Tanpa Gateway, klien Anda harus mengetahui setiap URL layanan.
• 4:07
  Aplikasi seluler memerlukan alamat layanan pengguna, layanan pesanan, layanan pembayaran, dan layanan katalog.
• 4:12
  Itu adalah banyak URL yang harus diklon.
• 4:14
  Dan jika salah satu alamat tersebut berubah, Anda harus memperbarui setiap klien.
• 4:17
  Dengan Gateway, klien hanya perlu mengetahui satu URL.
• 4:19
  Alamat Gateway tersebut.
• 4:20
  Mereka tidak peduli di mana layanan sebenarnya berat.
• 4:22
  Mereka hanya mengirim permintaan ke Gateway dan Gateway yang menangani sisanya.
• 4:26
  Ini adalah salah satu kasus penggunaan API Gateway yang paling umum,
• 4:28
  yaitu perutean berbasis sumber daya.
• 4:30
  Penelitian Apache Apisiks menyebutnya secara eksplisit.
• 4:32
  Anda melakukan perutean berdasarkan path, metode HTTP, header, bahkan geolokasi klien.
• 4:37
  Jika seseorang di Eropa mengirim permintaan, Anda bisa merutekannya ke pusat data Eropa.
• 4:41
  Jika seseorang di AS mengirim permintaan, mereka diarahkan ke pusat data.
• 4:44
  Klien tidak tahu bahwa semuanya sedang terlihat.
• 4:46
  Mereka hanya menerima respon yang cepat.
• 4:48
  Perutean juga menangani pembuatan versi.
• 4:49
  Takkanlah Anda memiliki versi baru dari layanan penggunaan.
• 4:51
  Klien lama tetap menggunakan Provee 1 perusers dan klien baru menggunakan Provee Web Reusers.
• 4:55
  Gateway merutekan mereka ke back-end yang berbeda.
• 4:58
  Klien lama tetap berfungsi saat Anda meluncurkan versi baru.
• 5:01
  Anda dapat mengubah back-end tanpa merusak klien Anda.
• 5:04
  Itu sangat penting saat Anda mengelola aplikasi langsung dengan penggunaan nyata.
• 5:07
  Pikirkan tentang platform e-commerce.
• 5:09
  Anda memiliki layanan terpisah untuk katalog, keranjang belanja, check-out, dan akun pengguna.
• 5:13
  Tanpa Gateway, aplikasi seluler harus mengetahui 4 URL yang berbeda.
• 5:16
  Dengan Gateway aplikasinya Provee 1.
• 5:19
  Gateway membaca platnya, katalog, keranjang, check-out, akun, dan mengirim setiap permintaan kelainan yang tepat.
• 5:25
  Perhubungan sederhana mudah.
• 5:26
  Tugas berikutnya adalah di mana hal itu menjadi sangat berupa.
• 5:29
  Bagian 2, keamanan di pintu depan.
• 5:31
  Tiap panggilan API harus diperiksa.
• 5:33
  Tapi membuat permintaan ini, apakah mereka memiliki izin yang tepat?
• 5:36
  Tanpa Gateway, setiap layanan harus menangani autentikasinya sendiri.
• 5:39
  Itu berarti pekerjaan duplikat dan mudah sekali terjadi kesalahan.
• 5:42
  Satu layanan mungkin meriksa token dengan benar,
• 5:44
  yang lain mungkin melewatkan langkah, dan yang lain menggunakan metode yang benar-benar berbeda.
• 5:48
  Hasilnya adalah keamanan yang tidak konsisten di seluruh aplikasi Anda.
• 5:51
  Gateway mengubah hal itu.
• 5:52
  Gateway menangani autentikasi dan otorisasi di satu tempat terpusat.
• 5:55
  Satu tempat untuk memeriksa, satu tempat untuk menegakkan, satu tempat untuk memperbarui saat kebicaraan dulu.
• 5:59
  Itu adalah perhatian terbaik aman utama.
• 6:01
  Gateway mengvalidasi kunci API, JWT, token O-out, atau sertifikat pada setiap permintaan.
• 6:06
  Setiap permintaan melalui pemeriksaan yang sama. Tidak ada pengicuari.
• 6:10
  Gateway juga dapat menegakkan aturan. Anda bisa mengatakan kunci API ini hanya bisa memanggil endpoint baca.
• 6:15
  Atau, klien ini hanya bisa mengakses layanan katalog, bukan layanan pembayaran.
• 6:19
  Anda menentukan izin yang terperinci di tingkat Gateway, dan izin tersebut berlaku secara otomatis.
• 6:23
  Layanan backend tidak perlu pusing memikirkan otorisasi.
• 6:26
  Mereka hanya memproses permintaan dan mengirimkan data kembali.
• 6:28
  Inap poinnya.
• 6:29
  Gateway adalah satu tempat untuk mencabut akses saat terjadi masalah.
• 6:32
  Jika kunci API klien dikompromikan, Anda mencabutnya di Gateway.
• 6:36
  Satu perubahan selesai. Anda tidak perlu memperbarui setiap layanan atau memulai ulang apa.
• 6:40
  Permintaan berikutnya dari kunci tersebut langsung ditolak.
• 6:43
  Ambil contoh nyata, sebuah bank memiliki layanan pembayaran dan layanan penagihan.
• 6:46
  Hanya layanan pembayaran yang butuh akses tulis ke sistem penagihan.
• 6:49
  Gateway menegakkan aturan tersebut.
• 6:51
  Jika klien mencoba menulis ke sistem penagihan lewat endpoint yang salah, Gateway memblokirnya.
• 6:55
  Layanan penagihan bahkan tidak pernah melihat permintaan tersebut.
• 6:57
  Gateway juga mendukung mutual TLS dan integrasi WAF untuk perlindungan lebih mendalam.
• 7:01
  Namun pada intinya, ini adalah garis pertama Anda.
• 7:04
  Keamanan adalah satu hal, tapi bagaimana jika terlalu banyak permintaan datang sekarang?
• 7:08
  Bagian 3. Manajemen lalu lintas.
• 7:10
  Apa yang terjadi saat 10 ribu pengguna mengakses aplikasi Anda secara bersama?
• 7:14
  Mungkin Anda mengadakan flash sale, peluncuran produk viral, atau hanya hari selasa biasa saat semua orang login bersamaan.
• 7:20
  Tanpa Gateway, layanan backend Anda akan langsung dibanjiri dan bisa lumpuh.
• 7:24
  Tidak perlahan, tapi sekaligus.
• 7:26
  Disitulah manajemen lalu lintas berperan.
• 7:28
  Gateway dapat membatasi jumlah permintaan yang bisa dibuat setiap klien.
• 7:32
  Batasan laju dan throttling adalah fitur standar.
• 7:34
  Anda menetapkan aturan di Gateway dan Gateway menegakkan.
• 7:37
  Layanan backend Anda tidak akan merasakan lonjakan tersebut.
• 7:39
  Anda bisa menetapkan kuota per pengguna, per kunci API, atau per alamat IP.
• 7:43
  Misalnya Anda memiliki tingkat gratis untuk API Anda.
• 7:45
  Pengguna gratis mendapatkan 100 per jam.
• 7:47
  Pengguna premium mendapatkan 10 ribu.
• 7:48
  Gateway melacak setiap permintaan dan menegakkan batasan tersebut sejak awal.
• 7:51
  Pengguna gratis mencapai batasnya dan Gateway mengirimkan pesan sopan untuk mencoba lagi nanti.
• 7:57
  Layanan backend bahkan tidak tahu ada permintaan masuk.
• 7:59
  Mereka tetap berjalan lancar melayani pelanggan berbayar.
• 8:02
  Gateway juga menangani penyeimbangan beban.
• 8:04
  Jika Anda menjalankan beberapa instans dari layanan yang sama, Gateway menyebarkan permintaan ke sana.
• 8:09
  Instans 1 menerima permintaan, instans 2 menerima berikutnya, begitu seterusnya.
• 8:12
  Semuanya otomatis.
• 8:14
  Dan jika satu instans mati, Gateway mengarahkannya ke instans lain.
• 8:16
  Lain tidak akan bertahu.
• 8:18
  Mereka hanya menerima respons.
• 8:18
  Penyimbangan berbandingan pemeriksaan kesehatan menjaga semuanya perjalanan lain.
• 8:22
  Gateway melakukan ping ke setiap instans untuk memastikan kondisinya.
• 8:25
  Jika tidak, Gateway berhenti mengirimkan lalu lintas ke sana.
• 8:27
  Ini sangat penting untuk api dengan lalu lintas tinggi.
• 8:29
  Tanpa Gateway, lonjakan trafik akan langsung menghantam layanan Anda.
• 8:33
  Dengan Gateway, lonjakan tersebut akan tertahan di Gateway, diserap, disebarkan, dan melindungi layanan Anda agar tidak kewalahan.
• 8:40
  Oke, tapi bagaimana jika data tidak sesuai saat tiba?
• 8:47
  Terkadang data yang dikirim klien tidak sesuai dengan yang diharapkan backend Anda.
• 8:50
  Mungkin klien mengirim jason, tapi backend Anda hanya mengerti XML.
• 8:54
  Mungkin nama kolomnya tidak selaras.
• 8:55
  Klien memulakan nama depan, dan backend Anda mengharapkan nama depan.
• 8:59
  Ketidakcocokannya menyebabkan.
• 9:00
  Dengan cara lama, Anda harus memperbaiki setiap klien atau menulis ulang backend.
• 9:04
  Itu tidak dia.
• 9:05
  Gateway dapat mengubah data sebelum mencapai backend.
• 9:08
  Anggap saja sebagai penuh.
• 9:09
  Ia berada di tengah, dan dapat mengubah data saat masuk, saat keluar, atau keduanya.
• 9:12
  Itulah transformasi permintaan dan respons secara singkat.
• 9:15
  Izinkan saya memberikan contoh nyata.
• 9:17
  Katakanlah Anda memiliki sistem lama yang membutuhkan XML.
• 9:19
  Sistem itu sudah berjalan selama 15 tahun.
• 9:21
  Sistem itu bekerja di rumah.
• 9:22
  Tapi sekarang Anda sedang membangun aplikasi seluler baru, dan aplikasi seluler menggunakan JIS.
• 9:25
  Tanpa gateway, Anda harus menulis ulang sistem lama, atau memaksa aplikasi seluler mengirim XML.
• 9:30
  Dengan gateway, Anda tidak perlu melakukan geret.
• 9:31
  Aplikasi seluler mengirim JIS.
• 9:33
  Gateway mengubahnya menjadi XML.
• 9:34
  Sistem mendapatkan apa yang diharapkannya.
• 9:36
  Aplikasi seluler mendapatkan respons kembali dalam format JIS.
• 9:38
  Tidak ada yang perlu menulis ulang apapun.
• 9:40
  Itulah keindahannya.
• 9:41
  Gateway juga dapat menambah atau menghapus header, mengubah URL, atau menyamarkan data sensitif.
• 9:46
  Bayangkan sebuah respons berisi nomor kartu kredit.
• 9:48
  Anda tentu tidak ingin data itu kembali ke klien.
• 9:50
  Gateway dapat menghapusnya sebelum respons dikirim, atau menggantinya dengan versi yang disamarkan.
• 9:54
  Backend tidak perlu diubah sama sekali.
• 9:56
  Gateway melanganinya.
• 9:57
  Ini sangat berguna saat Anda memodernisasi sistem lama.
• 9:59
  Anda tidak perlu menulis ulang backend.
• 10:01
  Anda tidak perlu memaksa klien untuk berubah.
• 10:03
  Anda cukup mengubah gateway inside.
• 10:04
  Ini seperti penerjemah di konferensi internasional.
• 10:06
  Semua orang berbicara dalam bahasa mereka sendiri, tapi penerjemah memastikan semua orang saling mengerti.
• 10:10
  Gateway adalah penerjemah bagi perangkat lunaan.
• 10:12
  Jadi perutean, keamanan, throttling, transformasi itu cukup banyak.
• 10:15
  Namun itu bukan empat hal yang terpisah.
• 10:17
  Ijinkan saya menunjukkan bagaimana semuanya.
• 10:18
  Bagaimana semuanya terhubung.
• 10:20
  Begini, keempat tugas ini tidak terpisah.
• 10:23
  Semuanya bekerja bersama pada setiap permintaan.
• 10:25
  Setiap kali ada permintaan masuk.
• 10:26
  Gateway memeriksa autentikasi.
• 10:28
  Gateway memvalidasi batas kecepatan.
• 10:29
  Gateway merotakan kelayanan.
• 10:30
  Ini mengubah data jika diperlukan.
• 10:32
  Ini menerima respons kembali.
• 10:36
  Setiap langkah terjadi secara otomatis, berurutan, tanpa layanan perlu memikirkannya.
• 10:42
  Kekuatan sebenarnya bukan pada satu fitur saja.
• 10:44
  Kelainkan pada integrasinya.
• 10:46
  Anda bisa menambah kebijakan keamanan baru tanpa mengubah perutean.
• 10:49
  Layanan backend tanpa mengubah klien.
• 10:52
  Anda bisa memperbarui batas kecepatan tanpa perlu mendapatkan ulang.
• 10:54
  Setiap bagian itu independen, tetapi semuanya bekerja dalam alur yang sama.
• 10:58
  Dan karena semuanya melewati satu tempat, Anda mendapat visibilitas penuh atas apa yang terjadi.
• 11:01
  Log, metrik, analitik semua dari satu titik.
• 11:04
  Anda bisa melihat berapa banyak permintaan yang masuk, mana yang gagal, mana yang lambat, klien, mana yang menggunakan sumber daya paling banyak.
• 11:10
  Tanpa gateway, Anda harus mengumpulkan data itu dari setiap layanan secara terpisah.
• 11:14
  Dengan gateway semuanya ada di sana.
• 11:15
  Pelawasan besarnya.
• 11:16
  Gateway bukan sekadar router.
• 11:18
  Ini adalah pusat kendali untuk seluruh platform API Anda.
• 11:20
  Setiap permintaan, setiap respon, setiap error semuanya mengalir melalui satu tempat.
• 11:24
  Anda memiliki satu jendela tampilan untuk segala hal yang terjadi.
• 11:26
  Jadi bagaimana cara menggunakannya?
• 11:28
  Mari bicara tentang apa yang bisa Anda lakukan sekarang.
• 11:29
  Poin dekat nyata.
• 11:31
  Realis.
• 11:32
  Jika Anda memiliki satu atau dua layanan, Anda mungkin belum memerlukan API Gateway.
• 11:35
  Anda bisa melangani putaran sendiri mengelola autentikasi di tiap layanan.
• 11:38
  Yang tidak elegan tapi berfungsi.
• 11:40
  Namun saat Anda mencapai tiga layanan atau mengekspos API ke klien eksternal, kompleksitas akan bertambah cepat.
• 11:46
  Gateway akan terbayar dengan cepat.
• 11:47
  Badi apa langkah pertama terbaikan?
• 11:49
  Sentralisasikan autentikasi di gateway.
• 11:50
  Lakukan itu sebelumnya lain.
• 11:51
  Pilih satu layanan, pindahkan pemeriksaan autentikasinya ke gitu.
• 11:54
  Anda akan langsung melihat kode layanan Anda menjadi lebih bersih.
• 11:56
  Tidak ada lagi logika validasi token yang tersebar di mana-mana.
• 12:00
  Tidak perlu lagi bertanya apakah Anda menerapkannya dengan cara yang sama di tiap layanan.
• 12:03
  Gateway menanganiya sekali dan setiap layanan mendapatkan manfaatnya.
• 12:06
  Langkah berikutnya, pembatasan kecepatan.
• 12:08
  Bahkan batas sederhana melindungi backend Anda dari kelebihan baru.
• 12:11
  Mulai dengan sesuatu yang dasar seperti 100 permintaan per menit per klien.
• 12:14
  Itu menghentikan klien nakal yang bisa melumpuhkan layanan Anda.
• 12:16
  Yang bisa bicara.