Die Infrastruktur über den Prototyp hinaus bestimmen

Beginnen Sie mit dem generierten System

Betrachten Sie eine fiktive Prototypenplattform. Sie erstellt einen Webcontainer, eine verwaltete PostgreSQL-Datenbank und eine öffentliche URL. Der Ablauf funktioniert mit Beispieldatensätzen korrekt. Das ist ein nützliches Ergebnis: Menschen können die Funktion beurteilen, bevor sie eine größere Implementierung finanzieren.

Nun möchte das Unternehmen vertrauliche Verträge speichern und seinen Identitätsanbieter für Mitarbeiter nutzen. Das erforderliche System hat sich geändert. Ein erfolgreiches Container-Deployment belegt weder Autorisierung noch freigegebene Datenverarbeitung, Wiederherstellbarkeit oder Dienstverantwortung.

Entwicklungsplattformen bieten unterschiedliche Funktionen. Untersuchen Sie den tatsächlichen Dienst und seine Konfiguration. Nehmen Sie weder bei allen Prototypenwerkzeugen dieselben Grenzen an noch, dass ein bekannter Cloudname die Unternehmensrichtlinie erfüllt.

Stellen Sie sieben Fragen zur Produktion

Die Antworten können vorhandene Unternehmensdienste nutzen. Sie müssen nicht für jede Anwendung ein neues Identitätssystem oder eine Monitoring-Plattform aufbauen. Binden Sie freigegebene Funktionen an und dokumentieren Sie verbleibende Lücken.

AWS Well-Architected betrachtet Betrieb, Sicherheit, Zuverlässigkeit, Leistung, Kosten und Nachhaltigkeit gemeinsam. Das erinnert daran, dass ein funktionierendes Deployment nur ein Teil einer Architekturbewertung ist. Lesen Sie das Framework.

Definieren Sie Grenzen zwischen Umgebungen

Ermitteln Sie Entwicklungs-, Test- und Produktionsressourcen. Legen Sie fest, welche Identitäten diese Grenzen überschreiten dürfen. Kopieren Sie Produktionsdatensätze nicht ohne freigegebenes Verarbeitungsverfahren in eine bequeme Vorschauumgebung.

Prüfen Sie ausgehende Verbindungen ebenso wie eingehenden Zugriff. Eine private Datenbank kann über die Anwendung trotzdem Daten an einen öffentlichen Logging-Dienst liefern. Die Modellaufrufe des Coding-Agenten sind ein weiterer, gesondert zu bewertender Datenfluss.

Halten Sie fest, wer Cloudkonto, DNS, Zertifikat, Verschlüsselungsschlüssel und Abrechnungsbeziehung verantwortet. Ein Projekt, das vom persönlichen Konto eines ausscheidenden Mitarbeiters abhängt, hat ein Verantwortungsproblem, auch wenn der Anwendungscode verfügbar ist.

Prüfen Sie die Aufteilung der Verantwortung

Ein Anbieter einer verwalteten Datenbank kann den zugrunde liegenden Dienst betreiben. Ihre Organisation kontrolliert dabei möglicherweise Nutzer, Datenzugriff, Schemaänderungen und Aufbewahrungseinstellungen. Die genaue Aufteilung hängt von Dienst und Vertrag ab. Fragen Sie ausdrücklich danach.

Führen Sie für die Vertragsanwendung eine fiktive Wiederherstellungsübung durch. Messen Sie die tatsächliche Wiederherstellungszeit und ermitteln Sie möglichen Datenverlust. Vergleichen Sie das Ergebnis mit der Geschäftsanforderung. Ein Kontrollkästchen „Backups aktiviert“ ist nicht derselbe Nachweis.

Testen Sie auch das Offboarding. Entfernen Sie einen fiktiven Mitarbeiter aus der Identitätsquelle und prüfen Sie die vorgesehene Zugriffsänderung. Berücksichtigen Sie im Entwurf aktive Sitzungen, Administratorrollen und Automatisierungsidentitäten.

Verbinden Sie Infrastruktur und Liefersystem

Infrastrukturdefinitionen, Umgebungskonfiguration, Pipelines und Anwendungscode brauchen abgestimmte Änderungen. Ein Agent sollte auf Basis der tatsächlichen Zielumgebung planen. Sonst kann er ein Deployment erzeugen, das Netzwerk-, Identitäts- oder Verantwortungsanforderungen widerspricht.

Hier treffen Platform Engineering und Software Factory aufeinander. Die Plattform liefert unterstützte Funktionen und Grenzen. Das Liefersystem muss sie nutzen, Nachweise erzeugen und eine klare Betriebsübergabe erhalten. Lesen Sie weiter über Platform Engineering.