Apa itu gateway federasi?

Dalam sistem terpusat, sebuah gateway tunggal (yang terhubung ke, dan bertanggung jawab untuk mengelola, beberapa API) menangani semua permintaan klien. Federasi Gateway, sementara itu, memungkinkan organisasi untuk menggunakan jaringan terdistribusi API Gateway, masing-masing bertanggung jawab atas rangkaian layanannya sendiri yang berbeda.

Dalam sistem federated gateway, tim dapat menambahkan layanan sesuai kebutuhan tanpa memengaruhi keseluruhan sistem, sehingga memungkinkan penggunaan sumber daya dan manajemen lalu lintas yang efisien. Departemen terpisah juga dapat menggunakan protokol yang berbeda untuk mengelola gateway masing-masing. Kerangka kerja ini memberikan keleluasaan bagi tim untuk mengelola API mereka sendiri, meningkatkan fleksibilitas, ketahanan operasional, dan banyak lagi.

Pendekatan ini juga membantu menghindari kemacetan lalu lintas dan masalah lain yang terkait dengan API gateway terpusat dan dapat memberikan manfaat kinerja dengan menerapkan fungsi gateway lebih dekat ke pengguna akhir. Strategi federasi gateway dapat diterapkan ke berbagai gaya dan protokol arsitektur API, termasuk REST, gPRC, dan SOAP, yang masing-masing menawarkan kelebihan dan kekurangan.

Dari perspektif TI, gateway gabungan bermanfaat karena memungkinkan tim DevOps untuk mengembangkan dan menerapkan API mereka sendiri sambil mempertahankan kepatuhan terhadap manajemen platform API, tata kelola, dan kebijakan keamanan di seluruh perusahaan. Tim dapat pindah cepat dan mandiri untuk menyelesaikan proyek di domain mereka (memfasilitasi inovasi dan mempercepat kecepatan ke pasar) sambil mempertahankan standar di seluruh organisasi, mencapai keseimbangan antara otonomi tim dan pengawasan terpusat.

Federasi GraphQL adalah konsep alternatif dan pendekatan arsitektur yang digunakan untuk membuat GraphQL API terpadu. Ini didasarkan pada GraphQL, bahasa kueri yang dapat secara akurat menargetkan sumber daya dari beberapa layanan dengan satu kueri API.

Federasi GraphQL menghubungkan berbagai layanan (dikenal sebagai subgraf)—masing-masing dengan skema sendiri yang mendefinisikan data yang dikelolanya—ke skema terpadu yang dikenal sebagai supergraf. Satu gateway mengekspos skema supergraph ini ke aplikasi klien, menyatukan beberapa layanan dan bidang yang mendasarinya, dan merutekan semua kueri API. Sebaliknya, federasi gateway menghubungkan beberapa API gateway melalui bidang kontrol pusat, dengan setiap API Gateway menurunkan kuerinya sendiri.

Federasi adalah pendekatan umum untuk manajemen sistem yang menghubungkan komponen otonom melalui bidang kontrol umum.

Dalam sistem gateway terpusat, semua permintaan klien mengalir melalui satu gateway, yang mengelola fungsi-fungsi seperti perutean, autentikasi, otorisasi, dan pemantauan. Tidak seperti arsitektur federasi, tanggung jawab ini tidak didistribusikan di beberapa instance.

Pendekatan ini dapat merampingkan pencatatan, manajemen lalu lintas, penegakan keamanan, dan tugas-tugas lainnya karena setiap proses ini mengalir melalui gateway. Organisasi juga bisa memulai peluncuran dari satu titik, sehingga tidak perlu melakukan pembaruan versi di beberapa gateway dan layanan.

Namun, perusahaan dengan kerangka kerja terpusat mungkin lebih mungkin menghadapi kemacetan, terutama saat mereka meningkatkan operasi mereka. Sebagai titik pass-through tunggal sistem, gateway dapat dengan mudah menjadi padat. Selain itu, ini menyajikan satu titik kegagalan; jika kesalahan terjadi, itu mempengaruhi seluruh sistem.

Tidak seperti sistem terpusat, arsitektur gateway federasi terdiri dari beberapa gateway, masing-masing bertanggung jawab atas serangkaian layanan yang berbeda dan API terkait. Gerbang-gerbang tersebut berfungsi secara independen, meskipun masing-masing dikelola oleh bidang kontrol pusat.

Dibandingkan dengan kerangka kerja terpusat, sistem federasi mendorong fleksibilitas dan otonomi dengan memberikan tim pengembang tingkat kontrol yang lebih besar atas domain mereka masing-masing. Tata letak terdesentralisasi ini juga membuat sistem federasi lebih tangguh terhadap pemadaman dan kegagalan sistem.

Namun, sistem federasi lebih kompleks secara operasional, sehingga berpotensi menimbulkan kesenjangan tata kelola dan miskomunikasi antar tim. Peluncuran bisa memakan waktu lebih lama, dan pemeliharaan bisa jadi lebih mahal, karena setiap gateway harus dikelola dan diperbarui secara terpisah.

Ada beberapa alasan mengapa perusahaan mungkin memilih sistem gateway federasi.

Pertama, federasi gateway biasanya digunakan dalam kasus merger dan akuisisi, di mana perusahaan mewarisi tumpukan yang berbeda dan sistem API management dari perusahaan yang mereka akuisisi. Alih-alih mengelola beberapa arsitektur terpisah secara individual, masing-masing dengan protokol keamanan, standar teknis, dan struktur tata kelola yang berbeda, atau mencoba menyesuaikan sistem yang diakuisisi dengan sistem perusahaan yang sudah ada, perusahaan beralih ke federasi gateway. Pendekatan ini memungkinkan organisasi untuk melipat API Gateway yang ada, dan sistem yang mendasarinya, ke dalam struktur di atasnya yang disediakan oleh bidang kontrol pusat.

Demikian pula, beberapa gateway sering digunakan di lingkungan dengan banyak layanan mikro yang dibangun oleh tim yang berbeda dan tersebar di berbagai pengaturan. Perusahaan juga dapat memilih sistem federasi untuk manfaat kinerja.

Misalnya, pertimbangkan perusahaan logistik dengan beberapa kantor di seluruh dunia, masing-masing melayani wilayah tertentu. Dengan menempatkan gateway, server, layanan, dan sumber daya lainnya lebih dekat dengan klien yang mengaksesnya, perusahaan dapat mengoptimalkan latensi dan faktor kinerja terkait.

Dalam federasi gateway, bidang kontrol pusat menangani manajemen, pemantauan, dan tata kelola tetapi umumnya tidak dapat diakses oleh klien. Konsumen API berinteraksi langsung dengan gateway yang membentuk sistem federasi (menanyakan titik akhir yang bertanggung jawab untuk layanan yang relevan) tetapi tidak menanyakan bidang kontrol itu sendiri. Pesawat menerima metadata dan log hanya setelah panggilan API telah terjadi.

Meskipun pendekatan ini dapat memperkenalkan beberapa kompleksitas operasional, pendekatan ini juga mempromosikan independensi. Sebagai contoh, ini membantu memungkinkan tim platform untuk mengonfigurasi gateway dan layanan mereka sendiri untuk memenuhi kebutuhan spesifik mereka, memilih protokol mereka sendiri dan menerapkan peluncuran sendiri. Arsitektur federasi juga lebih tangguh terhadap kesalahan konfigurasi dan pelanggaran keamanan karena kesalahan diisolasi ke gateway tempat asalnya dan tidak mungkin menyebar ke gateway lain di jaringan.

Sementara itu, dalam federasi GraphQL, skema dari beberapa layanan independen (subgraf) digabungkan menjadi satu skema supergraf terpadu. Gateway tunggal, atau router, menyajikan satu titik masuk untuk kueri klien, memberikan pengalaman API terpadu.  

Router secara cerdas membagi kueri menjadi sub-permintaan yang lebih kecil, mengambil informasi yang relevan dari beberapa subgraf dan menyusunnya menjadi respons yang kohesif untuk klien.

Bayangkan platform perawatan kesehatan dengan layanan terpisah untuk:

• Pasien: Mengelola detail pasien, informasi kontak, dan riwayat medis
  
  
• Janji Temu: Penjadwalan dan pelacakan kunjungan mendatang
  
  
• Penagihan: Menangani faktur dan pemberitahuan penagihan

Alih-alih meminta masing-masing titik akhir ini dengan panggilan API terpisah, federasi GraphQL menyajikan antarmuka terpadu yang memungkinkan klien - dalam hal ini, aplikasi atau dasbor yang melayani dokter atau pasien - untuk mengakses riwayat medis pasien, mengidentifikasi janji temu berikutnya, dan menentukan saldo terutangnya dengan satu panggilan API, daripada melalui tiga permintaan terpisah.

Federasi GraphQL menyediakan cara untuk membangun API GraphQL yang dapat diskalakan di lingkungan terdistribusi. Kerangka kerja ini memungkinkan pengembangan dan penerapan layanan secara independen sambil menyediakan frontend terpadu untuk permintaan klien. Namun, federasi GraphQL rentan terhadap tantangan biaya dan kompleksitas, kerentanan keamanan, kemacetan, dan redundansi.

Diperkenalkan pada tahun 2019, federasi Apollo adalah salah satu implementasi federasi GraphQL yang menggunakan arahan khusus (seperti @key atau @extends) dalam bahasa definisi skema GraphQL untuk mendefinisikan hubungan antara berbagai jenis di seluruh subgraf.

Meskipun Apollo adalah solusi umum, itu bukan satu-satunya opsi federasi GraphQL yang tersedia. Alternatif yang umum termasuk Hive, Mesh, Indigo dan WunderGraph Cosmo, yang masing-masing menawarkan berbagai tingkat penyesuaian. 

Meskipun kurang dari 5% perusahaan telah menggabungkan sistem GraphQL pada tahun 2024, angka tersebut diperkirakan akan mencapai 30% pada tahun 2027, menurut perusahaan riset Gartner. Penyedia cloud utama seperti Amazon Web Services (AWS) dan Microsoft Azure, serta repositori kode seperti GitHub, juga mendukung GraphQL API dengan alat pengamatan dan validasi bawaan.

Federasi GraphQL memiliki beberapa keunggulan berbeda, terutama dalam kemampuannya untuk merampingkan akses API untuk klien. Tim dapat mempertahankan tingkat kemandirian tertentu dengan menerapkan, mengelola, dan menskalakan subgraf mereka sendiri.

Tetapi sebagai kerangka kerja terpusat, federasi GraphQL lebih rentan terhadap penyimpangan keamanan, masalah kemacetan, dan inefisiensi kinerja. Ini juga terikat pada skema GraphQL, sedangkan federasi API gateway kompatibel dengan beberapa protokol.

Dalam mengembangkan strategi API, organisasi memutuskan apakah akan mengadopsi kerangka kerja GraphQL API atau menggunakan gaya arsitektur lain, seperti REST, untuk API mereka.

Pada akhirnya, organisasi dapat memilih untuk menggabungkan federasi GraphQL dan gaya arsitektur lainnya ke dalam sistem mereka, dengan masing-masing bertanggung jawab untuk menangani fungsi yang berbeda. Dalam satu konfigurasi umum, suatu perusahaan menggunakan GraphQL secara internal (dengan batasan ketat untuk mengurangi masalah keamanan, biaya atau kompleksitas) dan menggunakan gaya arsitektur yang berbeda seperti REST (yang dapat memberikan tingkat kontrol yang lebih dalam dan adopsi yang lebih mudah) untuk API eksternal. Dalam skenario ini, API gateway federasi juga dapat digunakan untuk menyatukan gaya arsitektur yang berbeda ini melalui bidang kontrol pusat.

Dalam konfigurasi API gateway standar, satu gateway menangani semua lalu lintas pengguna, perutean, dan analitik. Meskipun pendekatan ini membantu merampingkan pengaturan yang lebih sederhana, pendekatan ini dapat dengan cepat menyebabkan kemacetan di lingkungan yang lebih kompleks.

Gateway federasi tidak hanya mengandalkan satu API gateway tetapi juga array dari mereka. Setiap gateway digunakan untuk mengelola panggilan API ke serangkaian layanan tertentu, dan gateway terhubung ke bidang kontrol, yang menangani manajemen dan tata kelola.

Sementara itu, jaring layanan dianggap konfigurasi timur-barat karena mengelola koneksi antara layanan mikro tetapi tidak berinteraksi dengan pengguna itu sendiri. Jaring layanan terutama memfasilitasi komunikasi dan pengamatan dalam satu lingkungan atau klaster. Namun, varian yang dikenal sebagai hybrid cloud mesh dioptimalkan untuk melakukan fungsi seperti enkripsi, penyeimbangan beban, dan autentikasi di beberapa klaster dan lingkungan (termasuk multicloud, hybrid cloud, dan lingkungan lokal). 

Organisasi dapat menggunakan berbagai strategi untuk memanfaatkan arsitektur terdistribusi gateway federasi sambil mengurangi beberapa kompleksitas operasional dan biaya pemeliharaan yang terkait dengan sistem federasi. Praktik-praktik ini membantu menjaga otonomi tim sambil mempertahankan jalur komunikasi yang terbuka dan pengawasan terpadu di antara tim.

Perusahaan harus membuat perbedaan yang jelas di antara tim, menghilangkan ambiguitas di sekitar layanan mana yang ditugaskan untuk membangun dan memelihara. Praktik ini mendorong akuntabilitas dan melindungi tim agar tidak menduplikasi atau salah mengkonfigurasi pekerjaan rekan kerja secara tidak sengaja. Selain itu, pendekatan ini dapat meningkatkan produktivitas karena tim memiliki pemahaman yang kuat tentang tujuan dan tanggung jawab mereka (dan kebebasan untuk menindaklanjutinya).

Penerapan protokol dan standar keamanan dan kepatuhan yang tidak konsisten di seluruh gateway dan API dapat menimbulkan risiko keamanan, hukum, dan reputasi. Mempertahankan standar untuk pencatatan, enkripsi, autentikasi, dan implementasi keamanan lainnya di seluruh gateway harus menjadi prioritas dalam sistem terdistribusi. Dengan demikian, hal ini membantu memastikan bahwa bidang manajemen pusat dapat digunakan untuk merespons laporan insiden secara efisien, melakukan audit yang komprehensif, dan mencegah serangan di masa depan, tidak peduli dari domain mana ancaman berasal.

Kesenjangan observabilitas dalam sistem terdistribusi dapat menyebabkan risiko keamanan dan masalah kinerja. Sangat penting bahwa bidang manajemen pusat memberikan visibilitas komprehensif yang diperlukan bagi tim untuk melihat kesehatan dan kinerja sistem. Kemampuan ini membantu memungkinkan remediasi cepat ketika masalah muncul, serta kemampuan untuk melakukan peningkatan proaktif berdasarkan metrik keamanan dan kinerja.

Portal pengembang terpadu bertindak sebagai hub terpusat di mana pengembang dapat mengakses dan mempelajari API apa pun dalam sistem, di mana pun API tersebut dihosting atau bagaimana strukturnya. Mereka sangat penting dalam sistem federasi karena mereka memberikan panduan, dokumentasi, dan sampel pengodean untuk memberi tim DevOps kerangka kerja yang jelas tentang bagaimana API mereka harus dibangun, diterapkan, dan dipelihara.

Standar universal ini, bersama dengan kunci API dan kontrol akses lainnya, membantu memastikan bahwa pengembang dapat dengan lancar menambahkan API ke sistem dan mengelola gateway mereka sendiri sambil menjaga keamanan dan konsistensi.

Karena setiap tim bertindak dengan tingkat otonomi tertentu, jalur komunikasi yang terbuka sangat penting untuk berbagi praktik terbaik dan mempertahankan jaringan yang berkelanjutan. Dasbor dan alat kolaborasi lainnya dapat membantu tim melakukan sinkronisasi di sekitar tujuan dan prosedur bersama, terutama ketika perubahan dalam satu domain dapat memengaruhi layanan terkait.

Mekanisme pelaporan yang komprehensif memungkinkan tim DevOps untuk mendeteksi dan mengatasi latensi, gangguan layanan, dan anomali lainnya dengan cepat, berkontribusi pada pengalaman pengguna yang lebih mulus. Metrik kinerja juga dapat meningkatkan efisiensi skala dengan mengidentifikasi bagian mana dari sistem yang mencapai kapasitas dan mana yang berkinerja buruk.

Pendekatan DevOps modern, seperti infrastruktur sebagai kode (menggunakan kode untuk mengotomatiskan proses TI yang seharusnya memerlukan pengawasan dan penyediaan manual) dan AIOps (menggunakan AI untuk merampingkan operasi TI) dapat membantu gateway federasi beroperasi lebih efisien. Teknik otomatisasi juga berkontribusi pada jaringan yang lebih tangguh karena mereka mengurangi kemungkinan kesalahan manusia dan memberikan bandwidth tim TI untuk fokus pada masalah yang lebih kompleks.

Federasi gateway menggabungkan fleksibilitas dan kustomisasi arsitektur terdesentralisasi dengan struktur tata kelola terpusat dan dapat menawarkan beberapa keunggulan dibandingkan arsitektur tradisional.

Federasi memberi tim kontrol atas gateway mereka sendiri, memungkinkan mereka menyesuaikan konfigurasi waktu proses, mengelola pembaruan, dan menyesuaikan lingkungan pengodean agar sesuai dengan kebutuhan klien dan layanan mereka. Misalnya, untuk menyesuaikan batas tarif API dalam sistem terpusat, tim perlu mengirim permintaan melalui gerbang tunggal organisasi. Sistem federasi memungkinkan tim untuk melakukan penyesuaian secara mandiri dan secara real-time, tanpa memengaruhi gateway lain dalam jaringan.

Bidang pusat membantu memastikan bahwa beberapa gateway, meskipun memiliki konfigurasi masing-masing, mematuhi standar kompatibilitas dan keamanan bersama. Tim memiliki fleksibilitas untuk menyesuaikan parameter secara mandiri sambil mendapat manfaat dari pengawasan eksternal yang disediakan oleh bidang kontrol.

Pendekatan federasi mengakui bahwa tim pengembangan sering kali memiliki ide terbaik tentang cara meningkatkan dan memelihara domain mereka sendiri. Tim diberi otonomi untuk menyesuaikan API atau layanan mereka segera setelah mereka melihat ada masalah yang muncul, sehingga meningkatkan kemampuan beradaptasi dan ketangkasan. 

Tim bahkan dapat bekerja di berbagai bahasa pengodean yang berbeda sambil mempertahankan hubungan layanan mereka dengan pusat kendali. Akhirnya, departemen dapat meluncurkan pembaruan sesuai kebutuhan alih-alih mengandalkan otoritas pusat untuk menyetujui perubahan, meningkatkan waktu ke pasar untuk fitur baru, dan merampingkan alur kerja.

Sistem federasi dapat menawarkan penyediaan sumber daya yang lebih efisien dengan memungkinkan tim memantau kinerja mereka sendiri dan menyesuaikan batas tarif dan distribusi lalu lintas yang sesuai. Organisasi hanya dapat meningkatkan layanan dan fungsi yang membutuhkan kapasitas ekstra, menyalurkan sumber daya dari layanan atau wilayah yang kurang digunakan ke mereka yang mengalami permintaan yang lebih tinggi.

Selain itu, karena API gateway bersifat independen, maka lebih sulit bagi kerentanan untuk melompat dari satu API Gateway ke API Gateway lainnya. Akibatnya, sistem federasi umumnya lebih tahan terhadap serangan dan pemadaman karena kegagalan cenderung mempengaruhi hanya satu gateway, bukan seluruh sistem.

Dalam sistem federasi, tim DevOps individu mengambil alih operasi dan pemeliharaan gateway mereka sendiri. Dengan tanggung jawab yang lebih sedikit, tim pusat dapat fokus pada isu-isu yang lebih tinggi, seperti menegakkan peraturan kepatuhan, memfasilitasi komunikasi silang antar tim, dan menyempurnakan arsitektur sistem.

Silo data jauh lebih kecil kemungkinannya karena gateway federasi dapat menganalisis kinerja dan menerapkan pagar pembatas di seluruh domain. Metrik lintas gateway dapat memberikan pandangan yang lebih menyeluruh tentang bagaimana layanan tertentu berdampak pada produk dan layanan terkait.

Kepemilikan dan fleksibilitas yang terdesentralisasi dapat menimbulkan beberapa tantangan, terutama ketika terjadi gangguan dalam tata kelola atau pengamatan. Tantangan yang diperkenalkan oleh gateway federasi meliputi:

Meskipun otonomi tim dapat membantu mendorong inovasi, hal ini juga menambah kompleksitas arsitektur pada sistem, sehingga meningkatkan biaya infrastruktur dan komputasi. Sistem federasi juga cenderung membutuhkan lebih banyak sumber daya pemeliharaan dan keamanan karena strukturnya yang terdesentralisasi.

Karena metrik dan log didistribusikan di beberapa API gateway, mungkin lebih sulit bagi organisasi untuk membangun gambaran yang kohesif tentang kinerja secara keseluruhan. Sumber data dapat terfragmentasi dan terputus dari jaringan yang lebih luas, sehingga lebih sulit untuk mengidentifikasi dan mengatasi potensi miskonfigurasi. Organisasi dapat mengatasi tantangan ini dengan protokol dan prinsip standarisasi yang kuat, dan dengan alat bantu pengamatan.

Meskipun masing-masing tim bisa melakukan pembaruan sesuai kebijaksanaan mereka sendiri, peluncuran di seluruh perusahaan mungkin membutuhkan waktu lebih lama daripada di lingkungan terpusat. Alih-alih memperbarui satu basis kode pusat, gateway federasi harus mendistribusikan pembaruan di beberapa domain, dengan masing-masing tim bertanggung jawab untuk menyetujui dan mengintegrasikan perubahan tersebut secara mandiri.

Mempertahankan konfigurasi dan kebijakan yang konsisten di seluruh gateway terdistribusi dapat menghadirkan tantangan. Jika tim mengadopsi protokol, jadwal peluncuran, dan format data yang menyimpang dari standar tata kelola perusahaan, maka akan timbul ketidakcocokan dan kerentanan keamanan. Sebaliknya, jika standar dan kebijakan tata kelola menjadi terlalu ketat, perusahaan berisiko menghambat eksperimen dan memperlambat laju inovasi. Dalam sistem federasi, keseimbangan sangat penting.

Ketika perusahaan tumbuh dan berkembang di bawah sistem federasi, mereka berisiko menimbulkan inefisiensi baru, seperti penyebaran API, ketika beberapa tim secara tidak sengaja mengembangkan API yang berlebihan. Jika masalah ini meningkat, gateway bisa menjadi tidak terkendali, dengan bidang pusat tidak dapat melacak perubahan. Masalah ini dapat diatasi melalui tata kelola yang efisien.