Diese Komponentenbildung der IT ist vergleichbar mit der Komponentenbildung der Anwendungen, deren Sicherung und Bereitstellung sie übernehmen soll. Schätzungsweise 80 bis 90 % der modernen Anwendungen bestehen aus Komponenten von Drittanbietern, von denen die meisten Open Source sind. Zu den Vorteilen zählen Geschwindigkeit, Reaktionsfähigkeit auf Veränderungen (Agilität) und geringere Kosten für die Erstellung der Software. Wenn schließlich schon jemand anderes den Code für ein Rad geschrieben hat, warum sollte man es dann neu erfinden?
Es gibt keine Schätzungen darüber, in welchem Ausmaß die IT heute komponentenbasiert sein wird. Die Antwort auf die Frage, in welchem Ausmaß sie in Zukunft komponentenbasiert sein wird, ist jedoch klar: Sehr.
Wir bauen keine eigenen Überwachungssysteme mehr. Wir adoptieren einen, wie Prometheus. Wir entwickeln keine eigenen Suchmaschinen; wir integrieren Elastic Search oder Lucerne. Wir müssen keine Formations- und Infrastruktur-Controller entwerfen und entwickeln; wir haben Helm und Terraform. Wir werden nicht mehr nach der Integration in Systeme gefragt, sondern nach unserer Unterstützung für Ökosysteme.
Wir erstellen Systeme aus einem Software-Stack, anstatt jede Komponente selbst zu entwickeln.
Dieses Denken auf Systemebene ist in der Entwicklung allgegenwärtig und hat allmählich tiefgreifende Auswirkungen auf die Art und Weise, wie sämtliche Software – kommerzielle und individuelle – entwickelt wird. Darüber hinaus hat es erhebliche Auswirkungen auf die Art und Weise, wie wir das Netzwerk strukturieren.
Vor einigen Jahren bemerkte ich, dass Microservices das Netzwerk aufspalteten . Dabei handelt es sich aus Gründen, die eng mit der DevOps-Denkweise verbunden sind, noch immer um einen laufenden Aufbruch. Das heißt, DevOps denkt eher in Komponentensystemen, insbesondere unter dem Einfluss der Cloud. Da DevOps immer weiter in den Bereich der traditionellen NetOps und des Betriebs vordringt, bringen sie ihre Denkweise mit. Das bedeutet Stapel statt Lösungen.
Diese Perspektive führt natürlich zur Einführung individueller Application , die besser zur Betriebs- und Denkweise von DevOps heute passen. Zweckgebundene und auf eine bestimmte Funktion ausgerichtete Application werden zum Zusammenstellen eines Datenpfad und nicht zum Erstellen eines solchen verwendet.
Das heißt, Lastausgleich ist Lastausgleich. Eingangskontrolle ist Eingangskontrolle. Und ein API-Gateway ist ein API-Gateway. Bei einer Vielzahl von Application erstellen (assemblieren) operative Handwerker einen Datenpfad , der vom Code (der App) bis zum Kunden (dem Client) reicht.
Dies lässt sich an den außerordentlichen Akzeptanzraten gezielter Dienste wie API-Gateway, Ingress Control und Bot-Abwehr erkennen, die wir im diesjährigen „State of Application Services“-Bericht gesehen haben.
Dieser Wandel ist nicht unbemerkt geblieben. So wie die digitale Transformation Unternehmen weiterhin dazu zwingt, sich neu zu definieren und in Dienste zu zerlegen, die durch APIs und Applications (digitale Fähigkeiten) repräsentiert werden, verändert sie auch dramatisch die Art und Weise, wie wir Application entwerfen, entwickeln und bereitstellen.
Datenpfade wurden schon immer auf IP-basiertem Routing aufgebaut. Leiten Sie diesen Datenverkehr hierhin und diesen Datenverkehrtyp dorthin, und wenn die Nutzlast etwas enthält, das mit X übereinstimmt, leiten Sie den Datenverkehr dorthin weiter. Es ist sehr netzwerkspezifisch und koppelt daher den Datenpfad eng an das Netzwerk, in dem es bereitgestellt wird.
Dies erschwert die Replikation in anderen Umgebungen, beispielsweise einer öffentlichen Cloud. Zwar können Sie Richtlinien wahrscheinlich wiederverwenden, Sie können jedoch nicht die Vorteile der Konfiguration nutzen, die den Datenpfad an das Netzwerk bindet.
Sowohl Container als auch die Cloud erzwingen grundsätzlich eine Verschiebung der Datenpfade im Stapel nach oben und eine Zusammenstellung dieser Pfade auf der Application aus den Application . Dies ist zwischen Umgebungen viel portabler, da Sie mit Metadaten wie Hostnamen oder Tags und Labels arbeiten, die nicht an das Netzwerk gebunden sind.
Letztendlich bedeutet das, dass wir von Konfigurationen zu Richtlinien übergehen müssen, die Datenpfade zusammenstellen können, ohne an IP-Adressen und Umgebungen gebunden zu sein.
Es besteht kein Zweifel, dass wir von Lösungen zu Stapeln und von manuellen Prozessen zu Pipelines übergehen. Während wir unsere digitalen Kapazitäten in allen Geschäftsbereichen und Betriebsabläufen erweitern, wird der Bedarf an Zusammenstellung und Kontrolle des Datenpfad immer weiter nach oben rücken und sich immer stärker auf die App-Dienste stützen, die ihn steuern.