Die Standards für Software Delivery wie auch operative Abläufe waren im vergangenen Jahrzehnt einem immer dynamischeren Momentum unterworfen. In der Folge müssen IT-Teams nun auch ein viel ausgedehnteres Infrastruktur-Feld bestellen, dessen Größe wie auch Komplexität weiter zunehmen.
Veränderung. Einst massiver Belastungspunkt für IT-Infrastrukturen, nun die Grundlage zur Ausbildung von Wettbewerbsvorteilen.
DevOps für schnellere, häufigere Infrastruktur- und Anwendungs-Deployments. Modernisierung von Anwendungen, um mehr Speed, Skalierbarkeit und Performance zu erreichen. Cloud-Migration. Microservice-Einführung. Kubernetes zur Container-Orchestrierung.
Veränderung. Schnell und konstant. Und überall in der Blutbahn
Ihrer Infrastruktur.
Mehr Änderungen an Software, mehr Konfigurationen, mehr Alerts. Mehr...von allem. Ebenso auch mehr Druck. Mehr Druck, Probleme rascher zu dentifizieren und zu beheben. Mehr Druck, die Stabilität und Verlässlichkeit von Produktionssystemen zu garantieren.
Die Komplexität, die sich im Namen von Speed und Skalierbarkeit entwickelt hat, gilt es, im Monitoring mit dem Shift-Left-Prinzip zu adressieren. Denn in einer Vielzahl der Fälle ist bei Systemanpassungen vor dem Rollout in die Produktion noch so einiges nicht komplett zu antizipieren. Daher unabdingbar: Observability.
Mit dieser grundlegenden Änderung in Sachen Methodik bleiben auch noch so dynamische Systeme stets transparent.
Nur kommen aber je nach Team und Stack-Komponenten häufig ganz unterschiedliche Monitoring- Tools zum Einsatz. Eines für Entwickler, eines für IT-Ops, eines für Business Manager, eines für Logs, eines für Metrics, eines für Traces, eines für On-Prem-Tech, wieder ein anderes für die Cloud.
Und jedes einzelne dieser Tools ist sicher eine hervorragende Wahl für das jeweilige Team.
In der Praxis bedeutet diese Tech- Streuung nun aber auch für jedes Team mehr Alerts, mehr Telemetrie und mehr kritische – aber leider auch fragmentierte – Ops-Daten.
Fragmentierte Tooling-Landschaften bedeuten auch fragmentierte Observability. Und die nützt keinem.
Jedes Tool liefert nur einen Teil des Gesamtbilds, während dieses selbst jedoch weiter in flux und dynamisch bleibt. Die Grenzen zwischen den einzelnen Stack-Komponenten verschwimmen leicht. Die Ursache für einen Anwendungs-Ausfall in Code oder Infrastruktur ausfindig zu machen, bevor es zu einem Dominoeffekt kommt, ist eine Sache. Aus ihr wird jedoch eine Herausforderung völlig neuen Ausmaßes, wenn die punktuelle Natur der Einzellösungen für Ihre Systemkomponenten nun auch noch zusätzlich Zeit und Geld kostet.
Ihre Daten hängen nun plötzlich in Silos fest, von den Technologien zudem noch mit ihrem eigenen, proprietären Vokabular erfasst. Ihre Teams sprechen somit alles, nur keine gemeinsame Sprache, sehr zum Leidwesen Ihrer MTTD und MTTR.
Direkt finanziell quantifizierbarer Natur sind diese Effekte nur zu Beginn. Sie entfalten schnell zusätzliche Tücken an anderen Stellen im Unternehmen. So verbringen IT und Operations bald zu viel Zeit mit der Fehlerbehebung. Für Innovation bleibt immer weniger übrig. Gemeinsame Zielausrichtung und Zusammenarbeit für Ihre Teams werden immer schwerer. Die Moral Ihrer Mitarbeiter leidet.
Ihr Unternehmen bekommt die Folgen dieses Tooling- Tohuwabohu zu spüren.
In diesem Leitfaden betrachten wir, wie sich fragmentierte Tooling-Landschaften auf Ihr Unternehmen auswirken können. Genauso aber betrachten wir die positive Seite der Medaille – nämlich alle Chancen, die sich für Ihr Team auftun, wenn Sie diese Herausforderungen angehen.