Bangun untuk kebutuhan bisnis
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 memerlukan 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 menambahkan 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 memperhitungkan situasi yang lebih kecil kemungkinannya, seperti area geografis yang mengalami bencana alam utama 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 nonfungsi. 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.
Menguraikan beban kerja menjadi fungsionalitas diskrit. Beban kerja adalah kumpulan sumber daya aplikasi, data, dan infrastruktur pendukung yang berfungsi bersama untuk mencapai hasil bisnis yang ditentukan. Beban kerja terdiri dari komponen dan juga prosedur pengembangan dan operasional. Beban kerja sering kali dapat diurai menjadi fungsionalitas diskrit yang selaras dengan alur pengguna, data, atau sistem dan alur tersebut dapat dikaitkan dengan nilai dan memiliki persyaratan non-fungsional.
Alur pengguna, data, atau sistem yang berbeda sering memiliki persyaratan yang berbeda untuk ketersediaan, skalabilitas, konsistensi data, dan pemulihan bencana. Sistem yang dirancang dengan baik memungkinkan Anda mengoptimalkan desain per alur. Untuk mencapai hal ini, Anda harus memecah beban kerja menjadi komponen yang dapat disesuaikan. Strategi umum melibatkan kategorisasi komponen berdasarkan nilainya. Misalnya, komponen Tingkat 1 sangat penting dan harus dioptimalkan tanpa memperhatikan pengeluaran. Komponen Tingkat 2 signifikan tetapi dapat dikurangi sementara dengan konsekuensi minimal. Komponen Tingkat 3 bersifat opsional; menjaga mereka hemat biaya dan mudah dikelola. Menetapkan pemahaman bersama tentang nilai alur membantu semua orang merancang dan mengembangkan beban kerja menjaga keseimbangan antara biaya dan persyaratan non-fungsi lainnya.
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.
Menyelaraskan model dan biaya bisnis. Umur panjang sistem dipengaruhi oleh seberapa efektif biayanya selaras dengan model bisnis. Sebagai arsitek, Anda harus mempertimbangkan pendorong nilai dan menggunakan wawasan tersebut untuk memandu keputusan Anda. Anda harus mengidentifikasi dimensi di mana solusi Anda akan memberikan nilai (seperti profitabilitas), lalu memastikan arsitektur mengikuti aliran nilai. Dengan cara ini, arsitektur Anda dapat memaksimalkan nilai investasi, menghasilkan return on investment (ROI) yang selaras dengan ekspektasi bisnis.
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.