In dieser Frage schwingt bereits die Schlussfolgerung mit, dass Sie es tun sollten.
Seit Jahrzehnten stellen wir die Anwendungsdienste, die einen Großteil der Produktionspipeline ausmachen, auf gemeinsam genutzten Plattformen bereit. Anwendungsdienste wie Lastverteilung, Dienste zur Optimierung der Anwendungsleistung, WAF und föderierte Identitäten werden von NetOps auf einer gemeinsam genutzten Infrastruktur bereitgestellt, häufig in Form eines Application Delivery Controllers (ADC).
Doch der Lauf der Zeit und die steigenden Anforderungen – zusammen mit neuen Anwendungsarchitekturen wie Microservices – erzwingen Veränderungen in dieser Pipeline. Diese Veränderungen sind sowohl für NetOps als auch für DevOps von Vorteil, da sie zu einem Modell führen, das besser auf Bereitstellungspläne und Betriebspraktiken wie Infrastructure as Code abgestimmt ist.
Einige Anwendungsdienste sind nach wie vor fest in gemeinsam genutzten Infrastrukturen verankert. DNS. Schutz vor volumetrischen DDoS-Angriffen. Netzwerk-Firewalls. Diese Dienste sind ihrem Wesen nach unternehmensweite Dienste. Das heißt, sie sollen das Unternehmen schützen, verteidigen und unterstützen. Fallen diese Dienste aus, kommen Produktivität und Geschäftsertrag im gesamten Unternehmen zum Erliegen.
Andere Anwendungsdienste hingegen sind stark an eine bestimmte Anwendung gebunden; ihre Konfigurationen, APIs und Dienste werden häufig gezielt für die Unterstützung einer einzelnen Anwendung eingerichtet. Nicht für eine einzelne Architektur, sondern für eine einzelne Anwendung.
Die Verantwortung für diese Dienste verlagert sich zunehmend nach links in Richtung Anwendungsbetrieb (DevOps), wobei die Entwickler, die Anwendungen bereitstellen, stärker einbezogen werden. Und obwohl ein gemeinsam genutztes Modell für die Bereitstellung der erforderlichen Dienste zur Anwendungsauslieferung und -sicherheit weiterhin funktionieren kann (und dies häufig auch tut), ist für viele dieser Dienste aus mehreren Gründen ein anwendungsspezifisches Modell wünschenswert.
Erstens löst ein anwendungsspezifisches Modell Konflikte bei den Bereitstellungszeitplänen auf elegante Weise. Unternehmen sind bei der Konfiguration und Bereitstellung der von ihnen unterstützten Anwendungsdienste häufig durch Konflikte aufgrund gemeinsam genutzter Infrastruktur eingeschränkt. Gemeinsam genutzte Infrastruktur bedeutet gemeinsam genutzte Ressourcen, wodurch zwangsläufig die Gefahr von Konfigurationskonflikten steigt. Wird diese Möglichkeit ausgeschlossen, lassen sich Vorbehalte gegen häufigere oder außerplanmäßige Bereitstellungen abbauen. Denn wenn ein Anwendungsdienst ausschließlich für meine Anwendung vorgesehen ist und auf einer eigenen Plattform mit eigenen Ressourcen ausgeführt wird, ist der Konflikt elegant gelöst. Meine Anwendung, mein Risiko.
Zweitens unterstützt ein anwendungsspezifisches Modell neue Automatisierungsansätze, bei denen Methoden wie Infrastructure as Code in die Praxis umgesetzt werden. Indem Ressourcen und Plattform einer einzigen Anwendung zugewiesen werden, umfasst die Konfiguration ausschließlich diese Anwendung. Unveränderlichkeit lässt sich durchsetzen und das Risiko einer schleichenden Abweichung vom Sollzustand vermeiden. Ich würde sogar behaupten (und habe dies kürzlich auch getan), dass sich eine unveränderliche Infrastruktur nicht richtig ohne eine anwendungsspezifische Architektur umsetzen lässt. Dieser Ansatz ermöglicht die Einbindung in eine Continuous-Deployment-Pipeline, die über die Anwendungsinfrastruktur hinaus bis in „das Netzwerk“ reicht. Um diese Möglichkeit bereitzustellen, muss die Verantwortung für die Konfiguration und die laufende Verwaltung von NetOps auf DevOps verlagert werden. Die gute Nachricht ist, dass mit dieser größeren Verantwortung auch mehr Kontrolle einhergeht: DevOps wird zum „Eigentümer“ des Anwendungsdienstes und kann Upgrades, Patches und erneute Bereitstellungen nach eigenen Vorgaben und Zeitplänen durchführen.
Und schließlich ist ein anwendungsspezifisches Modell von vornherein portabler. Da es nicht an eine gemeinsam genutzte Plattform gebunden ist und fast ausschließlich auf Bereitstellungsartefakten (Konfigurationen und Vorlagen) basiert, lässt sich der Großteil der Produktionspipeline mit deutlich weniger Aufwand und Reibungsverlusten von einer Cloud in eine andere oder von einer lokalen Umgebung in die Cloud migrieren. Diese Freiheit ermöglicht es Unternehmen, die beste Cloud und den besten Standort für die jeweilige Anwendung auszuwählen, ohne durch migrationsbedingte Kosten eingeschränkt zu sein.
DevOps kann erheblich davon profitieren, die Einführung einer anwendungsbezogenen Architektur für Anwendungsdienste zu fördern – sowohl im eigenen Rechenzentrum als auch in der Public Cloud. Da NetOps zunehmend unter Druck steht, anderen Betriebsbereichen mehr Kontrolle und Transparenz zu ermöglichen, wäre jetzt ein guter Zeitpunkt, sich bei Pizza und Bier mit den NetOps-Kollegen darüber auszutauschen, wie sich eine anwendungszentrierte Per-App-Architektur der nächsten Generation unterstützen lässt.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...