Performance Matters Most

So kann eine langsame Verbindung, beispielsweise zu einem Bezahldienstleister im Checkout-Prozess, die gesamte User Experience nachhaltig beeinträchtigen und den beabsichtigten Kauf verhindern. Der „schuldige“ Dienst, in Form eines API-Calls oder Funktionsaufrufs ist nicht immer auf einen Blick zu identifizieren. Dies führt zu zwei Fragen. Wie kam es überhaupt zu dieser Situation und wie kann diese Herausforderung zuverlässig gelöst werden? Alle Unternehmen, die eine Antwort auf die zweite Frage finden, dürfen sich über einen nicht unerheblichen Wettbewerbsvorteil freuen.

Um die erste Frage zu beantworten, lohnt sich ein kurzer Blicker zurück: Die letzten 10 Jahre in der Software-Entwicklung zeigen, dass aktuell Java- und PHP-Monolithen aufgebrochen werden und für die interne Kommunikation zwischen den Komponenten auf einen API-First-Ansatz gewechselt wird. Was früher noch auf einem Server oder gar einem Mainframe betrieben werden konnte, muss heute modularer aufgesetzt werden. Die Gründe liegen zum einen in der besseren Skalierbarkeit und zum anderen in der Möglichkeit mit verteilten Teams an derselben Applikation, nur eben an unterschiedlichen Teilen, arbeiten zu können. Wenn man nach den technischen Gründen sucht und sich fragt, warum diese Maßnahmen nicht schon früher durchgeführt wurden, sind wohl extrem zuverlässige und gezähmte Linux-Derivate sowie eine allgemeine API Maturity¹ zu nennen. Einfach übersetzt kann man sagen, dass moderne APIs endlich aus der Pubertät gekommen sind und dieser modulare Ansatz nun zuverlässig betrieben werden kann.

Zusätzlich wird in modernen Software-Architekturen nicht mehr jede Funktionalität selbst entwickelt, sondern oft auf externe Dienste wie bspw. Datenanbieter für Kartenmaterial oder den Versand von Nachrichten zurückgegriffen. Ein anschauliches Beispiel ist, wie bereits in der Einleitung angedeutet, ein Bezahldienstleister im Stil von Stripe². Dieser Anbieter nimmt uns die lästige Verarbeitung von Kreditkartendaten ab, ohne dass wir auch nur in die Gefahr laufen, die besonders kritischen Bezahldaten inklusive des magischen CVC/CVV in den Datenbanken unserer Anwendungen zwischenspeichern zu müssen. So können wir den stark regulierten Finanzbereich mit all seinen Bestimmungen und Anforderungen wie PCI-DSS³, 3DS-2.0, PSD 2 etc. elegant umgehen.

Das Gleiche gilt für per Content Delivery Network (CDN) extern eingebettete JavaScript-Bibliotheken, Schriftarten von Google oder Adobe sowie Video Iframes in den Geschmacksrichtungen YouTube, Vimeo und Co. In einer Applikation kommen schon so eine Vielzahl von Abhängigkeiten zusammen, die aber meist noch mit einem Blick in die Konsole des Browsers und einem gewissen technischen Sachverstand nachvollzogen werden können.

Den Trend nicht mehr jede Funktion selbst zu entwickeln, sondern auf bereits vorgefertigte Bibliotheken zurückzugreifen, gibt es in der Entwicklung schon länger. In allen modernen Programmiersprachen wird auf das Konzept von Libraries oder Packages zurückgegriffen, die mit einer Code-Zeile geladen und dann einfach mit einem Funktionsaufruf innerhalb der Anwendungen verwendet werden können. Um ein Gefühl für das Ausmaß zu bekommen lohnt ein Blick in die öffentlichen Datenbanken zu exakt diesen Paketen für Python, Ruby, JavaScript und Go — allesamt beliebte und verbreitete Sprachen mit starker Präsenz am Markt⁴.

Eine parallele Entwicklung ist ebenfalls in der Infrastruktur zu beobachten. Alle Cloud-Anbieter geben als größten Vorteil nicht ihre quasi grenzenlosen Kapazitäten an, sondern die Möglichkeit alle zur Verfügung gestellten Dienste per API aufzurufen. Die einzelnen Dienste können dadurch automatisiert miteinander verbunden werden und sich am Ende zu einem gewissen Maß selbst steuern und konfigurieren. Marktvorteile schaffen sich Cloud-Anbieter nicht nur durch Masse (verfügbare Speicher- und Rechenkapazitäten), sondern auch durch Eleganz (die Vielfalt abrufbarer Dienster per API).

Um nun Public-Cloud-Anbieter mit ihren Schnittstellen und Private Cloud Konstrukte auf OpenShift oder VMware Basis aus Sicht der Entwicklung zu homogenisieren, zeichnet sich die Container-Verwaltung Kubernetes als eine der möglichen Antworten ab⁵. Und auch Kubernetes selbst steuert intern alles über API-Aufrufe und sorgt so dafür, dass selbst-skalierende Docker Container immer so gestartet werden können, dass die in Kubernetes-Clustern gestarteten Applikationen performant laufen.

Schon dieser oberflächliche Abriss wird jedem Nicht-Techniker bei der Frage, wie das nun alles wirklich zusammenarbeitet, die Schweißperlen auf die Stirn treiben. Es ist leicht nachzuvollziehen, warum in einer modernen Software-Architektur oft nur der Lead Developer oder Architekt den wirklichen Überblick besitzt. Denn in den Anwendungen und Apps, die wir jeden Tag verwenden, sind eine Vielzahl von Libraries und Komponenten verbaut, die selbst den beteiligten Entwicklern nicht mehr bis in das letzte Detail bekannt sind. Wenn sich die Finanzwelt über undurchsichtige Exceldokumente „beschwert“⁶, zucken Entwickler nur müde mit den Achseln. Eine kleine Veränderung bei NPM/Javascript Packages kann auch die Großen der IT-Welt wie Facebook in die bedrohliche Situation bringen keine Updates mehr einspielen zu können⁷. Im konkreten Fall sorgte eine Markenrechtsverletzung in Form des Paketnamens einer Minifunktion dafür, dass sich ein eingeschwungenes aber komplexes System weder builden noch deployen ließ.

Auf das Beste zu hoffen genügt nicht (mehr)

Wenn es nun im Fehlerfall oder bei Performanceproblemen zur Schuldfrage kommt, wartet nicht nur lästiges Fingerpointing zwischen Entwicklern und anderen IT-Teams, sondern meist ein langwieriger Prozess, der deutlich werden lässt, dass technisch oft auf das Beste gehofft wurde. Technische Teams wie bei Google, die über das Wissen verfügen, wo bzw. wie die Daten auf der Festplatte gespeichert werden und somit Fehler durch alle Layer hindurch nachvollziehen können⁸, sind extrem rar und am Markt schwer bis gar nicht mehr zu finden.

Sofern noch striktes Abteilungsdenken das Unternehmen bestimmt, beginnt ein Prozess, der oft mit Mean Time to Innocence bezeichnet wird: Wie schnell kann beispielsweise das Entwicklungsteam beweisen, dass der Code fehlerfrei ist und das Problem im Netzwerk liegen müsste? Modernere Unternehmen haben bereits erkannt, dass dieser Weg nicht sonderlich lösungsorientiert ist und sich als Ziel KPI Mean Time to Resolution gegeben. Es geht also um die Zeit, die gemeinsam über die Teams hinweg benötigt wird, um das Problem zu lösen.

Wie wird aber nun im Fehlerfall konkret das Problem gelöst? Jede Abteilung hat eine andere Auswahl an Tools, die nun aufgerufen und ausgelesen werden. Die Entwickler haben Repositories, in denen der Code verwaltet wird, und Pipelines, die oft in .yaml-Files gespeichert sind. Netzwerkteams besitzen ihre Monitoring-Lösungen und am Ende bleibt für die Verantwortlichen immer das Auslesen von Logs auf den unterschiedlichen Ebenen: in der Applikation selbst, im Container, in der Virtualisierung, in der Cloud oder zu guter Letzt direkt auf der Hardware. Viel hängt also von der Visibilität der Infrastruktur ab. Zusätzliche Herausforderungen bringen die externen API-Dienstleister. Erst ein mal muss man wissen, dass diese ebenfalls betroffen sein können. Und selbst wenn man dies weiß, werden diese dann doch verschachtelt im Code aufgerufen und sind vielleicht nur dem Entwicklungsteam oder dem Product Owner bekannt.

Wie kann diese Herausforderung gelöst werden? (Noch) bessere Entwickler, DevOps/Site Reliability Ingenieure und Architekten, saubererer Code, bessere Dokumentationen? Klingt alles gut und richtig. Eine vollständige Abkehr von Mark Zuckerbergs frühem internen Facebook-Motto „move fast and break things“⁹? Die Aktualisierung und mit dem Zusatz „move fast with stable infrastructure¹⁰“ veredelt? Eher unwahrscheinlich, da es einfach nicht der gelebte Modus Operandi in Tech¹¹ ist. Innovation bedingt in gewisser Hinsicht Geschwindigkeit und eine hohe Schnelligkeit in der Entwicklung bedeutet meist nicht beste Qualität — oder als Konsquenz einen extrem hohen Preis. Ein klassisches Projektmanagement Dreieck¹², in dem wir uns im Ergebnis meist doch für schnellere Entwicklungszyklen entscheiden, vor allem wenn es um nicht wirklich kritische Infrastruktur geht.

Eine Antwort auf dieses Dilemma könnte APM sein: Applications Performance Monitoring oder Applications Performance Management, hier streiten sich noch die Marktforschungsgelehrten¹³ und Hersteller. Beide Begriffe werden unter der Bezeichnung Digital Experience Management (DEM) zusammengefasst, zumindest darüber herrscht inzwischen Einigkeit in der Industrie.

Mit Hilfe von APM-Lösungen können Daten aus System- und Applikationslogs gesammelt und nach ein wenig Konfigurationsarbeit ansehnlich in schönen Dashboards aufbereitet werden. Aus den zuvor beschriebenen vielen Logins in unterschiedlichen Systemen mit verschiedenen Teams wird eine einzige Softwarelösung — so zumindest das Produktversprechen. Im Zentrum des künftigen IT-Betriebs steht also ein aggregierendes Tool, welches mit Machine-Learning-Algorithmen Unterschiede zum Normalzustand frühzeitig erkennen kann und mit einem ebenfalls zu konfigurierenden Alarmierungssystem umgehend alle Beteiligten bzw. Verantwortlichen informiert.

Diese Art von Produkt scheint somit nicht nur die Antwort auf die modernen technischen Herausforderungen zu sein, sondern bringt Visibilität in Form von Reports und Dashboards für Entscheider und Manager. In Zukunft soll die Frage „Wer weiß wo der Fehler liegen könnte?“ mit einem Tool beantwortet werden. Genau diese Aussicht treibt IT- und Business-Verantwortlichen Freudentränen in die Augen und rechtfertigt am Ende auch die hohen Investitionskosten in diese Lösungen. Denn die Preise für APM, egal von welchem Hersteller, sind nicht unbedingt günstig.

Ein Blick in den Markt

Da sich ein Kundenbedarf im Bereich der Applikationsüberwachung immer stärker erkennen lässt, ist es wenig verwunderlich, dass bereits jetzt Player um Marktanteile kämpfen. In diesem Kontext verstärkte sich Cisco 2017 mit AppDynamics, in der Industrie auch mit AppD abgekürzt, für nicht ganz günstige 3,7 MRD USD¹⁴. Ob nicht ein Kauf bzw. der Versuch Controlling Interest an den öffentlichen Märkten zu gewinnen doch günstiger gewesen wäre, da eine IPO-Evaluierung mit weniger als 2 MRD USD¹⁵ im Raum stand, weiß nur die Investorenglaskugel und hoffentlich das Akquisitionsteam von Cisco.

Ein weiterer Anbieter im Rennen um die APM-Krone und den Spot rechts oben im Gartner Magic Quadrant ist Dynatrace. Gestartet als Softwarehaus dynaTrace in Österreich und nach mehreren Firmenzusammenschlüssen bei Compuware als Monitoring-Abteilung gelandet, erkannte die Private Equity Firma Thoma Bravo bereits 2014 das Potential in diesem Markt¹⁶. Erst nahm der Käufer Compuware von der Börse und separierte anschließend den APM Part aus dem übernommenen Softwarehaus. Dynatrace wurde wieder eine eigenständige Firma mit klarem Produktfokus. Nach dieser Public Market On-Off-Beziehung entschied man sich im Ergebnis für „on“ und brachte Dynatrace Anfang August (2019) wieder an die Börse¹⁷. Es wird die Zeit zeigen, ob APM besser als Einzelfirma oder als Produkt von einem großen Unternehmen wie Cisco angeboten werden sollte. Für beide Varianten lassen sich aktuell gute Gründe finden.

Neben Dynatrace und AppDynamics findet man die Lösungen von New Relic ebenfalls in relevanter Verbreitung und mit entsprechender Installationsbasis im Markt. Auch hier setzt man sich mit dem Thema Performance von Applikationen bereits seit einiger Zeit — rund 10 Jahren — auseinander und hat ebenfalls den Schritt an die öffentlichen Märkte gewagt¹⁸. Im Ergebnis ist APM trotz geringer Popularität, auch unter IT-Spezialisten, für bestimmte Anwendungen bereits seit einiger Zeit wichtiger Bestandteil des Stacks. Gleichzeitig braut sich der perfekte Sturm zusammen, dass die Adaptionsraten in Zukunft rasant steigen werden.

Wenn man die Demos der drei genannten Anbieter und ihre Dashboards direkt nebeneinander sieht, zum Beispiel auf Marketing Events von Public Cloud Providern, wird schnell klar, dass die User Experience aller Lösungen sehr ähnlich ist: Auf der Startseite nach dem Login werden auf einer Übersichtsseite der Status der einzelnen Systeme zusammengefasst. Im Ergebnis soll so viel wie möglich grün/aktiv sein und so der Fokus auf die Probleme gelegt werden. Von diesem Dashboards besteht dann die die Möglichkeit in die einzelnen Komponenten, ggf. bis auf die entsprechende Codezeile vorzudringen, und so die Ursache des Fehlers zu finden.

Gleichzeitig sei gesagt, dass der zu Grunde liegende Architekturansatz der Anbieter unterschiedlich ist und nur AppDynamics und Dynatrace auf einen zentral zu installierenden Agenten setzen. Dieser Agent sammelt auf Systemebene die Daten und schickt diese an die Auswertungsplattform zur Analyse und Aufbereitung. Die eigentliche Plattform kann in beiden Fällen sowohl als SaaS-Lösungen bezogen wie auch On-Premise betrieben werden. Bei vielen automatisierten Deployments gibt es somit einen technischen Nachteil auf Seiten von New Relic, die den Agenten zur Überwachung in den jeweiligen Applikationen bzw. Komponenten benötigen und nicht auf einen zentralen Agenten setzen.

APM-Anbieter treibt aber nicht nur das Überwachen der fertigen Applikationen an. Denn mit immer schnelleren Releases wird bereits der Entstehungsprozess der Software — der sogenannte und durch Pipelines automatisierte Build Prozess — quasi zum Teil der Lösung. Bereits dieser Schritt müsste in den Next-Generation-Monitoring-Lösungen mitüberwacht werden. So versucht Dynatrace seinen DevOps Pivot mit dem Kubernetes Framework Keptn¹⁹. Als Ziel soll ein Betriebsteam durch die Etablierung einer NoOps-Kultur vollständig überflüssig werden. Innerhalb dieses technischen Frameworks werden neben der Definition der Anwendungen auch die Pipelines und die Prozesse rund um die Software berücksichtigt. Als Beispiele sind hier automatisierte Tests, also wann soll die Software wirklich aktualisiert werden, und Informationsketten, die bei Problemen angestoßen werden sollen, zu nennen.

Und auch Cisco hat eine ähnliche Vision. Vielleicht waren die Kalifornier mit ihrem Zukauf von Cliqrs Cloud Center im Jahr 2016²⁰ eine Spur too early. Die Vision von einer Multi-Cloud-Welt war zu diesem Zeitpunkt noch nicht so ausgereift, wie die Erwartungen der DevOps-Teams aktuell im Jahr 2019 sind. Aber genau das frühzeitige Erkennen, dass ein Rennen zu einem Private/Public Cloud Abstraktionslayer und die zentrale Steuerung von Deployment-Prozessen in Verbindung mit einer Monitoring-Lösung die Antwort auf alle Probleme sein müsste, zeigt wo die Reise bezüglich Features und Funktionalität von APM-Lösungen wohl hingehen wird.

Ich habe in diesem Artikel vor allem die verschiedenen Ursachen betrachtet, die uns in die Hände von APM treiben. Hingegen wird auf den Sales-Veranstaltungen der Hersteller vor allem der Pitch der digitalen Transformation strapaziert. Grundlegend stimme ich der Aussage der Hersteller zu, diese hilft allerdings Novizen in diesem Gebiet wenig, da man schnell das Gefühl bekommt ein Buzzword mit einem weiteren Buzzword zu beantworten.

Die Erkenntnis, die hinter all diesen Floskeln wartet, ist, dass Einblicke, Kontext und Transparenz in die Technik, und zwar durch die gesamte Organisation und über Teams hinweg, ein wichtiger Erfolgsfaktor in der Zukunft sein wird. Denn durch die digitale Transformation werden immer mehr Prozesse in und durch individuelle Software abgebildet. Allerdings gibt das renommierte IT-Forschungsinstitut IDC die Prognose ab, dass die Maturität dieser Transformation im Jahr 2020 „nur“ 55% betragen wird²¹. Und so wird auch deutlich: Es gibt noch Luft für Anpassungen des Modus wie mit den technischen Herausforderungen auf diesem Weg umgegangen werden soll.

Zusätzlich spekuliert Gartner²², dass sich bis 2021 nur 20% der Unternehmen mit dem Thema APM auseinander gesetzt haben. Es wartet also trotz der erheblichen Produktreife von knapp 10 Jahren ein erheblicher Blue Ocean Markt auf APM-Anbieter, Partner bzw. Integratoren und Berater.

Gleichzeitig sieht man bereits eine starke Traktion und somit APM-Umsätze bei allen Unternehmen, die sich im Bereich der Finanzdienstleistungen bewegen. Für mich ist der Grund klar: Der aktuelle Wettbewerbsvorteil in Form von besseren Informationen und der Zugang zu selbigen muss gesichert werden. Eine Industrie ohne physisches Produkt muss auf der Zeitachse dem Markt voraus sein, um seine Leistungen auch zukünftig verkaufen zu können. Dies erklärt, warum Banken — vielleicht nicht unbedingt die deutschen Banken — schon immer in Technologien und Märkten unterwegs sind, wenn die produzierenden Unternehmen diese gerade als das Neue für sich entdecken.

Mehr als nur ein Blick in die technische Infrastruktur

Aber Performance-Daten reichen nicht für ein holistisches Bild der digitalen User Experience aus. Erst die Verbindung mit Metriken wie der Conversion Rate, Klicks sowie Ein- und Ausstiege in Websites und Applikationen, bisher Expertendomäne von Google und anderen Marketing-Tracklösungen wie HotJar oder etracker, lassen die Datensätze über diese User erst vollständig werden. Um bei dem eingangs dargestellten Beispiel herauszufinden, was tatsächlich die Ursache für den Nicht-Kauf gewesen ist, reicht die Analyse der technischen Logs und Systemevents nicht aus. Vielmehr müssen auch die konkreten Interaktionen des Users betrachtet werden. Auch diese Daten können APM-Lösungen mit Funktionen wie User Session Replays, die alle Klicks des Nutzers als Video anzeigen, darstellen.

Die Verbindung all dieser Datensätze wird in einer nahen Zukunft den entscheidenden Wettbewerbsvorteil bringen und später eine Notwendigkeit sein, um wettbewerbsfähig zu bleiben. Eine sinnvolle Korrelation der Datenpunkte ist jedoch nur möglich, wenn die Daten möglichst einfach an einem zentralen Ort, einer Single Spot of Truth, aufgerufen werden können.

APM-Lösungen sind nicht nur aus Nutzersicht für bessere Einblicke in die immer wichtiger werdenden Automatisierungen interessant. Auch die Investoren dieser Welt schauen ganz genau auf Produkte in der Kategorie Software Intelligence, zu denen die sich selbst als Second and Third Generation Monitoring bezeichnenden Lösungen zählen. So handelt es sich bei diesen modernen Monitoring-Produkten auch um Enterprise-SaaS-Lösungen der zweiten Welle. In einem ersten Anlauf sollten noch verhältnismäßig einfache Unternehmensaufgaben wie die firmenweite Dateiablage, beispielsweise mit Box und Dropbox (Business), als on Demand und per Nutzer zu bezahlender Dienst gelöst werden. Die Anbieter der zweiten Welle von Enterprise-Lösungen greifen wesentlich tiefer in die Unternehmensprozesse mit ein und sind weniger austauschbar — als prominente Beispiele sind hier allen voran Security-Dienste wie CloudStrike, Black Carbon oder Signals zu nennen. Diese neuen Lösungen, sofern bereits an die Börse gegangen, erhalten starken Zuspruch an den öffentlichen Märkten²³. Die Gründe sind wohl die gleichen: Die Wege zur Skalierung und Profitabilität sind bestens erforscht und Software is (still) eating the world²⁴.

—

Innovation um jeden Preis hinsichtlich der tatsächlichen Kosten, Risiko für die Privatsphäre und Zuverlässigkeit, war in den letzten Jahren die treibende Kraft hinter dem rasanten Wachstum von Technologie-Unternehmen. Wer schneller mehr Features auf den Markt und an den Kunden bringen konnte, hat meist das Rennen um Marktanteile gewonnen — von Public-Cloud-Anbietern bis Last-Mile-Mobilität mit per App zu buchender E-Scooter. Innovation hat Zuverlässigkeit als Unternehmensziel abgelöst, wie nicht nur in Mark Zuckerbergs frühem Motto für Facebook, sondern auch im Popularitätsabfall von Six-Sigma bei General Electric²⁵ gesehen werden kann. Vielleicht sorgt der Aufstieg von APM und das präzise Sammeln von Qualitätsdaten über eben genau diese Applikationen, die für Innovation und Digitalisierung stehen, wieder für mehr Qualität und Zuverlässigkeit.

Ich habe eine provokative Prognose aber natürlich gleichzeitig spekulative These: Für Unternehmen wird APM in naher Zukunft so wichtig sein wie das ERP-System. Warum? Klassische Monitoring-Lösungen bieten nicht genügend Einblick in die agile Softwarewelt. Diese sind zu stark auf einen Status quo fixiert, der unter allen Umständen erhalten werden soll. Für die Physik unter den Kubernetes Clustern und den Virtualisierungs-Layern mag dies noch die richtige Wahl der Tools sein. Aber regelmäßige Updates ohne Servicefenster, auf Grund von vollautomatisierten Build- und Deployment-Pipelines, überfordern jene Überwachungslösungen der alten Garde. Zusätzlich befindet sich aktuell jedes Unternehmen auf seiner ganz eigenen Digitalisierungsreise. Und dies bedeutet, dass individuelle und mitunter auch komplexe Prozesse mit speziellen Software-Lösungen abgebildet werden. Genau bei diesen Lösungen zeichnet sich ein quasi-einheitlicher Stack ab: Ein Datenbank-gestütztes Backend stellt seine Funktionalität über eine moderne API unterschiedlichen Frontends zur Verfügung. Wie diese Applikationen nun installiert, aktualisiert und und betrieben werden, mag ein Spezialfall sein, aber ein sinnvolles und tatsächlich Einblick gewährendes Monitoring ist nur möglich, wenn auch hier begonnen wird End-to-End zu denken und den vollständigen Prozess zu überwachen.

Während ERP-Systeme in den unterschiedlichen Gewichtsklassen Einblicke in die Unternehmenszahlen von Controlling und buchhalterischer Seite bieten, sind APM-Lösungen eben die Lupen in die Softwareprozesse, die diese Zahlen (aktuell noch mit Unterstützung menschlicher Arbeitsleistung) generieren. Kein CEO wird hier im Blindflug unterwegs sein wollen. Dass nun exakt diese Digitalisierung der Geschäftsprozesse noch eine andere Konsequenz für Karrierepfade haben könnte, ist für alle technology driven Personen ein netter Nebeneffekt. Bisher stand der CFO oder COO oft als zukünftiger CEO bereit, aber der Innovationsdruck rückt den CIO — aktuell mit dem I für Information und nicht Investment — oder CTO in ein besonderes Licht, um mitunter zukünftig für die Performance des Unternehmens zu sorgen.

This content is only available in German

Performance Matters Most

Auf das Beste zu hoffen genügt nicht (mehr)

Ein Blick in den Markt

Mehr als nur ein Blick in die technische Infrastruktur

—