Warum die Application eher wie eine Fabrik (und weniger wie ein Handwerksbetrieb) aussehen sollte

Damals …

In der längst vergangenen Zeit vor der Cloud sah die Application ganz anders aus als heute. Der Grund hierfür liegt darin, dass sich nichts schneller bewegen konnte als die Geschwindigkeit, mit der die IT die Server beschaffen und bereitstellen konnte, auf denen die Applications liefen. Die Planung neuer Applications oder größerer Application dauerte viele Monate oder Jahre. Gleichzeitig wurden Applications immer komplexer und es entstand eine immer länger werdende Liste gegenseitiger Abhängigkeiten, die schwer zu verfolgen und zu verwalten waren. Es traten Sicherheitsbedrohungen auf, die ganze Systeme tagelang lahmlegen oder zu karriereschädigenden Datenlecks führen konnten. Auch ohne externe Übeltäter stieg zusammen mit dem Komplexitätsindex weiterhin das Risiko einer Änderung, die das Netzwerk (und die unterstützten Applications ) in die Knie zwingt.

Um diese Risiken zu beherrschen und die Sicherheit und Zuverlässigkeit aller ihnen anvertrauten Application zu gewährleisten, entwickelten die Netzwerk- und Sicherheitsteams Prozesse und Richtlinien, die stark auf manueller Überprüfung basierten und im Allgemeinen handgefertigte Richtlinien beinhalteten, die auf die individuellen Anforderungen jeder einzelnen Application zugeschnitten waren. Diese Verfahren waren zwar umständlich, stellten jedoch nicht unbedingt Engpässe dar. Sie haben den Beschaffungsprozess oft beschleunigt.

Aus heiterem Himmel …

Dann kam die Cloud. Plötzlich erwiesen sich Bereitstellungsprozesse als Bremse für ein sonst so schnelles System. Etwa zur gleichen Zeit erleichterten GitHub und andere Social-Coding-Plattformen den Entwicklern die Zusammenarbeit am Code, sei es innerhalb desselben Teams oder bei Open-Source-Projekten. Durch neue Application konnte die Effizienz der Entwickler deutlich gesteigert werden, da die Wahrscheinlichkeit verringert wurde, dass die Arbeit in einem Teil der Application mit anderen Teilen in Konflikt gerät – eine der Hauptursachen für Mühe, Nacharbeit und Verzögerungen. Microservices- und Service-Mesh-Architekturen verringern die Abhängigkeiten zwischen Teilen der Application selbst, während Container und Serverless die Abhängigkeiten von der zugrunde liegenden Infrastruktur verringern – wodurch einzelne Entwickler und Application in ihrem eigenen Tempo vorgehen können. Entwickler können Applications jetzt innerhalb von Minuten statt Monaten bereitstellen. Anfangs waren solche Bereitstellungen auf Entwicklungs- und Testprojekte beschränkt, doch die Nachfrage nach schnellerem Zugriff auf Produktionssysteme stieg schnell.

digitale Transformation: Ein Werk in Arbeit

Netzwerkadministratoren und Sicherheitsingenieure hatten Mühe, mit der Entwicklung Schritt zu halten, was teilweise daran lag, dass sich ihre Berufserfahrung – anders als bei Entwicklern – eher auf die Wahrung der Geschäftssicherheit als auf die Optimierung von Arbeitsabläufen konzentrierte. Viele der Kernkonzepte der sogenannten DevOps-Bewegung waren für Entwickler bereits eine Selbstverständlichkeit: die Automatisierung von Prozessen, die Rationalisierung von Systemen, die Reduzierung von Abhängigkeiten zwischen Systemen und die Nutzung wiederverwendbarer Prozesse und Codes, wo immer möglich. Netzwerkadministratoren und Sicherheitsingenieure wurden dagegen als Handwerker ausgebildet. Aufgrund der kritischen Natur ihrer Arbeit war es erforderlich, dass jede Application manuell überprüft, durch Änderungsüberprüfungsgremien gepflegt und durch handgefertigte Richtlinien verwaltet wurde, die als Reaktion auf sich ändernde Bedingungen (manuell) aktualisiert werden konnten.

Die gute Nachricht ist, dass die Netzwerk- und Sicherheitsteams zwar zu Beginn des Rennens einen großen Rückstand auf die Entwickler hatten, was das Verständnis automatisierte Bereitstellung angeht, aber sie holen langsam auf .

Die Application : Anwendung einer systemischen Denkweise auf die Application

Man kann sich den Übergang gut vorstellen, indem man sich eine Application vorstellt. Anstelle von handgefertigten Richtlinien und manuellen Überprüfungsprozessen müssen Netzwerk- und Sicherheitsexperten wiederverwendbare Richtlinien definieren und diese dann an die Entwickler weitergeben, damit diese sie im Rahmen einer automatisierte Bereitstellung mit ihren Applications bereitstellen können.

Zugegeben, das ist leichter gesagt als getan. So wie es bei der Umstellung von handgefertigten Waren auf fabrikgefertigte Produkte nicht einfach darum ging, schweres Gerät zu kaufen und Arbeitern neue Aufgaben zuzuweisen, geht es bei der Umstellung auf einen systemischen Ansatz ebenso sehr um Denkweise und Kultur wie um Werkzeuge und Prozesse. Anstatt dass Änderungsprüfungsgremien und Sicherheitsteams jeden möglichen Sicherheitsbedrohungsvektor und jedes Leistungsrisiko mühsam untersuchen, hält ein gut konzipiertes automatisiertes Application Fehlerdomänen klein, um die Auswirkungen zu minimieren, und integriert effektive Feedbackschleifen, um eine frühzeitige Erkennung und Reaktion zu ermöglichen. Bei Entscheidungen zu Werkzeugen und Pipelines sollte die Freiheit des Entwicklers mit dem Effizienzwert konsistenter Dienste in Einklang gebracht werden. Das ideale System bietet Entwicklern maximale Freiheit bei Entscheidungen bezüglich der Werkzeuge, die sich auf die Funktionsentwicklung auswirken, stellt aber gleichzeitig einen konsistenten Satz an Multi-Cloud-fähigen Infrastruktur- und Sicherheitsdiensten bereit. Durch die Einbindung konsistenter Dienste in den Kern der Application werden technische Schulden reduziert und die Betriebs- und Compliance-Effizienz verbessert. Dadurch haben die Entwickler wiederum mehr Freiraum, sich auf die Bereitstellung von mehr Innovationswert für das Unternehmen zu konzentrieren.

(Sehen Sie die vollständige Infografik zur F5 Application Factory, indem Sie auf das Bild unten klicken.)