Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mendefinisikan ulang multi-tenancy

Istilah multi-tenancy dan SaaS sering terhubung erat. Dalam beberapa kasus, organisasi menggambarkan SaaS dan multi-tenancy sebagai hal yang sama. Meskipun ini mungkin tampak alami, menyamakan SaaS dan multi-tenancy cenderung memimpin tim untuk mengambil pandangan teknis murni SaaS ketika, pada kenyataannya, SaaS lebih merupakan model bisnis daripada strategi arsitektur.

Untuk lebih memahami konsep ini, mari kita mulai dengan pandangan klasik multi-tenancy. Dalam pandangan yang murni berfokus pada infrastruktur ini, multi-tenancy digunakan untuk menggambarkan bagaimana sumber daya dibagi oleh penyewa untuk mempromosikan kelincahan dan efisiensi biaya.

Misalkan, misalnya, Anda memiliki layanan mikro atau instans Amazon Elastic Compute Cloud (Amazon EC2) yang dikonsumsi oleh beberapa penyewa sistem SaaS Anda. Layanan ini akan dipandang berjalan dalam model multi-tenant, karena penyewa berbagi penggunaan infrastruktur yang menjalankan layanan ini.

Tantangan dari definisi ini adalah bahwa ia juga secara langsung melampirkan gagasan teknis multi-tenancy ke SaaS. Diasumsikan bahwa karakteristik SaaS yang menentukan adalah bahwa ia harus memiliki infrastruktur multi-penyewa bersama. Pandangan SaaS ini mulai berantakan ketika kita melihat berbagai cara SaaS diwujudkan di lingkungan yang berbeda.

Diagram berikut memberikan tampilan sistem SaaS yang mengekspos beberapa tantangan yang kami miliki dengan mendefinisikan multi-tenancy.

Di sini Anda akan melihat model SaaS klasik yang dijelaskan sebelumnya, dengan serangkaian layanan aplikasi yang dikelilingi oleh layanan bersama yang memungkinkan Anda mengelola dan mengoperasikan penyewa secara kolektif.

Yang baru adalah layanan mikro yang kami sertakan. Diagram mencakup tiga contoh layanan mikro: produk, pesanan, dan katalog. Jika Anda melihat lebih dekat pada model penyewaan masing-masing layanan ini, Anda akan melihat mereka semua menggunakan pola sewa yang sedikit berbeda.

Layanan produk berbagi semua sumber dayanya (komputasi dan penyimpanan) dengan semua penyewa. Ini sejalan dengan definisi klasik multi-tenancy. Namun, jika Anda melihat layanan pesanan, Anda akan melihat bahwa itu telah berbagi komputasi, tetapi penyimpanan terpisah untuk setiap penyewa.

Layanan katalog menambahkan variasi lain di mana komputasi terpisah untuk setiap penyewa (penyebaran layanan mikro terpisah untuk setiap penyewa), tetapi berbagi penyimpanan untuk semua penyewa.

Variasi sifat ini umum terjadi di lingkungan SaaS. Tetangga yang bising, model berjenjang, kebutuhan isolasi — ini adalah di antara daftar alasan yang mungkin Anda bagikan secara selektif atau silo bagian dari solusi SaaS Anda.

Mengingat variasi-variasi ini—dan banyak kemungkinan lainnya—menjadi lebih menantang untuk mengetahui bagaimana Anda harus menggunakan istilah multi-tenant untuk mengkarakterisasi lingkungan ini. Secara keseluruhan, sejauh menyangkut pelanggan, ini adalah lingkungan multi-penyewa. Namun, jika kita menggunakan definisi paling teknis, beberapa bagian dari lingkungan ini multi-penyewa dan beberapa tidak.

Inilah sebabnya mengapa menjadi perlu untuk menjauh dari menggunakan istilah multi-tenant untuk mengkarakterisasi lingkungan SaaS. Sebagai gantinya, kita dapat berbicara tentang bagaimana multi-tenancy diimplementasikan dalam aplikasi Anda, tetapi hindari menggunakannya untuk mengkarakterisasi solusi sebagai SaaS. Jika istilah multi-tenant akan digunakan, lebih masuk akal untuk menggunakannya untuk menggambarkan seluruh lingkungan SaaS sebagai multi-penyewa, mengetahui bahwa beberapa bagian arsitektur dapat dibagi dan beberapa mungkin tidak. Secara keseluruhan, Anda masih mengoperasikan dan mengelola lingkungan ini dalam model multi-penyewa.

Kasus ekstrim

Untuk lebih menyoroti gagasan penyewaan ini, mari kita lihat model SaaS yang memiliki penyewa yang berbagi sumber daya nol. Diagram berikut memberikan contoh lingkungan SaaS yang digunakan oleh beberapa penyedia SaaS.

Dalam diagram ini, Anda akan melihat bahwa kita masih memiliki lingkungan bersama di sekitar penyewa ini. Namun, setiap penyewa dikerahkan dengan koleksi sumber daya khusus. Tidak ada yang dibagikan oleh penyewa dalam model ini.

Contoh ini menantang apa artinya menjadi multi-tenant. Apakah ini lingkungan multi-penyewa meskipun tidak ada sumber daya yang dibagikan? Penyewa yang menggunakan sistem ini memiliki semua harapan yang sama dengan yang Anda miliki tentang lingkungan SaaS dengan sumber daya bersama. Bahkan, mereka mungkin tidak memiliki kesadaran tentang bagaimana sumber daya mereka dikerahkan di bawah kap lingkungan SaaS.

Meskipun penyewa ini berjalan dalam infrastruktur siloed, mereka masih dikelola dan dioperasikan secara kolektif. Mereka berbagi satu orientasi terpadu, identitas, metrik, penagihan, dan pengalaman operasional. Juga, ketika versi baru dirilis, itu digunakan untuk semua penyewa. Agar ini berfungsi, Anda tidak dapat mengizinkan penyesuaian satu kali untuk penyewa individu.

Contoh ekstrim ini memberikan model yang baik untuk menguji gagasan SaaS multi-penyewa. Meskipun mungkin tidak menyadari semua efisiensi infrastruktur bersama, ini adalah lingkungan SaaS multi-penyewa yang sepenuhnya valid. Untuk beberapa pelanggan, domain mereka mungkin mendikte bahwa beberapa atau semua pelanggan mereka menjalankan model ini. Itu tidak berarti mereka bukan SaaS. Jika mereka menggunakan layanan bersama ini dan semua penyewa menjalankan versi yang sama, ini masih sesuai dengan prinsip-prinsip dasar SaaS.

Mengingat parameter ini dan definisi SaaS yang lebih luas ini, Anda dapat melihat kebutuhan untuk mengembangkan penggunaan istilah multi-tenant. Lebih masuk akal untuk merujuk pada sistem SaaS apa pun yang dikelola dan dioperasikan secara kolektif sebagai multi-penyewa. Kemudian, Anda dapat tunduk pada terminologi yang lebih terperinci untuk menggambarkan bagaimana sumber daya dibagikan atau didedikasikan dalam implementasi solusi SaaS.