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 werden Konflikte im Bereitstellungsplan durch ein Pro-App-Modell auf elegante Weise gelöst . Unternehmensorganisationen werden hinsichtlich der Konfiguration und Bereitstellung der unterstützten Anwendungsdienste häufig durch Konflikte bei der gemeinsamen Infrastruktur eingeschränkt. Eine gemeinsam genutzte Infrastruktur bedeutet auch die Nutzung gemeinsam genutzter Ressourcen, wodurch zwangsläufig die Gefahr von Konfigurationskonflikten besteht. Durch die Beseitigung dieser Möglichkeit kann der Widerstand gegen häufigere oder außerplanmäßige Bereitstellungen gemindert werden. Wenn ein Anwendungsdienst meiner Anwendung gewidmet ist und auf seiner eigenen Plattform mit seinen eigenen Ressourcen ausgeführt wird, ist der Konflikt schließlich sauber gelöst. Meine App, mein Risiko.
Zweitens unterstützt ein Pro-App-Modell neue Automatisierungsbemühungen, die die praktische Umsetzung von Methoden wie „Infrastruktur als Code“ umfassen. Indem Ressourcen und Plattform einer einzelnen Anwendung zugewiesen werden, umfasst die Konfiguration nur diese Anwendung. Unveränderlichkeit kann erzwungen und das Risiko der Entropie vermieden werden. Ich würde sogar behaupten ( und habe das vor Kurzem auch getan ), dass eine unveränderliche Infrastruktur ohne eine Architektur pro App nicht wirklich möglich ist. Dieser Ansatz ermöglicht die Einbindung in eine kontinuierliche Bereitstellungspipeline, die über die Anwendungsinfrastruktur hinaus bis in „das Netzwerk“ reicht. Die Bereitstellung dieser Funktion bedeutet, die Verantwortung für die Konfiguration und das laufende Management von NetOps auf DevOps zu verlagern. Die gute Nachricht ist, dass mit dieser größeren Verantwortung auch mehr Kontrolle einhergeht, da DevOps zum „Eigentümer“ des Anwendungsdienstes wird und die Möglichkeit hat, nach seinen eigenen Bedingungen und Zeitplänen Upgrades, Patches und Neubereitstellungen durchzufü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.