Peluang dan Tantangan Evolusi Teknologi dalam Cloud Native

Saat ini, Cloud Native semakin populer, dan CNCF mendefinisikan Cloud Native sebagai:

• Berdasarkan lingkungan modern dan dinamis, alias lingkungan cloud.
• Dengan teknologi dasar berupa containerisasi, termasuk Service Mesh, infrastruktur yang tidak dapat diubah, API deklaratif, dll.
• Fitur utama meliputi penskalaan otomatis, kemampuan manajemen, observabilitas, otomatisasi, perubahan yang sering, dll.

Menurut survei CNCF 2021, ada jumlah yang sangat signifikan (lebih dari 62.000) kontributor di komunitas Kubernetes. Dengan tren teknologi saat ini, semakin banyak perusahaan yang menginvestasikan lebih banyak biaya ke dalam Cloud Native dan bergabung lebih awal untuk penerapan cloud yang aktif. Mengapa perusahaan-perusahaan ini mengadopsi Cloud Native dalam pengembangan, dan apa arti Cloud Native bagi mereka?

Keunggulan Teknis Cloud Native

Popularitas Cloud Native berasal dari keunggulannya di tingkat teknis. Ada dua aspek utama teknologi Cloud Native, termasuk containerisasi yang dipimpin oleh Docker, dan orkestrasi kontainer yang dipimpin oleh Kubernetes.

Docker memperkenalkan container image ke dunia teknologi, menjadikan container image sebagai unit pengiriman yang terstandarisasi. Sebenarnya, sebelum Docker, teknologi containerisasi sudah ada. Mari kita bicara tentang teknologi yang lebih baru, LXC (Linux Containers) pada tahun 2008. Dibandingkan dengan Docker, LXC kurang populer karena Docker menyediakan container image, yang dapat lebih terstandarisasi dan lebih mudah untuk bermigrasi. Selain itu, Docker menciptakan layanan publik DockerHub, yang telah menjadi repositori container image terbesar di dunia. Selain itu, teknologi containerisasi juga dapat mencapai tingkat isolasi sumber daya tertentu, termasuk tidak hanya isolasi CPU, memori, dan sumber daya lainnya, tetapi juga isolasi stack jaringan, yang memudahkan untuk menyebarkan beberapa salinan aplikasi pada mesin yang sama.

Kubernetes menjadi populer karena booming-nya Docker. Teknologi orkestrasi kontainer, yang dipimpin oleh Kubernetes, menyediakan beberapa kemampuan penting, seperti penyembuhan diri dari kesalahan, penjadwalan sumber daya, dan orkestrasi layanan. Kubernetes memiliki mekanisme penemuan layanan berbasis DNS yang terintegrasi, dan berkat arsitektur penjadwalannya, dapat diskalakan dengan sangat cepat untuk mencapai orkestrasi layanan.

Sekarang semakin banyak perusahaan yang secara aktif mengadopsi Kubernetes dan mengubah aplikasi mereka untuk memulai penyebaran Kubernetes. Dan Cloud Native yang kita bicarakan sebenarnya didasarkan pada prasyarat Kubernetes, yang merupakan landasan teknologi Cloud Native.

Keunggulan Containerisasi

1. Pengiriman yang Terstandarisasi

Container image sekarang telah menjadi unit pengiriman yang terstandarisasi. Dengan teknologi containerisasi, pengguna dapat langsung menyelesaikan pengiriman melalui container image alih-alih biner atau kode sumber. Dengan mengandalkan mekanisme pengemasan container image, Anda dapat menggunakan image yang sama untuk memulai layanan dan menghasilkan perilaku yang sama di runtime kontainer mana pun.

2. Portabel dan Ringan, Menghemat Biaya

Teknologi containerisasi mencapai isolasi tertentu melalui kemampuan kernel Linux, yang pada gilirannya memudahkan migrasi. Selain itu, teknologi containerisasi dapat langsung menjalankan aplikasi, yang lebih ringan dalam implementasi teknis dibandingkan dengan teknologi virtualisasi, tanpa memerlukan OS di mesin virtual.

Semua aplikasi dapat berbagi kernel, yang menghemat biaya. Dan semakin besar aplikasi, semakin besar penghematan biayanya.

3. Kemudahan Manajemen Sumber Daya

Saat memulai kontainer, Anda dapat mengatur properti CPU, memori, atau disk IO yang dapat digunakan untuk layanan kontainer, yang memungkinkan perencanaan dan penyebaran sumber daya yang lebih baik saat memulai instance aplikasi melalui kontainer.

Keunggulan Orkestrasi Kontainer

1. Menyederhanakan Alur Kerja

Di Kubernetes, penyebaran aplikasi lebih mudah dikelola daripada di Docker, karena Kubernetes menggunakan konfigurasi deklaratif. Misalnya, pengguna dapat dengan mudah mendeklarasikan dalam file konfigurasi image kontainer apa yang akan digunakan aplikasi dan port layanan apa yang diekspos tanpa perlu manajemen tambahan. Operasi yang sesuai dengan konfigurasi deklaratif sangat menyederhanakan alur kerja.

2. Meningkatkan Efisiensi dan Menghemat Biaya

Fitur lain yang menguntungkan dari Kubernetes adalah failover. Ketika sebuah node di Kubernetes mengalami crash, Kubernetes secara otomatis menjadwalkan aplikasi di dalamnya ke node normal lainnya dan membuatnya berjalan. Seluruh proses pemulihan tidak memerlukan intervensi dan operasi manusia, sehingga tidak hanya meningkatkan efisiensi operasional di tingkat operasional tetapi juga menghemat waktu dan biaya.

Dengan munculnya Docker dan Kubernetes, Anda akan melihat bahwa kemunculan mereka telah membawa inovasi dan peluang besar dalam pengiriman aplikasi. Container image, sebagai unit pengiriman standar, memperpendek proses pengiriman dan memudahkan integrasi dengan sistem CI/CD.

Mengingat pengiriman aplikasi menjadi lebih cepat, bagaimana arsitektur aplikasi mengikuti tren Cloud Native?

Evolusi Arsitektur Aplikasi: dari Monolitik, Mikroservis ke Service Mesh

Titik awal evolusi arsitektur aplikasi masih berasal dari arsitektur monolitik. Seiring dengan peningkatan ukuran dan kebutuhan aplikasi, arsitektur monolitik tidak lagi memenuhi kebutuhan pengembangan tim kolaboratif, sehingga arsitektur terdistribusi secara bertahap diperkenalkan.

Di antara arsitektur terdistribusi, yang paling populer adalah arsitektur mikroservis. Arsitektur mikroservis dapat memisahkan layanan menjadi beberapa modul, yang saling berkomunikasi, menyelesaikan pendaftaran dan penemuan layanan, dan mencapai kemampuan umum seperti pembatasan aliran dan pemutusan sirkuit.

Selain itu, ada berbagai pola yang termasuk dalam arsitektur mikroservis. Misalnya, pola database per-layanan, yang mewakili setiap mikroservis dengan database individual, adalah pola yang menghindari dampak tingkat database pada aplikasi tetapi dapat memperkenalkan lebih banyak instance database.

Yang lainnya adalah pola API Gateway, yang menerima lalu lintas masuk kluster atau seluruh arsitektur mikroservis melalui gateway dan menyelesaikan distribusi lalu lintas melalui API. Ini adalah salah satu pola yang paling banyak digunakan, dan produk gateway seperti Spring Cloud Gateway atau Apache APISIX dapat diterapkan.

Arsitektur populer secara bertahap meluas ke arsitektur Cloud Native. Bisakah arsitektur mikroservis di bawah Cloud Native hanya membangun mikroservis asli sebagai container image dan memigrasikannya langsung ke Kubernetes?

Secara teori, tampaknya mungkin, tetapi dalam praktiknya ada beberapa tantangan. Dalam arsitektur mikroservis Cloud Native, komponen-komponen ini perlu berjalan tidak hanya dalam kontainer, tetapi juga mencakup aspek lain seperti pendaftaran layanan, penemuan, dan konfigurasi.

Proses migrasi juga melibatkan transformasi dan adaptasi tingkat bisnis, memerlukan migrasi logika umum seperti autentikasi, otorisasi, dan kemampuan terkait observabilitas (logging, monitoring, dll.) ke K8s. Oleh karena itu, migrasi dari penyebaran mesin fisik asli ke platform K8s jauh lebih kompleks daripada yang terlihat.

Dalam hal ini, kita dapat menggunakan model Sidecar untuk mengabstraksi dan menyederhanakan skenario di atas.

Biasanya, model Sidecar hadir dalam bentuk Sidecar Proxy, yang berevolusi dari sisi kiri diagram di bawah ini ke sisi kanan dengan menenggelamkan beberapa kemampuan generik (seperti autentikasi, otorisasi, keamanan, dll.) ke dalam Sidecar. Seperti yang dapat Anda lihat dari diagram, model ini telah beradaptasi dari memerlukan beberapa komponen yang harus dipelihara menjadi hanya memerlukan dua hal (aplikasi + Sidecar) yang harus dipelihara. Pada saat yang sama, model Sidecar sendiri mengandung beberapa komponen umum, sehingga tidak perlu dipelihara oleh pihak bisnis sendiri, sehingga dengan mudah menyelesaikan masalah komunikasi mikroservis.

Untuk menghindari skenario kompleks dari konfigurasi terpisah dan pembuatan roda berulang saat memperkenalkan Sidecar untuk setiap mikroservis, proses ini dapat diimplementasikan dengan memperkenalkan control plane atau melalui injeksi control plane, yang secara bertahap membentuk Service Mesh saat ini.

Service Mesh biasanya memerlukan dua komponen, yaitu control plane + data plane. Control plane menyelesaikan distribusi konfigurasi dan eksekusi logika terkait, seperti Istio, yang saat ini paling populer. Di data plane, Anda dapat memilih API gateway seperti Apache APISIX untuk penerusan lalu lintas dan komunikasi layanan. Berkat kinerja tinggi dan skalabilitas APISIX, juga memungkinkan untuk melakukan beberapa kebutuhan kustomisasi dan logika kustom. Berikut ini menunjukkan arsitektur solusi Service Mesh dengan Istio+APISIX.

Keunggulan solusi ini adalah ketika Anda ingin bermigrasi dari arsitektur mikroservis sebelumnya ke arsitektur Cloud Native, Anda dapat menghindari perubahan besar di sisi bisnis dengan menggunakan solusi Service Mesh secara langsung.

Tantangan Teknis Cloud Native

Artikel sebelumnya menyebutkan beberapa keunggulan tren Cloud Native saat ini dalam hal teknis. Namun, setiap koin memiliki dua sisi. Meskipun beberapa elemen segar dan peluang dapat dibawa, tantangan akan muncul karena partisipasi teknologi tertentu.

Masalah yang Disebabkan oleh Containerisasi dan K8s

Di bagian awal artikel, kami menyebutkan bahwa teknologi containerisasi menggunakan kernel bersama, dan kernel bersama membawa ringan tetapi menciptakan kurangnya isolasi. Jika terjadi pelarian kontainer, host yang sesuai mungkin diserang. Oleh karena itu, untuk memenuhi tantangan keamanan ini, teknologi seperti secure container telah diperkenalkan.

Selain itu, meskipun container image menyediakan metode pengiriman yang terstandarisasi, mereka rentan terhadap serangan, seperti serangan rantai pasok.

Demikian pula, pengenalan K8s juga membawa tantangan dalam keamanan komponen. Peningkatan komponen menyebabkan peningkatan permukaan serangan, serta kerentanan tambahan terkait komponen dasar dan tingkat dependensi. Di tingkat infrastruktur, migrasi dari mesin fisik atau virtual tradisional ke K8s melibatkan biaya transformasi infrastruktur dan lebih banyak biaya tenaga kerja untuk melakukan pencadangan data kluster, peningkatan berkala, dan pembaruan sertifikat.

Juga, dalam arsitektur Kubernetes, apiserver adalah komponen inti dari kluster dan perlu menangani semua lalu lintas dalam dan luar. Oleh karena itu, untuk menghindari masalah keamanan perbatasan, bagaimana melindungi apiserver juga menjadi pertanyaan kunci. Misalnya, kita dapat menggunakan Apache APISIX untuk melindunginya.

Keamanan

Penggunaan teknologi baru memerlukan perhatian tambahan di tingkat keamanan:

• Di tingkat keamanan jaringan, kontrol lalu lintas yang lebih halus dapat diimplementasikan melalui Network Policy, atau metode enkripsi koneksi lain seperti mTLS untuk membentuk jaringan zero-trust.

• Di tingkat keamanan data, K8s menyediakan sumber daya secret untuk menangani data rahasia, tetapi sebenarnya tidak aman. Isi sumber daya secret dikodekan dalam Base64, yang berarti Anda dapat mengakses isinya melalui decoding Base64, terutama jika ditempatkan di etcd, yang dapat dibaca langsung jika Anda memiliki akses ke etcd.

• Di tingkat keamanan izin, ada juga situasi di mana pengaturan RBAC tidak masuk akal, yang menyebabkan penyerang menggunakan Token yang relevan untuk berkomunikasi dengan apiserver untuk mencapai tujuan serangan. Pengaturan izin semacam ini sebagian besar terlihat dalam skenario controller dan operator.

Observabilitas

Sebagian besar skenario Cloud Native melibatkan beberapa operasi terkait observabilitas seperti logging, monitoring, dll.

Di K8s, jika Anda ingin mengumpulkan log dengan berbagai cara, Anda perlu mengumpulkannya langsung di setiap node K8s melalui agregasi. Jika log dikumpulkan dengan cara ini, aplikasi perlu diekspor ke output standar atau kesalahan standar.

Namun, jika bisnis tidak membuat perubahan yang relevan dan masih memilih untuk menulis semua log aplikasi ke file dalam kontainer, itu berarti Sidecar diperlukan untuk pengumpulan log di setiap instance, yang membuat arsitektur penyebaran menjadi sangat kompleks.

Kembali ke tingkat tata kelola arsitektur, pemilihan solusi monitoring di lingkungan Cloud Native juga menimbulkan beberapa tantangan. Begitu pemilihan solusi salah, biaya penggunaan selanjutnya sangat tinggi, dan kerugian bisa sangat besar jika arahnya salah.

Juga, ada masalah kapasitas yang terlibat di tingkat monitoring. Saat menyebarkan aplikasi di K8s, Anda dapat dengan mudah mengkonfigurasi pembatasan laju untuk membatasi detail sumber daya yang dapat digunakan aplikasi. Namun, di lingkungan K8s, masih cukup mudah untuk menjual sumber daya secara berlebihan, memanfaatkan sumber daya secara berlebihan, dan meluapnya memori karena kondisi ini.

Selain itu, situasi lain di kluster K8s di mana seluruh kluster atau node kehabisan sumber daya akan menyebabkan pengusiran sumber daya, yang berarti sumber daya yang sudah berjalan di node diusir ke node lain. Jika sumber daya kluster ketat, badai node dapat dengan mudah menyebabkan seluruh kluster crash.

Evolusi Aplikasi dan Pola Multi-kluster

Di tingkat evolusi arsitektur aplikasi, masalah intinya adalah penemuan layanan.

K8s menyediakan mekanisme penemuan layanan berbasis DNS secara default, tetapi jika bisnis mencakup koeksistensi bisnis cloud dan stok, akan lebih rumit untuk menggunakan mekanisme penemuan layanan DNS untuk menangani situasi tersebut.

Sementara itu, jika perusahaan memilih teknologi Cloud Native, dengan perluasan skala bisnis, mereka akan secara bertahap mempertimbangkan arah pemrosesan multi-node, yang kemudian akan melibatkan masalah multi-kluster.

Misalnya, kami ingin memberikan model ketersediaan yang lebih tinggi kepada pelanggan melalui beberapa kluster, dan kali ini akan melibatkan orkestrasi layanan antara beberapa kluster, distribusi beban multi-kluster dan sinkronisasi konfigurasi, serta bagaimana menangani dan menyebarkan strategi untuk kluster dalam skenario multi-cloud dan hybrid cloud. Ini adalah beberapa tantangan yang akan dihadapi.

Bagaimana APISIX Memungkinkan Transformasi Digital

Apache APISIX adalah API gateway Cloud Native di bawah Apache Software Foundation, yang dinamis, real-time, dan berkinerja tinggi, menyediakan fitur manajemen lalu lintas yang kaya seperti load balancing, upstream dinamis, canary release, circuit breaking, autentikasi, observabilitas, dll. Anda dapat menggunakan Apache APISIX untuk menangani lalu lintas north-south tradisional, serta lalu lintas east-west antara layanan.

Saat ini, berdasarkan evolusi arsitektur dan perubahan aplikasi yang dijelaskan di atas, solusi Ingress controller dan Service Mesh berbasis APISIX juga telah diturunkan di Apache APISIX untuk membantu perusahaan melakukan transformasi digital dengan lebih baik.

Solusi APISIX Ingress

Apache APISIX Ingress Controller adalah implementasi Kubernetes Ingress Controller yang terutama berfungsi sebagai gateway lalu lintas untuk menangani lalu lintas Kubernetes north-south.

Arsitektur APISIX Ingress Controller mirip dengan APISIX dalam hal ini adalah arsitektur terpisah untuk control plane dan data plane. Dalam hal ini, APISIX digunakan sebagai data plane untuk pemrosesan lalu lintas aktual.

Saat ini, APISIX Ingress Controller mendukung tiga metode konfigurasi berikut dan kompatibel dengan semua plugin APISIX secara langsung:

• Dukungan untuk sumber daya Ingress asli K8s. Pendekatan ini memungkinkan APISIX Ingress Controller memiliki tingkat adaptabilitas yang lebih tinggi. Sejauh ini, APISIX Ingress Controller adalah versi yang paling didukung dari produk Ingress controller open-source dan berpengaruh.

• Dukungan untuk menggunakan sumber daya kustom. Sumber daya kustom saat ini dari APISIX Ingress Controller adalah seperangkat spesifikasi CRD yang dirancang sesuai dengan semantik APISIX. Menggunakan sumber daya kustom memudahkan integrasi dengan APISIX dan lebih asli.

• Dukungan untuk Gateway API. Sebagai generasi berikutnya dari standar Ingress, APISIX Ingress Controller telah mulai mendukung Gateway API (tahap Beta). Seiring evolusi Gateway API, kemungkinan besar akan menjadi sumber daya bawaan untuk K8s secara langsung.

APISIX Ingress Controller memiliki keunggulan berikut dibandingkan Ingress NGINX:

• Pemisahan arsitektur. Di APISIX Ingress, arsitektur data plane dan control plane dipisahkan. Ketika tekanan pemrosesan lalu lintas tinggi dan Anda ingin memperluas kapasitas, Anda dapat dengan mudah melakukan perluasan data plane, yang memungkinkan lebih banyak data plane untuk dilayani secara eksternal tanpa perlu melakukan penyesuaian apa pun pada control plane.

• Skalabilitas tinggi dan dukungan untuk plugin kustom.

• Sebagai pilihan data plane, dengan kinerja tinggi dan fitur yang sepenuhnya dinamis. Berkat fitur sepenuhnya dinamis dari APISIX, memungkinkan untuk melindungi lalu lintas bisnis sebanyak mungkin dengan penggunaan APISIX Ingress.

Saat ini, APISIX Ingress Controller digunakan oleh banyak perusahaan di seluruh dunia, seperti China Mobile Cloud Open Platform (produk API terbuka dan cloud IDE), Upyun, dan Copernicus (bagian dari Europe's Eyes on Earth).

APISIX Ingress Controller masih dalam iterasi berkelanjutan, dan kami berencana untuk meningkatkan lebih banyak fungsi dengan cara berikut:

1. Menyelesaikan dukungan untuk Gateway API untuk memungkinkan konfigurasi skenario yang lebih banyak.
2. Dukungan untuk proxy layanan eksternal.
3. Dukungan asli untuk beberapa registri untuk membuat APISIX Ingress Controller lebih serbaguna.
4. Pembaruan arsitektur untuk membuat model arsitektur baru;
5. Integrasi dengan Argo CD/Flux dan alat GitOps lainnya untuk menciptakan ekosistem yang kaya.

Jika Anda tertarik dengan solusi APISIX Ingress, silakan ikuti pembaruan komunitas untuk iterasi produk dan tren komunitas.

Solusi APISIX Service Mesh

Saat ini, selain API gateway dan solusi Ingress, solusi Service Mesh berbasis APISIX juga sedang dalam iterasi aktif.

Solusi Service Mesh berbasis APISIX terdiri dari dua komponen utama, yaitu control plane dan data plane. Istio dipilih untuk control plane karena merupakan pemimpin industri dengan komunitas yang aktif dan didukung oleh banyak vendor. APISIX dipilih untuk menggantikan Envoy di sisi data, memungkinkan kinerja tinggi dan skalabilitas APISIX untuk dimanfaatkan.

Service Mesh APISIX masih terus dikejar, dengan iterasi selanjutnya direncanakan dalam arah berikut:

• Melakukan akselerasi eBPF untuk meningkatkan efektivitas keseluruhan.

• Melakukan integrasi kemampuan plugin untuk memungkinkan penggunaan kemampuan APISIX Ingress yang lebih baik dalam arsitektur Service Mesh.

• Membuat alat migrasi yang mulus untuk menyediakan alat yang lebih mudah dan menyederhanakan proses bagi pengguna.

Secara umum, evolusi arsitektur dan teknologi di era Cloud Native membawa kita baik peluang maupun tantangan. Apache APISIX sebagai gateway Cloud Native telah berkomitmen untuk lebih banyak adaptasi dan integrasi teknis untuk tren Cloud Native. Berbagai solusi berbasis APISIX juga telah mulai membantu pengguna perusahaan untuk melakukan transformasi digital dan membantu perusahaan untuk beralih ke jalur Cloud Native dengan lebih lancar.