İşletme gereksinimleri için oluşturun

Her tasarım kararının iş gereksinimleri açısından haklı bir gerekçesi olmalıdır

Bu tasarım ilkesi belirgin görünebilir, ancak bir çözüm tasarlarken göz önünde bulundurmanız önemlidir. Milyonlarca mı yoksa birkaç bin kullanıcınız mı olacak? Bir saatlik uygulama kesintisi kabul edilebilir mi? Trafikte veya öngörülebilir bir iş yükünde büyük artışlarıyla bekliyor musunuz? Sonuçta her tasarım kararının iş gereksinimleri açısından haklı bir gerekçesi olmalıdır.

Öneriler

Kurtarma süresi hedefi (RTO), kurtarma noktası hedefi (RPO) ve en fazla kesinti toleransı (MTO) dahil olmak üzere iş hedeflerini belirleyin. Bu sayılar mimari hakkında kararlarda dikkate alınmalıdır. Örneğin, düşük RTO elde etmek için ikincil bir bölgeye otomatik yük devretme uygulayabilirsiniz. Ancak çözümünüz daha yüksek bir RTO toleransına sahipse bu artıklık düzeyi gereksiz olabilir.

Kullanılabilirlik ve performans ölçümleri dahil olmak üzere hizmet düzeyi sözleşmelerini (SLA) ve hizmet düzeyi hedeflerini (SLO) belgeleyin. %99,95 kullanılabilirlik sunan bir çözüm oluşturabilirsiniz. Bu yeterli midir? Yanıt bir iş kararıdır.

Uygulamayı iş çerçevesinde modelleyin. İş gereksinimlerini çözümleyerek başlayın. Uygulamanın modelini oluşturmak için bu gereksinimleri kullanın. İş süreçlerine ve kullanım senaryolarına uygun etki alanı modelleri oluşturmak için etki alanı odaklı tasarım (DDD) yaklaşımı kullanmayı değerlendirin.

Hem işlevsel, hem de işlevsel olmayan gereksinimleri belirleyin. İşlevsel gereksinimler, uygulamanın doğru şeyi yapıp yapmadığını değerlendirmeye olanak tanır. İşlevsel olmayan gereksinimler, uygulamanın bu şeyleri iyi yapıp yapmadığını değerlendirmeyi sağlar. Özellikle, ölçeklenebilirlik, kullanılabilirlik ve gecikme süresi için gereksinimlerinizi anladığınızdan emin olun. Bu gereksinimler tasarım kararlarını ve teknoloji seçimini etkiler.

İş yüküne göre parçalara ayırın. Burada kullanıldığı şekliyle "iş yükü" terimi, diğer görevlerden mantıksal olarak ayrılabilen, ayrık bir özellik veya bilgi işlem görevi anlamına gelmektedir. Farklı iş yüklerinin kullanılabilirlik, ölçeklenebilirlik, veri tutarlılığı ve olağanüstü durum kurtarma konularında farklı gereksinimleri olabilir.

Büyümeyi planlayın. Bir çözüm kullanıcı sayısı, işlem hacmi, veri depolama ve benzeri konularda geçerli gereksinimlerinizi karşılayabilir. Ancak, sağlam bir uygulama, büyük mimari değişiklikler olmadan büyümeye olanak verir. Bkz. Ölçeğin genişletilebileceği şekilde tasarlama ve Bölümleyerek sınırları aşma. Ayrıca iş modelinizin ve iş gereksinimlerinizin büyük olasılıkla zamanla değişeceğini göz önünde bulundurun. Bir uygulamanın hizmet modeli ve veri modelleri sabitse, yeni kullanım örnekleri ve senaryoları için uygulamayı geliştirmek zorlaşır. Bkz. Gelişmeye açık olarak tasarlama.

Maliyetleri yönetin. Geleneksel bir şirket içi uygulamada, bir sermaye harcaması olarak donanım için önden ödeme yaparsınız. Bir bulut uygulamasında tükettiğiniz kaynaklar için ödeme yaparsınız. Tükettiğiniz hizmetler için kullanılan fiyatlandırma modeli anladığınızdan emin olun. Toplam maliyet, ağ bant genişliği kullanımını, depolama, IP adresleri, hizmet tüketimi ve diğer etkenleri içerecektir. Daha fazla bilgi için bkz. Azure fiyatlandırması. Ayrıca işlem maliyetlerinizi göz önünde bulundurun. Bulutta, donanım veya diğer altyapıları yönetmeniz gerekmez, ancak hala DevOps, olay yanıtlama, olağanüstü durum kurtarma ve benzerleri de dahil olmak üzere uygulamalarınızı yönetmeniz gerekir.