Warum ein anwendungsspezifischer Ansatz für Anwendungsdienste wichtig ist

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Ich kann keine Gedanken lesen (meine Kinder würden da widersprechen, aber das tut hier nichts zur Sache), wohl aber die Antworten auf unsere Umfrage „State of Application Delivery“. Und wenn ich sie aus der Perspektive derjenigen betrachte, die sich selbst als App-Entwickler bezeichnen, ergibt sich ein äußerst interessantes Bild.

Entwicklern sind Geschwindigkeit, Sicherheit und Skalierbarkeit wichtig. Nicht unbedingt in dieser Reihenfolge, aber alle drei Aspekte sind für sie von Bedeutung. Und nicht nur das: Sie erkennen auch den Wert von Anwendungsdiensten, die ihnen dabei helfen, alle drei Ziele zu erreichen.

Konkret gesagt wünschen sich Entwickler nicht nur vage Anwendungsdienste zur „Beschleunigung“, sondern gezielte Dienste, die TCP-Optimierungen und Caching bieten. Außerdem wünschen sie sich eine Web Application Firewall sowie einen gewissen Lastausgleich.

Das Problem besteht darin, dass die meisten dieser Anwendungsdienste über ein gemeinsam genutztes Infrastrukturmodell bereitgestellt werden. Jede Anwendung erhält ihre eigene „virtuelle Repräsentation“, befindet sich physisch jedoch auf einer gemeinsam genutzten Software- oder Hardwarekomponente.

Dies kann zu echten Problemen führen – und ist zum Teil eine Ursache für die nach wie vor bestehenden Spannungen zwischen IT und Anwendungsentwicklung. Der gemeinsam genutzte Charakter dieser Systeme hat uns Änderungsfenster, Prüfungsgremien und Bereitstellungen am Samstagabend beschert (mit Pizza, um uns bei Laune zu halten) – Prozesse, die die Entwicklung verlangsamen und die Bereitstellung für alle Beteiligten zu einer frustrierenden Erfahrung machen.

Wir stellen keine monolithischen Monsteranwendungen mehr bereit. Selbst wenn wir nicht dem Mikroservices-Wahn verfallen sind und Anwendungen in Hunderte kleiner Dienste zerlegt haben, gibt es dennoch mehr Anwendungen, die häufiger bereitgestellt werden. Anwendungen, die in einwöchigen Sprints statt in jahrelangen Projekten entwickelt werden und deren Updates schneller und häufiger veröffentlicht werden müssen.

Das ist letztlich eher der Grund dafür, dass die (Public) Cloud so erfolgreich ist. Weil es meine App und meine Infrastruktur sind und ich nicht auf Bob, Alice oder John warten muss, bevor ich ein Update bereitstelle. Weil alles mir gehört und ich allein dafür verantwortlich bin, wenn etwas schiefgeht.

Derselbe Ansatz ist auch in der eigenen Infrastruktur möglich (und meines Erachtens vorzuziehen). Voraussetzung dafür ist, dass alle Komponenten der Bereitstellungskette einer Anwendung denselben anwendungsspezifischen Ansatz unterstützen, den die Cloud so attraktiv gemacht hat.

Im Grunde ist ein anwendungsspezifischer Ansatz zur Bereitstellung der benötigten Netzwerk- und Anwendungsdienste damit vergleichbar, der Anwendung ein eigenes Subnetz zuzuweisen – gewissermaßen ein VLAN für die Anwendungsbereitstellung. Dabei dreht sich alles um diese eine Anwendung, mit eigens dafür vorgesehenen Diensten.

Diese Art der Isolation ist nicht nur gut für Bereitstellungspläne, sondern auch für alle anderen. Fehler passieren, und wenn es dazu kommt, sollte der Schadensradius so weit wie möglich begrenzt werden. Eine separate Architektur für jede App sorgt dafür, dass die Auswirkungen eines Fehlers eng begrenzt bleiben. Das freut all jene, die „nur für den Fall der Fälle“ Rufbereitschaft haben, weil sie keinen Anruf erhalten. Ich kann jede Woche eine neue Version veröffentlichen und bereitstellen, ohne den Apps in die Quere zu kommen, die dies nur einmal im Monat tun. Meine App, meine Dienste, mein Bereitstellungsplan.

Eine anwendungsspezifische Architektur erleichtert außerdem die Behebung von Problemen, die in der Produktionsumgebung auftreten. Und das kommt häufig vor. Tatsächlich gaben 50 % der Entwickler in einer Atlassian-Umfrage aus dem Jahr 2017 an, dass nach der Veröffentlichung von Code Probleme in der Produktionsumgebung aufgetreten seien. Es ist ausgeschlossen, dass jemand anderes eine Änderung vorgenommen hat, die sich auf die Anwendung auswirken könnte. Sie können sich direkt den beteiligten Systemen zuwenden, anstatt wertvolle Zeit damit zu verbringen, herauszufinden, welche Systeme möglicherweise beteiligt sind.

Eine anwendungsspezifische Architektur eignet sich naturgemäß besser für die Cloud – ob öffentlich oder privat –, da das Modell genau davon ausgeht. Jede Anwendung verfügt über einen eigenen Satz von Anwendungsdiensten, um sie zu skalieren, zu beschleunigen und abzusichern.

Tatsächlich war eine anwendungsspezifische Architektur unvermeidlich. Das sage ich nicht zum ersten Mal. Die Anziehungskraft von Anwendungen ist zu stark, um sie zu ignorieren, und die zunehmend anwendungsspezifischen Sicherheitsmaßnahmen, die zum Schutz einer Anwendung erforderlich sind, führten dazu, dass sich früher oder später ein anwendungsspezifischer Ansatz durchsetzen musste.

Und das ist auch gut so, denn die von Entwicklern gewünschten Anwendungsdienste sind in den meisten Fällen anwendungsspezifisch. Was für eine Anwendung funktioniert, eignet sich nicht zwangsläufig für eine andere – und kann sich sogar nachteilig auswirken. Mit einem anwendungsbezogenen Architekturansatz für die Anwendungsbereitstellung können Sie nicht nur sicherstellen, dass Entwickler genau das erhalten, was sie benötigen, um Anwendungen zu skalieren, abzusichern und zu beschleunigen, sondern auch das Self-Service-Modell besser unterstützen, das sie von der Cloud erwarten – unabhängig davon, ob diese lokal oder extern betrieben wird.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

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