Erstellen gemäß den Geschäftsanforderungen

  • Artikel

Jede Entwurfsentscheidung muss durch eine geschäftliche Anforderung gerechtfertigt sein. Dieses Entwurfsprinzip mag offensichtlich erscheinen, ist aber beim Entwerfen von Azure-Anwendungen von entscheidender Bedeutung.

Muss Ihre Anwendung Millionen oder nur ein paar Tausend Benutzer*innen unterstützen? Gibt es Datenverkehrsspitzen? Oder ist die Workload gleichmäßig? Welche Anwendungsausfallstufe ist akzeptabel? Letztendlich fördern geschäftsspezifische Anforderungen diese Entwurfsüberlegungen.

Die folgenden Empfehlungen helfen Ihnen beim Entwerfen und Erstellen von Lösungen für die Einhaltung der geschäftlichen Anforderungen:

  • Definieren Sie Geschäftsziele wie die Werte für Recovery Time Objective (RTO), Recovery Point Objective (RPO) und die maximal tolerierbare Ausfalldauer (Maximum Tolerable Outage, MTO). Diese Werte sollten als Grundlage für Entscheidungen dienen, die in Bezug auf die Architektur getroffen werden.

    Nehmen wir an, Ihr Unternehmen muss sehr niedrige RTO- und RPO-Werte erzielen. Sie können eine zonenredundante Architektur verwenden, um diese Anforderungen zu erfüllen. Wenn Ihr Unternehmen einen höheren RTO- und RPO-Wert tolerieren kann, könnte das Hinzufügen von Redundanz zusätzliche Kosten ohne geschäftlichen Nutzen verursachen.

  • Berücksichtigen Sie die Ausfallrisiken, die Sie entschärfen müssen. Befolgen Sie die Hinweise im Leitfaden zum Entwurf mit Blick auf Selbstreparatur, um Ihre Lösung so zu gestalten, dass sie gegen viele gängige Fehlerzustände resistent ist. Überlegen Sie, ob Sie auch weniger wahrscheinliche Situationen berücksichtigen müssen, z. B. eine Naturkatastrophe in einem geografischen Gebiet, die sich auf alle Verfügbarkeitszonen in der Region auswirken könnte. Die Entschärfung dieser ungewöhnlichen Risiken ist in der Regel teurer und mit erheblichen Abstrichen verbunden, deshalb sollten Sie die Risikotoleranz Ihres Unternehmens genau kennen.

  • Dokumentieren Sie Vereinbarungen zum Servicelevel (SLAs) und Servicelevelziele (SLOs), einschließlich Verfügbarkeits- und Leistungsmetriken. Beispielsweise kann eine vorgeschlagene Lösung eine Verfügbarkeit von 99,95 Prozent erreichen. Es ist eine Entscheidung des Unternehmens, ob diese SLO die SLA erfüllt.

  • Modellieren Sie Anwendungen für Ihre Geschäftsdomäne. Analysieren Sie die Geschäftsanforderungen, und verwenden Sie diese Anforderungen, um die Lösung zu modellieren. Erwägen Sie die Nutzung eines Entwurfsansatzes, der am Geschäftsbereich ausgerichtet ist (Domain-Driven Design, DDD), um Domänenmodelle zu erstellen, die Ihre Geschäftsprozesse und Anwendungsfälle widerspiegeln.

  • Definieren Sie funktionale und nicht funktionale Anforderungen. Funktionale Anforderungen bestimmen, ob eine Anwendung die Aufgabe ausführt. Nicht funktionale Anforderungen legen fest, wie gut die Anwendung ausgeführt wird. Stellen Sie sicher, dass Sie nicht funktionale Anforderungen wie Skalierbarkeit, Verfügbarkeit und Latenz verstehen. Diese Anforderungen haben Einfluss auf Entwurfsentscheidungen und die Technologieauswahl.

  • Teilen Sie Workloads auf. „Workload“ steht in diesem Kontext für eine einzelne Funktion oder Computingaufgabe, die von anderen Aufgaben logisch getrennt werden kann. Für Workloads gelten unter Umständen unterschiedliche Anforderungen in Bezug auf die Verfügbarkeit, Skalierbarkeit, Datenkonsistenz und Notfallwiederherstellung.

  • Planen Sie im Hinblick auf Wachstum. Eine Lösung kann die aktuellen Anforderungen für die Anzahl von Benutzer*innen, Transaktionsvolumen und Datenspeicher unterstützen, aber sie muss auch Wachstum ohne umfassende Änderungen an der Architektur ermöglichen. Berücksichtigen Sie auch, dass sich Ihr Geschäftsmodell und die geschäftlichen Anforderungen im Laufe der Zeit ändern können. Wenn das Dienstmodell und die Datenmodelle einer Anwendung zu starr gestaltet sind, ist es schwierig, die Anwendung für neue Anwendungsfälle und Szenarios weiterzuentwickeln.

  • Verwalten Sie die Kosten. Bei einer herkömmlichen lokalen Anwendung zahlen Sie vorab für Hardware (Investitionsaufwand). Bei einer Cloudanwendung zahlen Sie für die Ressourcen, die Sie nutzen. Stellen Sie sicher, dass Sie das Preismodell Ihrer Dienste verstehen. Die Gesamtkosten umfassen unter Umständen die Kosten für die genutzte Netzwerkbandbreite, den Speicher, die IP-Adressen und den Dienstverbrauch.

    Berücksichtigen Sie auch die Betriebskosten. In der Cloud müssen Sie zwar keine Hardware oder Infrastruktur verwalten, dafür aber Anwendungs-DevOps, die Reaktionen auf Incidents und die Notfallwiederherstellung.

Nächste Schritte