Leben am Limit: Wie wir hierher gekommen sind

Entwickler und Ingenieure, die erst vor Kurzem in die Welt der Computer und Anwendungen eingestiegen sind, betrachten die Welt oft durch die Linse der neuesten und brillantesten Technologie auf dem Markt. Häufiger jedoch besteht die Wahrheit darin, dass es diese Konzepte und analogen Implementierungen schon immer gegeben hat – wie bei den Freunden aus der Kindheit von uns erfahrenen Veteranen der Technologiebranche. Sie entwickeln sich im Laufe der Zeit einfach weiter oder zurück, je nachdem, wie sich Geschäftsanforderungen und wirtschaftliche Aspekte im Verhältnis zu den zugrunde liegenden Implementierungsbeschränkungen und Infrastrukturen annähern bzw. auseinandergehen. Tatsächlich ist es das sich ständig weiterentwickelnde Geschäftsumfeld, das die Bedürfnisse und Anforderungen vorantreibt, was wiederum dazu führt, dass bestimmte Technologiestrategien neu entdeckt oder beiseite geschoben werden.

In diesem Sinne werde ich in der nächsten Artikelserie über einige der anwendungsbezogenen Technologien sprechen, die in den nächsten Jahren an Bedeutung gewinnen werden, insbesondere im Zuge unserer Entwicklung hin zu einer stärker verteilten Anwendungsbereitstellungsstruktur und der neuen Rolle des Edge. Doch zunächst ist es sinnvoll zu untersuchen, warum und wie wir dorthin gekommen sind, wo wir heute sind.

Stufe 1: Das Rechenzentrumszeitalter

Beginnen wir unsere Reise vor etwa 20 Jahren, zu einer Zeit, als die digitale Bereitstellung von Geschäftsdiensten (der Begriff „Anwendungen“ war damals noch nicht gebräuchlich) von privat geführten Rechenzentren aus erfolgte. Diese technische Strategie war für die damalige Zeit ausreichend und angemessen, vor allem deshalb, weil zu diesem Zeitpunkt nur die geschäftskritischsten Geschäftsabläufe „digitalisiert“ wurden.  Einige Beispiele für digitale Geschäftsabläufe in dieser Ära waren:

• Ein Onlinehändler würde lediglich das Einkaufserlebnis der Kunden und möglicherweise die Bestandsverwaltung „digitalisieren“. 
• Eine Fluggesellschaft würde lediglich die Reservierungs- und Zahlungssysteme „digitalisieren“. 
• Die Regierung würde Transaktionsabläufe mit hohem Wert, wie etwa Steuerzahlungen, „digitalisieren“.

Angesichts der Tatsache, dass zu dieser Zeit nur eine kleine Anzahl von Geschäftsabläufen – nämlich die wichtigsten – digital bereitgestellt und im Kontext einer typischen Unternehmensorganisation betrachtet wurden (vertikal integrierte, geografisch am selben Standort befindliche Belegschaften mit zentraler Kontrolle der Organisation und IT-Infrastruktur), war es nur natürlich, dass sich dies organisatorisch in einem zentral betriebenen und von der IT verwalteten Rechenzentrum widerspiegelte, in dem monolithische „Anwendungen“ liefen, die größtenteils oder vollständig intern entwickelt wurden. Infrastruktur, Sicherheit und Anwendungen (geb. „Geschäftsdienste“) bildeten einen einzigen vertikal integrierten Stapel. Somit ahmte der Technologie-Stack – zentralisiert und monolithisch – im wahrsten Sinne des Wortes die Organisations- und Geschäftsstrukturen nach.

Stufe 2: Das Cloud-Zeitalter

Der nächste Schritt in der Entwicklung von Anwendungen und deren Technologie-Stack wurde durch die Ausweitung der „Digitalisierung“ auf sekundäre Geschäftsabläufe vorangetrieben. Mit diesem nächsten Schritt wurde der Satz digitaler Arbeitsabläufe erweitert, um nicht nur kundenorientierte Arbeitsabläufe einzubeziehen – die zudem zu Massenware wurden, wie die zunehmende Verbreitung von Apps in App-Stores zeigt –, sondern auch den Umfang auf betriebliche Arbeitsabläufe innerhalb des Unternehmens auszudehnen, was oft als Teil des Trends zur digitalen Transformation von Unternehmen bezeichnet wird.

Infolgedessen waren die Unternehmen gezwungen, ihre betriebswirtschaftlichen Organisationsstrategien zu überdenken. Eine konkrete Auswirkung bestand darin, dass angesichts des geschäftlichen Problems rasch wechselnder Unternehmensgrößen ein größerer Schwerpunkt auf Kosteneffizienz und Agilität gelegt wurde. Dies hat zu einer Verlagerung des Zahlungsmodells in Richtung eines Versorgungspreismodells geführt, bei dem für das gezahlt wird, was tatsächlich genutzt wird, statt im Voraus bezahlen und Vorsorge für eine möglicherweise zu erwartende höhere Last treffen zu müssen. Um es in der Finanzterminologie auszudrücken: Das Modell zur Finanzierung der Anwendungsinfrastruktur verlagerte sich zunehmend vom Vorab-CapEx-Modell zur Pay-as-you-go-OpEx-Strategie. Ein weiterer paralleler Trend im gleichen Zeitraum, der ebenfalls mit Kosteneffizienz und Agilität zusammenhängt, war die Entwicklung hin zu einer geografisch stärker verteilten Belegschaft, die den Bedarf an allgegenwärtiger und zuverlässiger Konnektivität rund um die Uhr als in der Vergangenheit weckte.

Die Auswirkungen dieser Anforderungen – die Digitalisierung einer deutlich größeren Zahl von Geschäftsabläufen, der Wunsch nach Flexibilität im OpEx-Kostenmodell und die Forderung nach globaler Konnektivität rund um die Uhr – führten ganz natürlich zu einer Umgebung, die reif für die Schaffung eines globalen Netzwerks aus sehr großen, hochverfügbaren virtuellen Rechenzentren war, deren Nutzung als Serviceleistung bepreist wurde. Und so wurde die öffentliche Cloud geboren. 

Darüber hinaus entstand mit der Schaffung der öffentlichen Cloud eine sich selbst verstärkende positive Rückkopplungsschleife. Mit zunehmender Reife der öffentlichen Cloud als Anwendungsplattform begann sie, einen Großteil der Netzwerkinfrastruktur niedrigerer Ebene zu übernehmen, die zuvor von der traditionellen Unternehmens-IT verwaltet wurde. Infolgedessen verringerte sich in vielen Unternehmen der Umfang der Netzwerkbetriebsteams, und die Unternehmen richteten ihren Schwerpunkt stattdessen auf die Anwendungsbereitstellung und -übermittlung (auch bekannt als „DevOps“) und Anwendungssicherheit (auch bekannt als „SecOps“). Natürlich war dies nicht allgemeingültig; Dienstanbieter und große Unternehmen hatten die Notwendigkeit und die Möglichkeit, NetOps für ihre kritischsten oder sensibelsten Arbeitsabläufe intern durchzuführen.

Diese Geschichte repräsentierte die erste Phase des Cloud-Zeitalters, in der die öffentliche Cloud als eine Art ausgelagertes Rechenzentrum mit gemeinsam genutzter Zeit und Ressourcen betrachtet werden konnte. Mit anderen Worten: Die öffentliche Cloud war eine Abstraktion von Infrastructure-as-a-Service (IaaS).

Die nächste Phase des Cloud-Zeitalters wurde durch zwei verschiedene neue Geschäftserkenntnisse vorangetrieben, die beide das Phase-1-/IaaS-Paradigma als Voraussetzung erforderten. Die erste dieser geschäftlichen Erkenntnisse wurde durch die Fähigkeit ermöglicht, die Bereitstellung des Geschäftswerts von der Implementierung zu trennen, die den digitalen Workflow bereitstellte. Genauer gesagt konnten sich Unternehmen nun eine Ausführungsstrategie vorstellen, bei der die unteren Ebenen der Technologieinfrastruktur – die jetzt als Dienst aus der öffentlichen Cloud verwaltet wurden – von den Hauptanliegen der Unternehmensleitung entkoppelt werden konnten, die sich um das Wertversprechen des Unternehmens und die Differenzierungsmöglichkeiten gegenüber der Konkurrenz drehten. 

Die zweite geschäftliche Beobachtung bestand darin, dass mit der Digitalisierung und Automatisierung traditioneller Arbeitsabläufe die Geschäftsprozesse auf höherer Ebene in deutlich kürzerer Zeit angepasst und optimiert werden konnten. In einem separaten Artikel wird dieser Effekt ausführlicher erörtert. Dabei wird erläutert, wie sich digitale Arbeitsabläufe von der einfachen Aufgabenautomatisierung über die digitale Optimierung (auch als „digitale Erweiterung“ bekannt) bis hin zur KI-gestützten Geschäftserweiterung entwickeln. Als Beispiele für diesen Trend profitierten so unterschiedliche Arbeitsabläufe wie Preisanpassung, Mitarbeiterzeitplanung und Bestandsverwaltung allesamt von der schnellen Anpassungsfähigkeit und der Begriff „Geschäftsagilität“ wurde geprägt. 

Diese beiden Erkenntnisse führten zu einer geschäftlichen Offenbarung, da Unternehmen erkannten, dass es oft kosteneffizienter war, die Bereiche auszulagern, die nicht zu den Kernkompetenzen des Unternehmens gehörten. Dies wiederum führte zu einer Win-Win-Geschäftsvereinbarung zwischen dem Unternehmen und seinen Cloud-Provider-Partnern, bei der beide Seiten motiviert waren, die von der öffentlichen Cloud angebotenen Dienste weiter zu verbessern und so das Unternehmen von zusätzlichem Technologieaufwand zu entlasten. Dieses Konzept wurde dann durch die öffentliche Cloud erweitert, um Plattformfunktionen höherer Ebene wie Datenbanken, Dateisysteme, API-Gateways und serverlose Computing-Plattformen wiederum als Dienste in der öffentlichen Cloud verfügbar zu machen. Darüber hinaus bieten öffentliche Cloud-Anbieter auch die Integration von Over-the-Top-Diensten an, am häufigsten in den Bereichen Leistungsmanagement und Sicherheit.

Das Ergebnis war, dass mit der Reife des Cloud-Zeitalters das IaaS-Modell der Phase 1 hinter sich gelassen wurde und die Paradigmen der Cloud-Phase 2, Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS), eingeleitet wurden. Mit Cloud Phase 2 könnte der größte Teil (wenn nicht sogar die gesamte) Infrastruktur, die zur Unterstützung einer Anwendung erforderlich ist, vom Unternehmen an Cloud-Anbieter ausgelagert werden, die die Infrastruktur im großen Maßstab optimieren und ein größeres Team von Spezialisten bereitstellen könnten, um sich auf alle allgemein erforderlichen Anwendungsdienste zu konzentrieren. Dadurch hatte das Unternehmen zwar die Freiheit, sein Technologiebudget auf die Kerngeschäftslogik zu konzentrieren, doch es kam (aus Sicht des Unternehmens) häufig zu einem unerwünschten Nebeneffekt, nämlich der Bindung an einen bestimmten Cloud-Anbieter. Um diesen Effekt abzumildern, bemühten sich Unternehmen, den Ausdruck ihres zentralen Geschäftswerts mithilfe herstellerunabhängiger Technologien zu definieren und zu kodifizieren, insbesondere in den Schlüsselbereichen APIs und Rechenmodelle. Die Implementierung erfolgte mithilfe der REST- und gRPC-API-Technologie, unterstützt durch ein virtualisiertes und containerisiertes Rechenmodell – Kubernetes. 

Stufe 3: Digitalisierung physischer Dinge und Prozesse

Die dritte und sich derzeit abzeichnende Phase in der Entwicklung von „Anwendungen“ wird durch die Digitalisierung alltäglicher Aktivitäten vorangetrieben, die wir kaum als Arbeitsabläufe betrachten. Im Gegensatz zu Phase 1 und 2, in denen vor allem Geschäftsprozesse und eine kleine Anzahl transaktionaler Verbraucher-Workflows online gestellt wurden, geht es in dieser Phase darum, digitale Erlebnisse zu schaffen, die allgegenwärtig sind und sich nahtlos in unsere alltäglichen Handlungen im „menschlichen Leben“ integrieren. Die vollständigen Anwendungsfälle werden derzeit noch entwickelt, aber wir können bereits jetzt einen Blick auf die vielfältigen Möglichkeiten werfen, die vor uns liegen: neue Anwendungsfälle, die Technologien wie erweiterte Realität, automatische Heimüberwachungssysteme und Energiemanagement auf Netzebene nutzen. Die Lösungen interagieren insbesondere mit der realen, physischen Welt und nutzen häufig intelligente Geräte – autonome Fahrzeuge, digitale Assistenten, Kameras und alle Arten intelligenter Haushaltsgeräte. 

Aus Unternehmenssicht wird bei diesem nächsten Übergang der Schwerpunkt viel stärker auf das Benutzererlebnis des digitalen Verbrauchers gelegt. Dieser Fokus auf das Benutzererlebnis sowie die Beobachtung, dass Geräte und nicht Menschen den Großteil der direkten Kunden digitaler Prozesse ausmachen werden, führen dazu, dass die Anforderungen des digitalen Konsumenten an das Benutzererlebnis viel vielfältiger sein werden als in früheren Phasen der digitalen Evolution. Dieser nächste Übergang von Stufe 2 zu Stufe 3 wird sich vom vorherigen (Stufe 1 zu Stufe 2) unterscheiden. Dieser nächste Schritt wird nicht einfach eine extrapolierte Weiterentwicklung der üblichen Kennzahlen für das digitale Erlebnis sein (z. B. „Schneller machen und geringere Latenzzeiten“), sondern vielmehr darin bestehen, der „Anwendung“ eine viel breitere Palette an Auswahlmöglichkeiten für Kompromisse bei der Anwendungsbereitstellung zu geben, sodass das Erlebnis im Kontext des betrachteten Anwendungsfalls an die Anforderungen des digitalen Verbrauchers angepasst werden kann.

Aus technologischer Sicht bedeuten die Geschäftsanforderungen, dass aufgrund der zunehmenden Vielfalt der Anforderungen an das Konsumerlebnis die Entwicklung entsprechend flexibler und anpassungsfähiger Mittel erforderlich wird, um allgemeine Kennzahlen für die Anwendungsbereitstellung (Latenz, Bandbreite, Zuverlässigkeit und Verfügbarkeit) abzuwägen, festzulegen und zu optimieren. Beispielsweise erfordert ein Augmented-Reality-Erlebnissystem möglicherweise eine sehr geringe Latenz und eine hohe Bandbreite, kann aber einen kleinen Rückgang des Netzwerkverkehrs tolerieren. Umgekehrt erfordert eine Heimkamera, die für ein Alarmsystem verwendet wird, möglicherweise eine hohe Bandbreite, toleriert aber eine (relativ) längere Latenz im Sekundenbereich. Ein intelligenter Zähler kann zwar lange Latenzzeiten und geringe Bandbreiten tolerieren, erfordert aber möglicherweise ein hohes Maß an Zuverlässigkeit, wenn nicht sogar eine zeitnahe, damit der gesamte Energieverbrauch aufgezeichnet wird.

Das Design und die Architektur eines Systems, das flexibel und anpassungsfähig genug ist, um die Anforderungen dieser nächsten Stufe der „Digitalisierung“ zu erfüllen, erfordern einen Mechanismus, mit dem die vielen Komponenten, aus denen die Bereitstellung eines digitalen Erlebnisses besteht, problemlos verteilt und bei Bedarf an verschiedene Standorte im Anwendungsbereitstellungspfad migriert werden können. Die Verteilung dieser Anwendungskomponenten muss auf die Bereitstellungsbedürfnisse (Latenz, Bandbreite, Zuverlässigkeit) zugeschnitten sein, die sich aus den Anforderungen an das Benutzererlebnis ergeben. Zudem müssen sich die Systeme kontinuierlich an Änderungen der Umgebung und der Belastung anpassen. Und nicht zuletzt müssen die Sicherheitsaspekte der Anwendung (Identitätsverwaltung, Schutz vor Malware, Erkennung von Sicherheitsverletzungen) nahtlos mit den Anwendungskomponenten Schritt halten, wenn diese im Bereitstellungspfad der Anwendung verschoben werden.

Sich auf die Straße vor uns konzentrieren

Was bedeutet das also konkreter im Hinblick auf unsere heutige Situation?  Es bedeutet Folgendes:

• Erstens: Da es sich bei der Mehrheit der Konsumenten digitaler Erfahrungen um andere Anwendungen und digitale Dienste handeln wird, wird die Rolle von APIs und API-Management noch stärker in den Mittelpunkt rücken.
• Zweitens werden die heute verfügbaren Standorte zur Anwendungsbereitstellung – Rechenzentrum, Cloud und Cloud-basierte Dienste – nicht ausreichen, um den zukünftigen Anforderungen gerecht zu werden. Genauer gesagt: Um ein besseres Kundenerlebnis zu bieten, müssen wir in der Lage sein, Aspekte des digitalen Anwendungserlebnisses näher an den Endbenutzer zu bringen und dazu Technologien wie Intelligent Edge, Inhalte und Rechendienste im Bereitstellungspfad sowie SDWAN im Bereitstellungspfad zu nutzen. Möglicherweise müssen wir sogar den Anwendungsbereitstellungspfad erweitern, um clientseitige Sandbox-Technologien zu verwenden.  
• Drittens wird der Rand zunehmend zum „Einstiegspunkt“ in die Bereitstellung digitaler Erlebnisse und daher als zentraler Orchestrierungspunkt für die Bereitstellung an Bedeutung gewinnen.
• Und schließlich muss die Sicherheit nicht nur inhärent und allgegenwärtig sein, sondern auch unabhängig davon, wie die Anwendungskomponenten entlang des Anwendungsbereitstellungspfads verteilt sind.

Diese letzten drei Themen stehen im Mittelpunkt der nächsten Artikel dieser Reihe. Darin sprechen wir über den „Edge“ und seine Zukunftsaussichten und anschließend darüber, wie eine wirklich standortunabhängige Sicherheitsbetrachtung aussehen kann.