Kontrolle versus Ausführung im Datenpfad
Früher bildeten die App-Dienste, die Apps bereitstellten, einen geraden und schmalen Datenpfad. Alle Apps nutzten grundsätzlich die gleichen Dienste über das gleiche Netzwerk. Diese architektonische Einfachheit machte es leicht, einen einzigen Kontrollpunkt mit einem einzigen Ausführungspunkt zu kombinieren. Dies wiederum führte zur Entstehung des Application Delivery Controllers (ADC). Dadurch kann der App-Verkehr an einem Ort gestaltet, gesteuert, skaliert und gesichert werden. Durch die Kombination von Kontrolle und Ausführung steht dem operativen Geschäft ein strategischer Punkt im Datenpfad zur Verfügung, an dem alle möglichen Richtlinien durchgesetzt und ausgeführt werden können.
Der Aufstieg der Cloud und die fortschreitende Nutzung von Containern haben diesen Datenpfad unterbrochen. Wir verfügen jetzt über mehrere und manchmal dynamische Datenpfade, über die Apps bereitgestellt werden. Ein einziger strategischer Kontroll- und Ausführungspunkt ist oft weder operativ noch architektonisch realisierbar.
Dies bedeutet jedoch nicht, dass eine einheitliche Steuerung nicht mehr möglich ist, selbst wenn die Ausführung an verschiedene App-Dienste delegiert wird.
Es ist wichtig, möglichst wenige Kontrollpunkte zu haben, über die App-Dienste im Datenpfad bedient (bereitgestellt, konfiguriert und verwaltet) werden können. Die Förderung der Verwendung mehrerer Kontrollpunkte führt zwangsläufig zu widersprüchlichen Richtlinien, die für App-Benutzer Probleme verursachen. Die Fehlerbehebung wird komplexer und zeitaufwändiger, was den Ärger und die Angst der Benutzer steigert. Leider ist die zunehmende Verbreitung der Tools eine häufige Beschwerde unter denjenigen, die die Erweiterung eines bereits vielfältigen App-Portfolios um Cloud-native Architekturen verwalten.
Aus unserer Studie „State of App Services“ 2020 wissen wir, dass die Ops in erster Linie für den Betrieb der App-Dienste verantwortlich sind, sie sind jedoch nicht allein. DevOps, NetOps und SecOps sind alle in den Betrieb von App-Diensten sowohl vor Ort als auch in der öffentlichen Cloud investiert.
Was sie oft unterscheidet, sind die spezifischen Funktionen der App-Dienste, für die sie verantwortlich sind.
DevOps sind weitgehend für Zuverlässigkeit, Leistung und app-spezifische Richtlinien verantwortlich. NetOps hingegen konzentrieren sich, ihrem Namen entsprechend, stärker auf Netzwerkattribute. Es sind häufig NetOps, die App-Dienste aus einer Infrastrukturperspektive verwalten. SecOps befasst sich natürlich mit der Sicherheit im Zusammenhang mit der Infrastruktur und der App.
Eine mögliche Aufgabenteilung bedeutet jedoch nicht, dass die Künstler für die Ausübung ihrer Künste auch unterschiedliche Werkzeuge verwenden sollten. Heute gibt es zahlreiche Belege dafür, dass die CI/CD- und Continuous-Deployment-Pipelines auf unterschiedlichen Tool-Sets basieren. Jenkins und Git-Repos dominieren die CI/CD-Pipeline, während Ansible und Python die Tools der Wahl für die kontinuierliche Bereitstellung sind. Ein Großteil der Entscheidung besteht darin, den Werkzeugsatz an die Arbeitsweise der verschiedenen Beteiligten anzupassen, die täglich mit den Werkzeugen interagieren müssen.
Sollte also ein einzelnes Tool entstehen, um die Richtlinienkonsistenz zu verbessern, die Fehlerbehebung zu beschleunigen und die Komplexität und Kosten einer unkontrollierten Tool-Ausbreitung zu eliminieren, muss es über die richtigen Schnittstellen verfügen, um sicherzustellen, dass alle wichtigen Bestandteile der App-Dienste im Datenpfad das Toolset zur Erfüllung ihrer jeweiligen Aufgaben nutzen können.
Dies ist wichtig für die allgemeine Sicherheit und Zuverlässigkeit der App-Dienste selbst. Durch die Aufrechterhaltung eines einheitlichen Kontrollpunkts können Unternehmen sicher sein, dass Änderungen verfolgt und verstanden werden. Obwohl es sich nicht um eine unveränderliche Implementierung handelt, werden durch die Zentralisierung der Kontrolle in einem einzigen Tool mehrere Schritte in diese Richtung unternommen.
Ein Beispiel für ein solches Tool ist NGINX Controller .
Sie werden feststellen, dass wie vorgesehen eine Vielzahl von App-Diensten (Analyse, API-Verwaltung, Sicherheit und Service Mesh) zentral gesteuert werden können, auch wenn Betrieb und Ausführung verteilt erfolgen.
In jeder Umgebung ist es wichtig, die Anzahl der Tools zu reduzieren, die mit Datenpfadkomponenten (App-Diensten) interagieren dürfen, um potenzielle Probleme aufgrund von Fehlkonfigurationen oder widersprüchlichen Konfigurationen zu verringern. In einer modernen Multi-Cloud-Umgebung ist eine zentrale Steuerung aufgrund der Komplexität, die durch das oft exponentielle Wachstum der App-Dienste, aus denen der Datenpfad besteht, entsteht, noch wichtiger.
Überzeugender für die Budgetverantwortlichen ist die Senkung der Betriebskosten, die mit der Eliminierung sich wiederholender, manueller Tätigkeiten durch Automatisierung einhergeht.
Eine Möglichkeit hierzu besteht darin, die Steuerung in einem einzigen Tool zu vereinheitlichen.