Prinsip desain beban kerja SaaS di Azure
Sebagai vendor perangkat lunak independen (ISV) yang memberikan solusi SaaS, Anda bertanggung jawab atas keunggulan arsitektur solusi, dan Anda berbagi tanggung jawab dengan pelanggan Anda. Mereka mengandalkan solusi Anda, dan masalah dapat berkabut dengan mereka. Jika organisasi Anda matang dan memiliki basis pelanggan yang mapan, keandalan dan keamanan kemungkinan menjadi kekhawatiran terbesar Anda. Waktu henti dan pelanggaran keamanan dapat memiliki konsekuensi negatif bagi pendapatan dan reputasi perusahaan Anda.
Tetapi banyak ISV, terutama ISV startup, beroperasi dengan sumber daya terbatas untuk meminimalkan biaya. Jika organisasi Anda berada dalam fase startup, Anda mungkin harus membuat tradeoff agresif untuk maju ke fase pertumbuhan berikutnya. Anda mungkin tidak memiliki tim khusus untuk pemerintahan, keamanan, atau otomatisasi penyebaran, tetapi ingatlah untuk merencanakan pertumbuhan di masa mendatang. Jika Anda harus mengambil risiko, buat keputusan terhitung.
Cara Anda merancang solusi yang beroperasi pada volume skala rendah berbeda dari solusi skala tinggi. Untuk mendukung pertumbuhan yang pesat, Anda harus merancang arsitektur beban kerja SaaS dengan fleksibilitas dan kemampuan beradaptasi. Artikel ini menyajikan prinsip-prinsip yang mendasarinya dengan mempertimbangkan evolusi pertumbuhan tersebut. Pertimbangkan kelima pilar Well-Architected Framework bersama-sama, termasuk tradeoff. Ada standar minimum di semua pilar, jadi pertimbangkan masing-masing pilar. Jika Anda tidak menerapkan prinsip-prinsip ini, Anda dapat memperkenalkan kerugian keuangan dan mengurangi kepercayaan pelanggan.
Keandalan
| Prinsip desain | Pertimbangan |
|---|---|
| Prioritaskan ketersediaan. | Solusi Anda adalah bisnis Anda. Pertahankan ketersediaan tinggi sebanyak praktis. Jika solusi Anda mengalami pemadaman, dampaknya dapat memengaruhi tidak hanya pelanggan Anda tetapi juga pelanggan mereka. |
| Jadilah eksplisit tentang perjanjian tingkat layanan (SLA) yang Anda tawarkan kepada pelanggan Anda. | Saat Anda membuat SLA yang didukung secara finansial untuk pelanggan Anda, pastikan Anda dapat memenuhinya dan bahwa komponen yang Anda andalkan kompatibel dengan mereka. Tinjau SLA komposit untuk layanan Azure yang mendasar sebagai bagian dari proses desain SLA Anda. Jangan membuat asumsi. Mencerminkan model tanggung jawab bersama Anda di SLA Anda. |
Tradeoff: Keandalan dan biaya. Untuk mencapai keandalan tinggi, Anda sering kali perlu menyebarkan sumber daya tambahan. Misalnya, Anda dapat mendistribusikan sumber daya di beberapa zona ketersediaan atau wilayah. Beberapa layanan Azure menawarkan replikasi geografis bawaan atau replikasi antar-zona, tetapi fitur-fitur ini sering kali dilengkapi dengan biaya tinggi.
Buat keputusan berdasarkan informasi tentang tingkat ketahanan yang diizinkan anggaran Anda. Jika keandalan beberapa komponen atau alur dalam beban kerja tidak memiliki implikasi finansial, pertimbangkan peluang berbilai rendah untuk meningkatkan ketahanan Anda. Misalnya, Anda dapat menggunakan zona ketersediaan layanan platform, secara teratur mencadangkan data ke lokasi fisik lain, dan menggunakan infrastruktur sebagai kode (IaC) untuk menyebarkan ulang sumber daya dengan cepat selama proses pemulihan.
Keamanan
| Prinsip desain | Pertimbangan |
|---|---|
| Menetapkan tata kelola sebagai fondasi untuk keamanan. | Tetapkan praktik tata kelola yang baik sejak awal daripada mengatasi masalah nanti. Banyak faktor memengaruhi keamanan, seperti bagaimana Anda mengelola peran, mengatur sumber daya, dan menerapkan kebijakan. Tanpa tata kelola yang kuat, kontrol keamanan tidak melindungi sistem. |
| Ikuti garis besar keamanan cloud sejak hari pertama. | Mengharapkan audit keamanan dari pelanggan Anda. Masukkan jejak audit di awal desain Anda. |
| Isolasi pelanggan Anda, dan isolasi segmen Anda. | Gunakan model penyewaan Anda sebagai strategi untuk isolasi data. Segmentasikan penyebaran dan lingkungan Anda. |
| Mulailah dengan Zero Trust, dan berikan akses sekecil mungkin. | Default ke posisi tanpa akses. Perkenalkan akses minimum hanya jika diperlukan. Gunakan strategi ini untuk manajemen identitas dan lalu lintas jaringan. Meninjau alur secara teratur melalui sistem, dan mengambil tindakan pada anomali. |
| Hindari kredensial jika memungkinkan. Jika Anda harus menggunakan kredensial, lindungi kredensial tersebut. | Perlakukan kredensial sebagai tanggung jawab. Gunakan penyedia identitas dan teknik terkemuka yang meminimalkan penyimpanan kredensial. Saat tidak dapat ditolak, lindungi kredensial dengan pendekatan cloud-native yang aman. Tangani kredensial dan rahasia pelanggan dengan sangat hati-hati. |
| Mengadopsi keamanan sebagai proses yang sedang berlangsung. | Terus mengevaluasi kembali postur keamanan Anda. Pertimbangkan lanskap ancaman yang terus berkembang, kemampuan dan protokol baru, dan persyaratan kepatuhan atau peraturan yang diperbarui. |
Pengoptimalan biaya
| Prinsip desain | Pertimbangan |
|---|---|
| Bayar hanya untuk apa yang Anda butuhkan. | Manfaatkan fitur Microsoft Cost Management untuk memahami pengeluaran Anda secara keseluruhan. Prioritaskan kategori sumber daya termahal untuk peninjauan lebih lanjut. Identifikasi area tempat Anda mungkin terlalu banyak mengesampingkan. |
| Gunakan apa yang Anda bayar. | Maksimalkan nilai dari sumber daya yang Anda bayar tetapi anda mungkin kurang digunakan. |
| Memodelkan biaya Anda. | Lacak biaya barang yang dijual. Pahami biaya untuk memberikan solusi Anda kepada pelanggan. Proses ini mirip dengan pembuatan produk fisik. Untuk menginformasikan pengambilan keputusan Anda, pantau biaya untuk setiap pelanggan relatif terhadap pendapatan yang mereka hasilkan. Untuk memahami dan mengagregasi pengeluaran Azure Anda dengan cepat, terapkan proses tata kelola, seperti organisasi sumber daya dan pemberian tag yang baik. |
| Pahami bagaimana biaya dan pendapatan Anda terkait. | Hindari situasi di mana biaya meningkat tanpa kenaikan pendapatan yang sesuai. Misalnya, biaya mungkin meningkat jika Anda menambahkan fitur baru yang menawarkan penyimpanan gratis tanpa batas. Demikian pula, jika Anda menagih pelanggan berdasarkan jumlah pengguna, pastikan Anda mengikat fungsionalitas dengan pengguna. |
Keunggulan operasional
| Prinsip desain | Pertimbangan |
|---|---|
| Pahami model tanggung jawab bersama. | Tentukan dengan jelas tanggung jawab penyedia cloud, pelanggan, dan organisasi Anda. Pastikan bahwa semua orang tahu siapa yang bertanggung jawab atas tugas mana. |
| Bersiaplah untuk mengoperasikan solusi atas nama pelanggan Anda. | Siapkan organisasi, tim, proses, dan alat Anda untuk mendukung operasi SaaS dalam skala besar. |
| Mengadopsi proses yang konsisten. | Gunakan stempel penyebaran. Dorong konsistensi di seluruh konfigurasi dan arsitektur stempel. Mengotomatiskan atau menstandarkan proses. |
| Formalisasi pengecualian atau perbedaan. | Tentukan SKU yang berbeda untuk memenuhi berbagai kebutuhan. Gunakan metode ini untuk menghindari penyebaran, konfigurasi, atau kode kustom untuk pelanggan yang berbeda. |
| Luncurkan perubahan dengan aman. | Terapkan proses penyebaran yang aman yang dapat Anda gunakan untuk paparan progresif, pemantauan konstan, dan putar kembali jika masalah muncul. Gunakan proses yang konsisten untuk perubahan kode, infrastruktur, dan konfigurasi. Kontrol jumlah versi solusi yang Anda sebarkan pada waktu tertentu. |
Efisiensi kinerja
| Prinsip desain | Pertimbangan |
|---|---|
| Terapkan skala global untuk mengaktifkan performa global. | Memberikan pengalaman yang baik bagi pelanggan global melalui penyebaran multiregion atau perutean lalu lintas yang dipercepat. |
| Kuantifikasi skala yang Anda harapkan. | Skenario pertumbuhan terbaik, rata-rata, dan terburuk model. Analisis tren dan konsultasikan dengan tim penjualan Anda untuk proyeksi realistis. Rencanakan strategi penskalakan yang fleksibel untuk mengakomodasi berbagai kemungkinan pertumbuhan. |
| Memahami titik skala. | Identifikasi di mana Anda mungkin membutuhkan fleksibilitas. Pemicu umum termasuk jumlah pelanggan atau penyewa, pengguna, dan transaksi per pengguna. Pahami bagaimana faktor-faktor ini berubah seiring pertumbuhan bisnis Anda dan pengaruhnya terhadap arsitektur Anda. |
| Desain untuk peluasan skala. | Peningkatan skala memiliki batas, tetapi penskalaan keluar memungkinkan ekspansi yang lebih besar. Tidak semuanya meluaskan skala, jadi pertimbangkan untuk menggunakan stempel penyebaran untuk menskalakan solusi Anda sebagai unit untuk menghindari keterbatasan peningkatan sumber daya. |
Langkah selanjutnya
Mulai perjalanan pembelajaran Anda dengan mengoptimalkan penagihan pelanggan dan strategi manajemen biaya Anda.