Manajemen API Hybrid dan Multi-Cloud: Tantangan dan Pilihan

1. Multi-Cloud & Hybrid Cloud

Microservices telah menjadi metode arsitektur perangkat lunak yang populer di mana organisasi memecah produk mereka menjadi microservices individu berdasarkan pemahaman mereka tentang bisnis mereka sendiri dan menggunakan metode ilmiah seperti domain-driven design. Struktur organisasi juga disesuaikan untuk selaras dengan arsitektur microservice, mengikuti Hukum Conway, untuk mendukung pengembangan iteratif bisnis.

Di masa lalu, organisasi membangun pusat data mereka sendiri untuk mengimplementasikan produk mereka. Pusat data ini dapat berada di fasilitas yang disewa atau dibeli, dan organisasi bertanggung jawab untuk mengelola infrastruktur yang kompleks, seperti switch, server, penyimpanan, rak, dan perangkat keras lainnya. Mereka juga perlu menangani masalah yang disebabkan oleh pemadaman listrik, suhu rak yang tinggi, server yang crash, dll. Menangani masalah seperti ini seringkali membutuhkan banyak sumber daya manusia dan keuangan tanpa mencapai hasil yang baik. Akibatnya, SLA (service level agreement) dari produk organisasi sendiri seringkali gagal memenuhi janji kepada pelanggan, yang mengakibatkan kompensasi.

Dengan munculnya cloud, orang semakin terbiasa mengimplementasikan bisnis mereka di public cloud. Public cloud membantu pengguna mengabstraksi detail infrastruktur perangkat keras, memungkinkan insinyur untuk fokus pada pengimplementasian, pemeliharaan, dan pengembangan bisnis mereka. Namun, selain kenyamanan yang diberikan oleh cloud, kemunculan dan penggunaannya juga membawa masalah lain bagi pengguna:

• Lock-in: Ketika produk dari penyedia cloud terintegrasi secara mendalam ke dalam bisnis, memindahkan bisnis ke cloud lain atau meninggalkan cloud sama sekali menjadi cukup menantang. Ini sangat umum terjadi pada produk PaaS atau SaaS yang memiliki ikatan kuat dengan bisnis. Sayangnya, ini sering terjadi ketika bisnis berada dalam periode pertumbuhan cepat dan pengambil keputusan mengabaikan efek pengikatan dari penggunaan produk cloud.
• Masalah ketersediaan: Prinsip diversifikasi berlaku di sini, yang berarti kita tidak menaruh semua telur dalam satu keranjang. Selama fase scaling bisnis, organisasi sering memprioritaskan peluncuran produk dengan cepat dan merebut pangsa pasar, mengabaikan infrastruktur. Hal ini dapat mengakibatkan pemadaman listrik atau pemotongan kabel di suatu region cloud, yang berdampak negatif pada bisnis.

Akibatnya, orang semakin terbiasa menggunakan beberapa public cloud atau membangun private cloud selain menggunakan public cloud untuk menghindari masalah yang disebutkan di atas. Pendekatan ini biasa disebut sebagai "multi-cloud" dan "hybrid cloud."

"Multi-cloud" mengacu pada penggunaan beberapa public cloud secara bersamaan, mengimplementasikan bisnis secara mirror atau heterogen di cloud tersebut. Ini akan menggunakan layanan standar sebanyak mungkin (untuk menghindari vendor lock-in). Karena penggunaan multi-cloud, ketika satu cloud menjadi tidak tersedia, dampak pada bisnis dapat diminimalkan, dan dapat memastikan kelangsungan bisnis dengan memodifikasi resolusi DNS dan mengaktifkan cloud cadangan.

"Hybrid cloud" mengacu pada organisasi yang, selain menggunakan satu atau lebih public cloud, juga memiliki private cloud (atau pusat data) mereka sendiri. Dalam skenario ini, beberapa layanan dapat diimplementasikan di private cloud, sementara yang lain mungkin diimplementasikan di public cloud. Atau semua layanan diimplementasikan di cloud, dan private cloud bertanggung jawab untuk manajemen dan pemantauan. Bagaimanapun, fleksibilitas dan ketersediaan implementasi perangkat lunak sangat meningkat setelah mengadopsi model "multi-cloud" atau "hybrid cloud."

Namun, mengimplementasikan strategi "multi-cloud" dan "hybrid cloud" dapat membuat manajemen microservices berbasis cloud lebih kompleks. Salah satu tantangan umum adalah manajemen API, karena banyak microservices bergantung pada API untuk komunikasi. Oleh karena itu, ketika mengimplementasikan microservices, API mereka harus diekspos secara eksternal untuk memungkinkan koneksi dengan pihak eksternal dan menyediakan layanan.

2. Kebutuhan Manajemen API dalam Skenario Multi-Cloud & Hybrid Cloud

Seperti yang kita ketahui, API gateway yang baik sangat penting untuk mengelola API microservices. API gateway memungkinkan eksposur API microservices yang aman dan efisien. Namun, ketika mengimplementasikan strategi "multi-cloud" dan "hybrid cloud," kebutuhan akan API gateway melampaui fungsionalitas dasarnya. Secara khusus, pertimbangan seperti:

Apakah mendukung manajemen multi-cluster

Seperti yang disebutkan sebelumnya, ketika mengimplementasikan strategi "multi-cloud" atau "hybrid cloud," layanan yang diimplementasikan di setiap cloud atau pusat data pribadi mungkin sangat bervariasi. Akibatnya, pengguna mungkin perlu mengimplementasikan cluster API gateway terpisah di setiap cloud dengan konfigurasi, sertifikat, dan kunci API yang berbeda. Jika gateway yang dipilih tidak mendukung manajemen multi-cluster, hal ini dapat menyebabkan kesulitan besar dalam mengelola API, terutama selama periode ekspansi bisnis ketika jumlah dan skala cluster gateway meningkat.

Dalam kasus seperti ini, produk API gateway yang mendukung manajemen multi-cluster dapat secara signifikan mengurangi biaya manajemen bagi administrator.

1. Pengguna memiliki akses ke konsol terpadu untuk memilih cluster yang ingin mereka konfigurasi dan pantau. Mereka juga dapat membawa cluster gateway online atau offline, tergantung pada situasi implementasi bisnis saat ini.
2. Pengguna dapat melihat status berjalan dari semua cluster API gateway ini di konsol, termasuk QPS umum, latensi, penggunaan CPU dan memori cluster gateway, dll.

Apakah mendukung kolaborasi

Dengan perkembangan bisnis yang cepat, sejumlah kecil administrator API gateway mungkin membutuhkan bantuan untuk mengelola dan memelihara semua cluster API gateway sendiri. Sementara itu, banyak konfigurasi gateway, seperti menambahkan rute dan mengonfigurasi plugin, dapat ditangani oleh pengembang, mengurangi kebutuhan akan keterlibatan administrator yang luas. Oleh karena itu, apakah mendukung "kolaborasi" menjadi penting untuk manajemen.

Secara khusus, administrator dapat mengundang anggota lain dari organisasi untuk bergabung dalam manajemen cluster API gateway menggunakan RBAC (Role-based access control) atau strategi lain untuk menetapkan izin yang berbeda kepada anggota tim. Misalnya, menetapkan peran Organization Admin (dapat melakukan operasi apa pun) untuk administrator dan Service Admin (hanya dapat memelihara beberapa layanan dan rute) untuk pengembang umum. Pendekatan ini memastikan keamanan operasi sambil mengimplementasikan kolaborasi. Ini juga memfasilitasi pemulihan akun atau modifikasi izin yang tepat waktu dalam kasus pergantian karyawan atau perubahan posisi pekerjaan.

Apakah dapat berjalan di infrastruktur apa pun

Seiring dengan matangnya teknologi containerization dan container orchestration, banyak microservices berpindah dari mesin virtual ke berjalan di Kubernetes. Ini berarti pengguna mungkin menggunakan Kubernetes, mesin virtual tradisional, atau bahkan mesin fisik, seperti di pusat data pribadi mereka. Jika produk API gateway yang dipilih oleh pengguna kaya fitur dan memenuhi kebutuhan bisnis tetapi dibatasi oleh infrastruktur dasar atau kurangnya alat instalasi yang matang, hal ini dapat menciptakan tantangan bagi pengguna, baik untuk menyerah menggunakannya atau melakukan pengembangan tambahan untuk memungkinkan API gateway berjalan di infrastruktur tertentu. Bagaimanapun, ini akan mengakibatkan biaya penggunaan tambahan.

3. Keputusan

Seperti yang dibahas, menjadi sangat penting untuk memilih API gateway yang tepat dalam konteks skenario "multi-cloud" dan "hybrid cloud." Beberapa opsi umum tercantum, dan pengguna harus menganalisisnya berdasarkan skenario aktual dan rencana masa depan mereka.

Solusi berbeda di cloud yang berbeda

Biasanya, setiap penyedia public cloud menawarkan solusi API gateway bawaan mereka sendiri, dan pengguna dapat mempertimbangkan untuk membeli solusi API gateway untuk setiap cloud.

Keuntungannya termasuk:

1. Biaya penggunaan yang sangat rendah, tanpa perlu implementasi atau pemeliharaan.
2. Biasanya mendukung pay-as-you-go; penggunaan awal mungkin hanya memerlukan biaya minimal.

Kerugiannya termasuk:

1. Penggunaan API gateway di cloud yang berbeda seringkali tidak kompatibel satu sama lain, sehingga menyelesaikan konfigurasi yang sama memerlukan jalur yang berbeda.
2. Fitur produk tidak simetris di antara penyedia yang berbeda. Misalnya, satu penyedia mungkin mendukung mTLS sementara yang lain tidak.
3. Dalam skenario "hybrid cloud," memilih API gateway open-source atau komersial lain mungkin diperlukan dan mengimplementasikannya di private cloud pengguna.

Ketika menggunakan pendekatan ini, mencapai pengalaman pengguna yang konsisten di berbagai penyedia cloud mungkin memerlukan kustomisasi produk, pengembangan alat sinkronisasi konfigurasi, dan abstraksi detail dasar. Ini mungkin melibatkan penelitian, analisis, dan pengembangan tambahan dari pihak pengguna. Pengguna mungkin menghadapi masalah kompatibilitas dan fungsionalitas terbatas dan hanya dapat menggunakan beberapa fitur umum dari produk API gateway. Selain itu, kemungkinan kegagalan sinkronisasi juga harus diperhitungkan.

Tentu saja, pengguna juga dapat secara manual mengulang konfigurasi setiap API gateway di setiap cloud (jika mereka dapat mentolerirnya).

Solusi API gateway open-source

Sebagai alternatif untuk menggunakan solusi berbeda di cloud yang berbeda, pengguna dapat mempertimbangkan untuk menggunakan solusi API gateway open-source seperti Apache APISIX, Kong, Tyk, Traefik, dll. Pendekatan ini memungkinkan pengguna untuk menggunakan API gateway yang sama di semua cloud, termasuk pusat data pribadi, sehingga menghindari masalah kompatibilitas antara solusi yang berbeda. API gateway open-source yang matang dan kuat dapat membantu pengguna menyelesaikan banyak masalah dalam berbagai skenario. Bahkan jika mungkin tidak mencakup semua skenario, API gateway ini biasanya memungkinkan pengguna untuk memperluasnya dengan berbagai cara. Misalnya, Apache APISIX memungkinkan pengguna untuk memperluasnya menggunakan bahasa dan teknologi seperti Go, Java, Python, Lua, WASM, dll.

Namun, API gateway open-source ini biasanya mengadopsi strategi open-source Open Core, di mana fitur inti produk bersifat open-source, tetapi kemampuan manajemen tingkat perusahaan seperti konsol visualisasi, manajemen multi-cluster, auditing, SSO (Single Sign-On), dll., seringkali berbayar (terintegrasi ke dalam produk komersial mereka). Jika pengguna tidak ingin membayar, mereka hanya dapat memilih untuk mengembangkan platform manajemen mereka sendiri (juga dikenal sebagai control plane gateway) untuk mengelola API gateway ini, yang berarti pengguna perlu mempekerjakan insinyur penuh waktu untuk mengambil alih pekerjaan pengembangan ini.

Membeli layanan SaaS API gateway tingkat perusahaan

Jika API gateway open-source memenuhi persyaratan dalam hal fungsionalitas, tetapi biaya penelitian mandiri tidak dapat diterima, pengguna juga dapat mempertimbangkan untuk menghubungi produsen asli dari perangkat lunak open-source ini (seperti API7.ai di belakang Apache APISIX, Kong Inc di belakang Kong, dan Tyk Inc di belakang Tyk, dll.). Produsen ini sering menyediakan produk dan layanan dukungan API gateway tingkat perusahaan yang berbeda. Terutama dalam skenario "multi-cloud" dan "hybrid cloud," produsen ini telah merilis produk SaaS mereka. Produk SaaS dari API gateway sering fokus pada sisi manajemen, menyediakan konsol siap pakai tanpa perlu khawatir tentang di mana instance API gateway diimplementasikan (tentu saja, beberapa layanan SaaS juga mendukung hosting instance API gateway, tetapi ini sering juga memperkenalkan masalah lain, seperti latensi saat memproksi API).

Layanan SaaS biasanya menyediakan panel kontrol gateway pribadi untuk setiap tenant, menghubungkannya ke instance gateway yang diimplementasikan pengguna (atau dihosting SaaS) menggunakan strategi seperti mTLS untuk memastikan keamanan dan privasi data, dan menyediakan kemampuan manajemen. Meskipun membeli layanan SaaS mungkin memerlukan investasi, ini bisa lebih hemat biaya daripada mempekerjakan insinyur khusus untuk memelihara API gateway dan panel kontrolnya.

Tentu saja, membeli layanan SaaS memerlukan kehati-hatian. Oleh karena itu, sebelum mengonfirmasi pesanan, pengguna harus mengevaluasi layanan SaaS dari aspek berikut:

1. Apakah layanan SaaS ini dapat memenuhi kebutuhan penggunaan saat ini dan masa depan?
2. Apakah penyedia layanan SaaS profesional dan dapat dipercaya? Kasus penggunaan apa yang mereka miliki?
3. Apakah layanan SaaS ini mematuhi peraturan, mematuhi GDPR, dan memiliki laporan audit SOC2?
4. Apakah layanan SaaS ini memiliki ketentuan SLA yang jelas?
5. Bagaimana layanan SaaS ini dikenakan biaya? Dapatkah pengguna memperkirakan pengeluaran masa depan untuk satu tahun atau beberapa tahun?

Mengembangkan sepenuhnya sendiri

Jika solusi API gateway open-source tidak memenuhi kebutuhan aktual pengguna, pengguna dapat mempertimbangkan untuk mengembangkan produk API gateway eksklusif mereka sendiri, yang dapat memakan waktu dan sumber daya yang intensif, dan stabilitas gateway juga menjadi perhatian utama. Mengembangkan API gateway tidak sesulit mengimplementasikan database relasional atau browser, tetapi ini bukan sesuatu yang dapat dilakukan dalam semalam; oleh karena itu, pengembangan mandiri dapat dianggap sebagai "strategi terburuk." Akibatnya, ini sering dianggap sebagai pilihan terakhir.

4. Kesimpulan

Dalam lingkungan cloud-native, mengelola API dalam skenario "multi-cloud" dan "hybrid cloud" akan menjadi tantangan bagi setiap organisasi, bahkan sebelum mengadopsi strategi ini. Oleh karena itu, meskipun artikel ini menyajikan berbagai opsi, penting untuk diingat bahwa tidak ada solusi yang cocok untuk semua, dan pengguna harus memilih opsi yang paling sesuai dengan kebutuhan bisnis spesifik dan tujuan pengembangan mereka.

Untuk informasi lebih lanjut tentang API gateway, silakan kunjungi blog kami atau hubungi kami.