Share via

Pertimbangan siklus hidup penyewa dalam solusi multipenyewa

  • Artikel

Saat Anda mempertimbangkan arsitektur multipenyewa, penting untuk mempertimbangkan semua tahap yang berbeda dalam siklus hidup penyewa. Di halaman ini, kami memberikan panduan bagi pembuat keputusan teknis tentang tahapan siklus hidup dan pertimbangan penting untuk setiap tahap.

Penyewa uji coba

Ketika Anda membangun solusi SaaS, pertimbangkan bahwa banyak pelanggan meminta atau memerlukan uji coba sebelum mereka berkomitmen untuk membeli solusi.

Uji coba dapat membuat pertimbangan unik berikut:

  • Persyaratan layanan: Haruskah uji coba tunduk pada persyaratan keamanan, performa, dan tingkat layanan data yang sama dengan data untuk pelanggan lengkap?
  • Infrastruktur: Haruskah Anda menggunakan infrastruktur yang sama untuk penyewa uji coba seperti untuk pelanggan lengkap, atau haruskah Anda memiliki infrastruktur khusus untuk penyewa uji coba?
  • Migrasi: Jika pelanggan membeli layanan Anda setelah uji coba, bagaimana mereka akan memigrasikan data dari penyewa uji coba mereka ke penyewa berbayar mereka?
  • Proses permintaan: Apakah ada batasan tentang siapa yang dapat meminta uji coba? Bagaimana Anda dapat mencegah penyalahgunaan solusi? Apakah Anda mengizinkan pembuatan penyewa uji coba otomatis atau apakah tim Anda terlibat dalam setiap permintaan?
  • Batas: Batasan apa yang Anda inginkan atau perlukan untuk menempatkan pelanggan uji coba, seperti batas waktu, pembatasan fitur, atau batasan sekeliling performa?

Dalam beberapa situasi, model harga freemium dapat menjadi alternatif untuk menyediakan uji coba.

Melakukan onboarding untuk penyewa baru

Saat melakukan onboarding penyewa baru, pertimbangkan hal berikut:

  • Proses: Apakah onboarding akan menjadi proses layanan mandiri, otomatis, atau manual?
  • Residensi data: Apakah penyewa memiliki persyaratan khusus untuk residensi data? Misalnya, apakah ada peraturan kedaulatan data yang berlaku?
  • Kepatuhan: Apakah penyewa harus memenuhi standar kepatuhan apa pun (seperti PCI DSS, HIPAA, dan sebagainya)?
  • Pemulihan bencana: Apakah penyewa memiliki persyaratan pemulihan bencana tertentu, seperti tujuan waktu pemulihan (RTO) atau tujuan titik pemulihan (RPO)? Apakah ini berbeda dari jaminan yang Anda berikan kepada penyewa lain?
  • Informasi: Informasi apa yang Anda butuhkan, untuk dapat sepenuhnya onboarding penyewa? Misalnya, apakah Anda perlu mengetahui nama hukum organisasi mereka? Apakah Anda memerlukan logo perusahaan mereka untuk memberi merek aplikasi, dan jika demikian, ukuran dan format file apa yang Anda butuhkan?
  • Penagihan: Apakah platform menyediakan opsi harga dan model penagihan yang berbeda?
  • Lingkungan: Apakah penyewa memerlukan lingkungan pra-produksi? Dan apakah ada harapan yang ditetapkan pada ketersediaan untuk lingkungan tersebut? Apakah ketersediaan bersifat sementara (sesuai permintaan) atau selalu tersedia?

Setelah penyewa di-onboarding, mereka pindah ke status 'bisnis seperti biasa'. Namun, masih ada beberapa peristiwa siklus hidup penting yang dapat terjadi, bahkan ketika mereka berada dalam keadaan ini.

Memperbarui infrastruktur penyewa

Anda perlu mempertimbangkan bagaimana Anda menerapkan pembaruan ke infrastruktur penyewa Anda. Penyewa yang berbeda mungkin memiliki pembaruan yang diterapkan pada waktu yang berbeda.

Lihat Pembaruan untuk pertimbangan lain tentang memperbarui penyebaran penyewa.

Melakukan penskalaan infrastruktur penyewa

Pertimbangkan jika penyewa mungkin memiliki pola bisnis musiman, atau mengubah tingkat konsumsi untuk solusi Anda.

Misalnya, jika Anda memberikan solusi untuk peritel, Anda mungkin mengharapkan bahwa waktu-waktu tertentu dalam setahun akan sangat sibuk di beberapa wilayah geografis, dan diam di lain waktu. Pertimbangkan apakah musiman ini memengaruhi cara Anda merancang dan menskalakan solusi Anda. Perhatikan bagaimana musiman dapat memengaruhi masalah tetangga yang bising, seperti ketika subset penyewa mengalami peningkatan beban yang tiba-tiba dan tidak terduga yang mengurangi performa penyewa lain. Anda dapat mempertimbangkan untuk menerapkan mitigasi, yang mungkin mencakup penskalaan infrastruktur penyewa individu, memindahkan penyewa antar penyebaran, dan menyediakan tingkat kapasitas yang memadai untuk menangani lonjakan dan palung dalam lalu lintas.

Memindahkan penyewa antar infrastruktur

Anda mungkin perlu memindahkan penyewa antar infrastruktur karena sejumlah alasan, termasuk yang berikut ini:

  • Rebalancing: Anda mengikuti pendekatan yang dipartisi secara vertikal untuk memetakan penyewa Anda ke infrastruktur, dan Anda perlu memindahkan penyewa ke penyebaran yang berbeda untuk menyeimbangkan kembali beban Anda.
  • Upgrade: Penyewa meningkatkan SKU atau tingkat harga mereka, dan mereka perlu dipindahkan ke penyewa tunggal, penyebaran khusus dengan isolasi yang lebih tinggi dari penyewa lain.
  • Migrasi: Penyewa meminta data mereka dipindahkan ke penyimpanan data khusus.
  • Pemindahan wilayah: Penyewa mengharuskan data mereka dipindahkan ke wilayah geografis baru. Ini mungkin terjadi selama akuisisi perusahaan, atau ketika hukum atau situasi geopolitik berubah.

Pertimbangkan cara Anda memindahkan data penyewa, serta mengarahkan permintaan ke kumpulan infrastruktur baru yang menghosting instansnya. Anda juga harus mempertimbangkan apakah memindahkan penyewa dapat mengakibatkan waktu henti, dan memastikan penyewa sepenuhnya mengetahui risikonya.

Menggabungkan dan membagi penyewa

Anda mungkin tergoda untuk menganggap penyewa atau pelanggan sebagai entitas statis yang tidak berubah. Namun, pada kenyataannya, hal ini sering tidak benar. Contohnya:

  • Dalam skenario bisnis, perusahaan dapat diakuisisi atau digabungkan, termasuk perusahaan yang berlokasi di wilayah geografis yang berbeda.
  • Demikian pula, dalam skenario bisnis, perusahaan dapat terpecah atau melakukan divestasi.
  • Dalam situasi konsumen, pengguna individu dapat bergabung atau meninggalkan kelompok keluarga.

Pertimbangkan jika Anda perlu menyediakan kemampuan untuk mengelola penggabungan dan pemisahan data, identitas pengguna, dan sumber daya. Pertimbangkan juga cara kepemilikan data memengaruhi penanganan operasi gabungan dan pemisahan. Misalnya, pertimbangkan aplikasi fotografi konsumen yang dibuat untuk keluarga guna berbagi foto satu sama lain. Apakah foto yang dimiliki oleh masing-masing anggota keluarga yang membagikannya, atau oleh keluarga secara keseluruhan? Jika pengguna meninggalkan keluarga, haruskah data mereka dihapus atau tetap berada di kumpulan data keluarga? Jika pengguna bergabung dengan keluarga lain, haruskah foto lama mereka berpindah bersama mereka?

Melakukan offboarding penyewa

Tidak dapat dihindari bahwa penyewa kadang-kadang perlu dihapus dari solusi. Dalam solusi multipenyewa, hal ini membawa beberapa pertimbangan penting, termasuk yang berikut ini:

  • Periode retensi: Berapa lama Anda harus menyimpan data pelanggan? Apakah ada persyaratan hukum untuk menghancurkan data, setelah jangka waktu tertentu?
  • Onboarding ulang: Haruskah Anda menyediakan kemampuan bagi pelanggan untuk di-onboarding ulang?
  • Rebalancing: Jika Anda menjalankan infrastruktur bersama, apakah Anda perlu menyeimbangkan kembali alokasi penyewa ke infrastruktur?

Menonaktifkan dan mengaktifkan kembali penyewa

Terdapat situasi saat akun pelanggan mungkin perlu dinonaktifkan atau diaktifkan kembali. Contohnya:

  • Pelanggan telah meminta penonaktifan. Dalam sistem konsumen, pelanggan mungkin memilih untuk berhenti berlangganan.
  • Pelanggan tidak dapat ditagih, dan Anda perlu menonaktifkan langganan.

Penonaktifan berbeda dengan offboarding karena dimaksudkan hanya untuk sementara waktu. Namun, setelah jangka waktu tertentu, Anda dapat memilih untuk melakukan offboarding penyewa yang dinonaktifkan.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

  • John Downs | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lainnya:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Pertimbangkan model harga yang akan Anda gunakan untuk solusi.