Membangun untuk kebutuhan bisnis

  • Artikel

Setiap keputusan desain harus dibenarkan oleh persyaratan bisnis. Prinsip desain ini mungkin tampak jelas, tetapi sangat penting untuk diingat saat merancang aplikasi Azure.

Haruskah aplikasi Anda mendukung jutaan pengguna, atau beberapa ribu? Apakah ada ledakan lalu lintas besar, atau beban kerja yang stabil? Tingkat pemadaman aplikasi apa yang dapat diterima? Pada akhirnya, persyaratan bisnis mendorong pertimbangan desain ini.

Rekomendasi berikut membantu Anda merancang dan membangun solusi untuk memenuhi persyaratan bisnis:

  • Tentukan tujuan bisnis seperti tujuan waktu pemulihan (RTO), tujuan titik pemulihan (RPO), dan pemadaman maksimum yang dapat ditoleransi (MTO). Angka-angka ini harus menginformasikan keputusan tentang arsitektur.

    Misalnya, bisnis Anda membutuhkan RTO yang sangat rendah dan RPO yang sangat rendah. Anda dapat memilih untuk menggunakan arsitektur zona redundan untuk memenuhi persyaratan ini. Jika bisnis Anda dapat mentolerir RTO dan RPO yang lebih tinggi, menambahkan redundansi dapat menambah biaya tambahan tanpa manfaat bisnis.

  • Pertimbangkan risiko kegagalan yang perlu Anda mitigasi. Ikuti panduan Desain untuk penyembuhan diri untuk merancang solusi Anda agar tahan terhadap banyak jenis mode kegagalan umum. Pertimbangkan apakah Anda perlu mempertimbangan situasi yang lebih kecil kemungkinannya, seperti area geografis yang mengalami bencana alam besar yang mungkin memengaruhi semua zona ketersediaan di wilayah tersebut. Mengurangi risiko yang tidak biasa ini umumnya lebih mahal dan melibatkan tradeoff yang signifikan, sehingga memiliki pemahaman yang jelas tentang toleransi bisnis terhadap risiko.

  • Perjanjian tingkat layanan dokumen (SLA) dan tujuan tingkat layanan (SLA), termasuk metrik ketersediaan dan performa. Misalnya, solusi yang diusulkan mungkin memberikan ketersediaan 99,95%. Apakah SLO memenuhi SLA adalah keputusan bisnis.

  • Aplikasi model untuk domain bisnis Anda. Analisis persyaratan bisnis, dan gunakan persyaratan ini untuk memodelkan solusi. Pertimbangkan untuk menggunakan pendekatan desain berbasis domain (DDD) untuk membuat model domain yang mencerminkan proses bisnis dan kasus penggunaan Anda.

  • Tentukan persyaratan fungsional dan tidak berfungsi. Persyaratan fungsi menentukan apakah aplikasi melakukan tugasnya. Persyaratan nonfungsi menentukan seberapa baik performa aplikasi. Pastikan Anda memahami persyaratan nonfungsi seperti skalabilitas, ketersediaan, dan latensi. Persyaratan ini memengaruhi keputusan desain dan pilihan teknologi.

  • Mengurai beban kerja. Beban kerja dalam konteks ini berarti kemampuan diskrit atau tugas komputasi yang dapat dipisahkan secara logis dari tugas lain. Beban kerja yang berbeda mungkin memiliki persyaratan yang berbeda untuk ketersediaan, skalabilitas, konsistensi data, dan pemulihan bencana.

  • Rencana untuk pertumbuhan. Solusi mungkin mendukung kebutuhan saat ini untuk jumlah pengguna, volume transaksi, dan penyimpanan data, tetapi juga perlu menangani pertumbuhan tanpa perubahan arsitektur utama. Pertimbangkan juga bahwa model bisnis dan persyaratan bisnis Anda mungkin berubah dari waktu ke waktu. Sulit untuk mengembangkan solusi untuk kasus dan skenario penggunaan baru jika model layanan dan model data aplikasi terlalu kaku.

  • Kelola biaya. Dalam aplikasi lokal tradisional, Anda membayar di muka untuk perangkat keras sebagai pengeluaran modal. Dalam aplikasi cloud, Anda membayar sumber daya yang Anda konsumsi. Pastikan Anda memahami model harga layanan Anda. Total biaya mungkin termasuk penggunaan bandwidth jaringan, penyimpanan, alamat IP, dan konsumsi layanan.

    Pertimbangkan juga biaya operasi. Di cloud, Anda tidak perlu mengelola perangkat keras atau infrastruktur, tetapi Anda masih perlu mengelola DevOps aplikasi, respons insiden, dan pemulihan bencana.

Langkah berikutnya