Warum sollten sich DevOps-Experten um Per-App-Architekturen kümmern?
In dieser Frage steckt die implizite Schlussfolgerung, dass Sie dies tun sollten.
Seit Jahrzehnten stellen wir die Anwendungsdienste, die einen Großteil der Produktionspipeline ausmachen, auf gemeinsam genutzten Plattformen bereit. Anwendungsdienste wie Lastausgleich, Anwendungsleistungsdienste, WAF und föderierte Identität werden von NetOps auf gemeinsam genutzter Infrastruktur bereitgestellt, häufig in Form eines Application Delivery Controllers (ADC).
Doch Zeit und Nachfrage – sowie neue Anwendungsarchitekturen wie Microservices – erzwingen Änderungen in dieser Pipeline . Diese Änderungen sind sowohl für NetOps als auch für DevOps gut, da sie zu einem Modell übergehen, das sich stärker an Bereitstellungsplänen und Betriebspraktiken wie Infrastruktur als Code orientiert.
Einige Anwendungsdienste basieren nach wie vor fest auf der gemeinsam genutzten Infrastruktur. DNS. Abwehr volumetrischer DDoS-Angriffe. Netzwerk-Firewalls. Bei diesen Diensten handelt es sich ihrem Wesen nach um Unternehmensdienstleistungen . Das heißt, sie sind dazu konzipiert, das Unternehmen zu schützen, zu verteidigen und ihm zu dienen. Wenn diese Dienste ausfallen? Keine Produktivität oder Gewinn im gesamten Unternehmen.
Andere Anwendungsdienste sind jedoch stark anwendungsaffin; ihre Konfigurationen, APIs und Dienste sind häufig speziell auf die Unterstützung einer einzelnen Anwendung ausgelegt. Keine einzelne Architektur, sondern eine einzelne Anwendung.
Die Verantwortung für diese Dienste verlagert sich zunehmend in den Anwendungsbetrieb (DevOps) und bezieht die Entwickler mit ein, die die Anwendungen bereitstellen. Und obwohl ein gemeinsames Modell immer noch funktionieren kann (und dies häufig auch tut), um die notwendigen Bereitstellungs- und Sicherheitsanwendungsdienste bereitzustellen, ist aus mehreren Gründen für viele von ihnen ein Pro-App-Modell wünschenswert.
Erstens löst ein Pro-App-Modell Konflikte im Bereitstellungszeitplan elegant. Unternehmen stehen oft vor Einschränkungen durch geteilte Infrastruktur, insbesondere bei der Konfiguration und Bereitstellung der unterstützten Anwendungsdienste. Geteilte Infrastruktur bedeutet geteilte Ressourcen, was zwangsläufig zu Konfigurationskonflikten führt. Indem wir diese Möglichkeit ausschließen, können wir den Widerstand gegen häufigere oder außerplanmäßige Bereitstellungen verringern. Wenn ein Anwendungsdienst meiner Anwendung gewidmet und auf einer eigenen Plattform mit eigenen Ressourcen ausgeführt wird, lösen wir den Konflikt direkt. Meine App, mein Risiko.
Zweitens unterstützt ein Modell pro Anwendung aufkommende Automatisierungsbestrebungen, die Methoden wie Infrastruktur als Code umsetzen. Wenn du Ressourcen und Plattform einer einzigen Anwendung widmest, enthält die Konfiguration ausschließlich diese Anwendung. So kannst du Unveränderlichkeit sicherstellen und das Risiko von Entropie vermeiden. Ich bin der Überzeugung (wie ich kürzlich betont habe), dass du eine unveränderliche Infrastruktur nur mit einer Architektur pro Anwendung richtig umsetzen kannst. Dieser Ansatz erlaubt die Einbindung in eine kontinuierliche Bereitstellungspipeline, die über die Anwendungsinfrastruktur bis ins „Netzwerk“ reicht. Damit verschiebst du die Verantwortung für Konfiguration und laufende Verwaltung von NetOps zu DevOps. Das Gute daran: Mit dieser größeren Verantwortung bekommst du auch mehr Kontrolle, denn DevOps wird zum „Eigentümer“ des Anwendungsdienstes und kann eigenständig Upgrades, Patches und Neu-Bereitstellungen nach eigenen Vorgaben und Zeitplänen durchführen.
Und schließlich ist ein Pro-App-Modell unmittelbar portabler. Ohne an eine gemeinsame Plattform gebunden zu sein und sich fast ausschließlich auf Bereitstellungsartefakte (Konfigurationen und Vorlagen) zu verlassen, kann der Großteil der Produktionspipeline mit weitaus weniger Reibung und Aufwand von Cloud zu Cloud und von vor Ort zu extern migriert werden. Diese Freiheit bietet Unternehmen die Möglichkeit, die beste Cloud und den besten Standort für die jeweilige Anwendung auszuwählen, ohne durch die mit der Migration verbundenen Kosten eingeschränkt zu werden.
DevOps kann erheblich davon profitieren, die Einführung einer Pro-App-Architektur für Anwendungsdienste sowohl vor Ort als auch in der öffentlichen Cloud zu fördern. Da NetOps unter dem Druck steht, für mehr Kontrolle und Transparenz in anderen Betriebsbereichen zu sorgen, wäre jetzt ein guter Zeitpunkt, sich Pizza und Bier zu schnappen und mit Ihren NetOps-Kollegen über die Umstellung auf eine anwendungszentrierte Pro-App-Architektur der nächsten Generation zu sprechen.