Erstellen gemäß den Geschäftsanforderungen
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 in separate Funktionalitäten auf. Eine Workload ist eine Sammlung von Anwendungsressourcen, Daten und unterstützenden Infrastrukturen, die zusammenarbeiten, um definierte Geschäftsergebnisse zu erzielen. Eine Workload setzt sich aus Komponenten sowie aus Entwicklungs- und Betriebsverfahren zusammen. Workloads lassen sich häufig in einzelne Funktionalitäten aufteilen, die an Benutzer-, Daten- oder Systemflüsse angepasst sind. Diese Flüsse können einem Wert zugeordnet werden und können mit nicht-funktionellen Anforderungen verbunden sein.
Für unterschiedliche Benutzer-, Daten- oder Systemflüsse gelten unterschiedliche Anforderungen in Bezug auf die Verfügbarkeit, Skalierbarkeit, Datenkonsistenz und Notfallwiederherstellung. Gut gestaltete Systeme ermöglichen es Ihnen, für jeden Fluss ein optimales Design zu erhalten. Hierzu müssen Sie Workloads in anpassbare Komponenten aufteilen. Eine typische Strategie besteht in der Kategorisierung von Komponenten basierend auf ihrem Wert. Komponenten der Stufe 1 sind beispielsweise entscheidend und sollten unabhängig vom Kostenaufwand optimiert werden. Komponenten der Stufe 2 sind wichtig, können jedoch vorübergehend mit minimalen Folgen reduziert werden. Komponenten der Stufe 3 sind optional und sollten kostengünstig und einfach zu verwalten sein. Ein gemeinsames Verständnis des Werts der Flüsse hilft allen, die eine Workload entwerfen und weiterentwickeln, ein Gleichgewicht zwischen den Kosten und anderen nicht funktionsbezogenen Anforderungen zu gewährleisten.
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.
Passen Sie das Geschäftsmodell an die Kosten an. Die Beständigkeit eines Systems hängt davon ab, wie gut die Kosten an das Geschäftsmodell angepasst sind. Als Architekt*in müssen Sie die Wertfaktoren berücksichtigen und dieses Wissen für Ihre Entscheidungsfindung nutzen. Sie sollten die Dimension identifizieren, in der Ihre Lösung Wert generieren wird (z. B. die Rentabilität), und anschließend sicherstellen, dass die Architektur dem Wertfluss folgt. Auf diese Weise kann Ihre Architektur den Mehrwert für Ihre Investitionen maximieren und einen ROI generieren, der auf die geschäftlichen Anforderungen abgestimmt ist.
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.