Laporan Benchmark Manajemen API

Laporan Benchmark Manajemen API

Laporan Benchmark Manajemen API

Tentang Teknologi Kerja

Antarmuka pemrograman aplikasi, atau API, sekarang menjadi metode di mana-mana dan standar komunikasi de facto di antara teknologi informasi modern. Ekosistem informasi dalam perusahaan besar dan organisasi kompleks adalah beragam aplikasi dan sistem, yang banyak di antaranya telah beralih ke API sebagai perekat untuk menyatukan artefak heterogen ini bersama-sama. API telah mulai menggantikan metode berbagi informasi yang lebih lama dan lebih rumit dengan titik akhir yang ringan. Ini memberi organisasi kemampuan untuk menyatukan sistem dan aplikasi yang berbeda. API dan layanan mikro juga memberi perusahaan peluang untuk membuat standar dan mengatur interoperabilitas aplikasi — baik yang baru maupun yang lama — yang menciptakan modularitas. Selain itu, ia memperluas ruang lingkup pertukaran data dengan dunia luar, khususnya teknologi seluler, perangkat pintar, dan Internet of Things, karena organisasi dapat dengan aman berbagi data dengan konsumen dan produsen informasi lokasi yang tidak tetap.

Karena popularitas dan proliferasi API dan layanan mikro, kebutuhan telah muncul untuk mengelola banyak layanan yang diandalkan perusahaan — baik internal maupun eksternal. API itu sendiri sangat bervariasi dalam protokol, metode, skema otorisasi / otentikasi, dan pola penggunaan. Selain itu, TI membutuhkan kontrol yang lebih besar atas API yang dihosting, seperti pembatasan tarif, kuota, penegakan kebijakan, dan identifikasi pengguna, untuk memastikan ketersediaan tinggi dan mencegah pelanggaran dan pelanggaran keamanan. API yang terbuka membuka pintu bagi banyak mitra yang dapat membuat dan memperluas platform inti tanpa tahu apa pun tentang teknologi yang mendasarinya.

Banyak organisasi telah beralih ke API dan kunci layanan Microsoft, stok, dan tong. Organisasi bergantung pada layanan ini untuk dikelola dengan baik, dengan kinerja dan ketersediaan tinggi. Untuk tujuan diskusi, kami akan mendefinisikan "kinerja tinggi" di sini sebagai perusahaan yang mengalami beban kerja lebih dari 1.000 transaksi per detik pada titik akhir API mereka. Untuk organisasi-organisasi ini, kebutuhan mereka akan kinerja sama dengan kebutuhan mereka akan manajemen karena mereka mengandalkan tingkat transaksi API ini untuk mengimbangi kecepatan bisnis mereka. Solusi manajemen API tidak boleh menjadi hambatan kinerja. Sebaliknya, banyak perusahaan mencari solusi untuk memuat saldo di seluruh titik akhir API yang berlebihan dan memungkinkan volume transaksi yang tinggi. Bayangkan sebuah lembaga keuangan dengan 1.000 transaksi terjadi per detik — ini berarti 86 juta panggilan API dalam 24 jam sehari! Dengan demikian, kinerja adalah faktor penting ketika memilih solusi manajemen API.

Laporan ini berfokus pada platform manajemen API yang digunakan di cloud. Cloud memungkinkan perusahaan untuk berdiferensiasi dan berinovasi dengan layanan mikro dengan cepat. Titik akhir API dapat dikloning dan diskalakan dalam hitungan menit. Cloud memungkinkan skalabilitas elastis dibandingkan dengan penyebaran di tempat, penyebaran server lebih cepat dan pengembangan aplikasi, dan penghitungan yang lebih murah. Untuk alasan ini dan lainnya, banyak perusahaan memanfaatkan cloud untuk mempertahankan atau mendapatkan momentum sebagai perusahaan.

Laporan ini meneliti hasil dari tolok ukur kinerja yang dilengkapi dengan dua solusi manajemen API populer: Kong dan Apigee — dua platform manajemen API siklus hidup penuh yang dibangun dengan potensi skala dan arsitektur untuk penyebaran skala besar dan kinerja tinggi. Terlepas dari kesamaan ini, ada beberapa perbedaan dalam kedua platform.

Kong

Kong dibuat oleh Mashape dan kemudian divestasi sehingga merilis platform API-nya. Kong tertarik untuk memberikan kinerja dengan infrastruktur yang ringan ketika platform didasarkan pada proksi yang ringan. Kong dikenal karena kemampuannya untuk menangani lebih dari 10.000 koneksi simultan ke beberapa titik akhir API dengan penggunaan memori minimal dan sambil memberikan latensi sangat rendah. Kong menjadi proyek open-source pada tahun 2015. Hari ini, ia digunakan oleh lebih dari 5.000 organisasi pada 400.000 instance yang sedang berjalan dan telah memiliki 54 juta unduhan GitHub.

Kong tersedia sebagai komponen perangkat lunak sumber terbuka (OSS) yang memiliki berbagai fungsi yang mengesankan, termasuk dukungan plugin sumber terbuka, penyeimbangan beban, dan penemuan layanan. Kong Enterprise (KE) — edisi yang diuji dalam benchmark ini — menampilkan fungsionalitas yang diperluas, seperti dasbor manajemen, portal pengembang yang dapat disesuaikan, plugin keamanan, metrik, dan dukungan 24x7. Dalam laporan ini, setiap penyebutan Kong harus diterapkan ke Perusahaan Kong juga.

Kong dan Kong Enterprise dapat digunakan baik di cloud atau di tempat. Bagi kami, pemasangan membutuhkan waktu kurang dari 10 menit dari awal pada contoh Amazon Web Services (AWS) EC2. Manajer paket berbasis Debian dan RedHat (Yum dan Apt-Get) memiliki Kong di repositori mereka; Opsi Docker dan CloudFormation juga tersedia.

Kong dapat beroperasi sebagai node tunggal atau dapat bergabung dengan orang lain untuk membentuk sebuah cluster. Dalam konfigurasi single-node, database PostgreSQL atau Cassandra dapat hidup dengan instance yang sama dengan Kong. Dalam konfigurasi cluster (seperti yang digambarkan di bawah), database berada pada instance terpisah. Scaling Kong secara horizontal sederhana. Kong tidak memiliki kewarganegaraan, sehingga menambahkan node ke cluster semudah menunjuk node baru ke database eksternal, sehingga dapat mengambil semua konfigurasi, keamanan, layanan, rute, dan informasi konsumen yang diperlukan untuk mulai memproses permintaan dan tanggapan API. Juga di lingkungan cluster, penyeimbang beban (seperti Nginx atau HAProxy) digunakan di tepi untuk memberikan alamat tunggal untuk klien dan untuk mendistribusikan permintaan di antara node Kong menggunakan strategi yang dipilih (mis., Round robin atau weighted).

Kong memiliki ekosistem plugin yang berkembang (disebut Kong Hub), tersedia sebagai bagian dari versi open source dan perusahaan, seperti otentikasi LDAP, CORS, Dynamic SSL, AWS Lambda, Syslog, dan lainnya. Berdasarkan Nginx, Kong memungkinkan pengguna untuk membuat plugin sendiri menggunakan LuaJIT.
Apigee

Apigee sudah ada sejak lama — bahkan sebelum munculnya wadah. Google mengakuisisi Apigee pada bulan September 2016 untuk memberikan vendor besar solusi manajemen API untuk bersaing dengan produk vendor cloud besar lainnya seperti Amazon API Gateway dan Microsoft's Azure API Management. Produk microservices utama Apigee disebut Edge, tetapi mereka memiliki penawaran produk yang lebih luas, seperti Sense untuk mendeteksi aktivitas penggunaan API yang mencurigakan. Sementara Apigee tersedia di tempat (penyebaran yang mereka sebut Private Cloud), mereka tidak menganjurkan penggunaannya demi keunggulan Perangkat Lunak sebagai Layanan (SaaS) di cloud publik. Bahkan, Apigee bahkan mendesak di situs webnya sendiri1 untuk "berpikir dua kali" tentang penyebaran di tempat, menyebutnya "gunung es pemeliharaan dan biaya." Ini mungkin pengaruh Google, lebih memilih Apigee untuk ditempatkan di Google Cloud.

Salah satu alasan mengapa sebuah perusahaan mungkin menghindar dari penyebaran di lokasi dengan Apigee adalah bahwa arsitekturnya lebih terlibat daripada penyebaran awan murni. Diagram di bawah ini menunjukkan sumber daya apa yang dibutuhkan dalam penyebaran di tempat. Karena Apigee dengan jelas merekomendasikan kepada pelanggan mereka tawaran cloud publik, kami mengujinya dengan lisensi tingkat bisnis — memungkinkan 300 juta panggilan API per hari, dan tidak ada pembatasan tarif atau pengurangan bandwidth.