Warum ein Pro-App-Ansatz für Anwendungsdienste wichtig ist
Ich kann keine Gedanken lesen (meine Kinder würden da anderer Meinung sein, aber das ist nebensächlich), aber ich kann die Antworten auf unsere Umfrage zum Stand der Anwendungsbereitstellung lesen. Und wenn ich sie aus der Sicht von selbsternannten App-Entwicklern lese, ergibt sich für mich ein sehr interessantes Bild.
Entwicklern ist Geschwindigkeit wichtig. Und Sicherheit. Und Maßstab. Nicht unbedingt in dieser Reihenfolge, aber alle drei sind ihnen wichtig. Es ist ihnen nicht nur wichtig, sondern sie erkennen auch den Wert der Anwendungsservices, die ihnen dabei helfen, alle drei Ziele zu erreichen.
Das heißt: Entwickler wollen nicht nur vage Anwendungsdienste zur „Beschleunigung“, sondern spezifische Dienste, die TCP-Optimierungen und Caching bereitstellen. Sie möchten zusätzlich eine Web Application Firewall und eine Lastverteilung.
Das Problem besteht darin, dass die meisten dieser Anwendungsdienste in einem gemeinsam genutzten Infrastrukturmodell bereitgestellt werden. Jede Anwendung erhält ihre eigene „virtuelle Darstellung“, befindet sich jedoch physisch auf einem gemeinsam genutzten Stück Software oder Hardware.
Dies kann zu echten Problemen führen – und ist teilweise eine Quelle der anhaltenden Reibereien zwischen IT und App-Entwicklung. Es ist diese gemeinsame Natur der Systeme, die uns Änderungsfenster und Prüfgremien und Bereitstellungen am Samstagabend (mit Pizza, um uns bei Laune zu halten) beschert hat – die Prozesse, die die Entwicklung verlangsamen und die Bereitstellung zu einer frustrierenden Erfahrung für alle Beteiligten machen.
Wir setzen keine monolithischen Monster-Apps mehr ein. Auch wenn wir nicht überstürzt auf Microservices setzen und Apps in Hunderte kleiner Dienste zerlegen, verfügen wir dennoch über mehr Apps, die häufiger bereitgestellt werden. Apps, die in einwöchigen Sprints statt in jahrelangen Projekten entwickelt werden und schneller und häufiger Updates benötigen.
Dies ist letztendlich der Hauptgrund für den Erfolg der (öffentlichen) Cloud. Weil es meine App und meine Infrastruktur ist und ich nicht auf Bob oder Alice oder John warten muss, bevor ich ein Update pushe. Denn es gehört alles mir, und wenn etwas schiefgeht, bin ich ganz für mich verantwortlich.
Derselbe Ansatz ist auch vor Ort möglich (und meiner Meinung nach auch vorzuziehen). Was notwendig ist, ist, dass alle Teile und Komponenten, aus denen die Lieferkette einer Anwendung besteht, denselben Pro-App-Ansatz unterstützen, den die Cloud wünschenswert gemacht hat.
Ein Pro-App-Ansatz zur Bereitstellung der benötigten Netzwerk- und Anwendungsdienste ist im Grunde genommen so, als würde man der Anwendung ein Subnetz widmen – ein VLAN für die App-Bereitstellung, wenn man so will. Es dreht sich alles um diese eine App mit dedizierten Diensten.
Diese Art der Isolierung ist nicht nur für Bereitstellungspläne gut, sondern auch für alle anderen. Fehler können vorkommen und in diesem Fall möchten Sie den Explosionsradius so weit wie möglich einschränken. Bei Architekturen pro App sind die Auswirkungen von Fehlern stark eingeschränkt, sodass alle Leute, die „für alle Fälle“ auf Abruf bereitstehen, froh sind, weil sie den Anruf nicht erhalten haben. Ich kann jede Woche veröffentlichen und bereitstellen, ohne mit den Apps in Konflikt zu geraten, die einmal im Monat veröffentlichen und bereitstellen. Meine App, meine Dienste, mein Bereitstellungsplan.
Eine Pro-App-Architektur erleichtert außerdem die Behebung von Problemen, die während der Produktion auftreten. Und das tun sie oft. Tatsächlich berichteten in einer Atlassian-Umfrage aus dem Jahr 2017 50 % der Entwickler von Problemen in der Produktion nach der Veröffentlichung des Codes. Es besteht keine Chance, dass jemand anderes eine Änderung vorgenommen hat, die Auswirkungen auf die Anwendung haben könnte. Sie können direkt zu den beteiligten Systemen gelangen, anstatt wertvolle Zeit damit zu verbringen, herauszufinden, welche Systeme beteiligt sein könnten .
Eine Pro-App-Architektur passt natürlich besser zur Cloud – egal ob öffentlich oder privat –, da dies die vom Modell ausgehende Annahme ist. Jede App verfügt über einen dedizierten Satz an Anwendungsdiensten, um sie zu skalieren, zu beschleunigen und zu sichern.
Tatsächlich war eine Architektur pro App unvermeidlich. Das ist nicht das erste Mal, dass ich das sage . Die Bedeutung von Anwendungen ist zu groß, um sie zu ignorieren. Und da für die Sicherheit einer Anwendung zunehmend anwendungsspezifische Sicherheit erforderlich ist, musste früher oder später ein Ansatz für einzelne Anwendungen eingeführt werden.
Und das ist gut so, denn die von Entwicklern gewünschten Anwendungsdienste sind meistens anwendungsspezifisch. Was für den einen funktioniert, muss nicht unbedingt auch für den anderen funktionieren – und kann sogar negativ sein. Durch die Einführung eines Architekturansatzes pro App für die Anwendungsbereitstellung können Sie sicherstellen, dass Entwickler nicht nur das bekommen, was sie wollen und brauchen, um Apps zu skalieren, zu sichern und zu beschleunigen, sondern Sie können auch das Self-Service-Modell besser unterstützen, das sie von der Cloud erwarten, egal ob vor Ort oder außerhalb.