Di balik CEP: arsitektur tiga tier di belakang cloud white-label

Cloud Enabler Platform memungkinkan penyedia hosting atau telko menjual cloud dengan mereknya sendiri. Di baliknya ada tiga tier, masing-masing dengan satu tanggung jawab.

Tier 1: frontend

Progressive Web Application Next.js/React: konsol bermerek yang benar-benar dilihat tenant. White-label sejak desain: logo, domain, dan skema warna milik operator, bukan milik kami. Semua yang dilakukan tenant di sini (membuat VM, memasang disk, mengundang rekan) adalah panggilan API ke tier di bawahnya.

Tier 2: backend

Server REST API berbahasa Go yang memegang dua masalah tersulit dalam multi-tenancy:

• Autentikasi dan otorisasi: siapa Anda, dan organisasi serta proyek mana yang Anda ikuti.
• Isolasi tenant: setiap request di-scope ke tenant-nya sebelum menyentuh cluster plane. UUID tenant bukan sekadar saran; ia adalah batas yang ditegakkan seluruh API.

Menjaga tier ini stateless membuatnya bisa diskalakan horizontal dan, sama pentingnya bagi pelanggan kami, bisa diaudit.

Tier 3: cluster plane

Kubernetes biasa, diperluas dengan tumpukan virtualisasi:

• CRD KubeVirt untuk menjalankan virtual machine utuh sebagai workload Kubernetes kelas satu
• CDI DataVolume untuk mengimpor dan meng-clone disk image
• Calico untuk network policy antar workload tenant

Tier inilah yang membuat CEP portabel. Klaster Kubernetes conformant mana pun, baik di AwaniOS, di perangkat keras yang sudah ada, maupun di kandang kolokasi, bisa menjadi kapasitas cloud.

Mengapa tiga tier, bukan dua

Jalan pintas yang menggoda adalah membiarkan frontend berbicara langsung ke Kubernetes. Kami tidak melakukannya, karena tier API adalah tempat jaminan kedaulatan hidup: scoping tenancy, penegakan kuota, jejak audit. Memusatkan logika itu di satu layanan Go berarti kode yang kritis terhadap keamanan punya satu rumah, satu test suite, dan satu unit deployment.

Selengkapnya di dokumentasi CEP, termasuk FAQ tentang bagaimana tenancy dipetakan ke namespace Kubernetes.