Leben am Limit: Wie wir hierhergekommen sind

Ken Arora

Entwickler und Ingenieure, die erst vor Kurzem in die Welt der Computertechnik und Anwendungen eingestiegen sind, betrachten die Welt häufig durch die Brille der aktuellsten, neuesten und angesagtesten Technologie. Doch meist ist es so, dass diese Konzepte und vergleichbare Implementierungen – ähnlich wie die Freunde aus Kindertagen von uns ergrauten Veteranen der Technologiebranche – schon immer existiert haben. Im Laufe der Zeit gewinnen oder verlieren sie lediglich an Bedeutung, je nachdem, wie sich geschäftliche Anforderungen und wirtschaftliche Rahmenbedingungen im Verhältnis zu den zugrunde liegenden Einschränkungen bei der Implementierung und den vorhandenen Infrastrukturen annähern oder auseinanderentwickeln. Tatsächlich ist es das sich ständig wandelnde Geschäftsumfeld, das neue Bedürfnisse und Anforderungen hervorbringt und dazu führt, dass bestimmte Technologiestrategien wiederentdeckt oder verworfen werden.

In diesem Sinne werde ich mich in den nächsten Artikeln mit einigen anwendungsbezogenen Technologien befassen, die in den kommenden Jahren an Bedeutung gewinnen werden – insbesondere im Zuge der Entwicklung hin zu einer stärker verteilten Infrastruktur für die Anwendungsbereitstellung und der wachsenden Rolle des Edge Computing. Zunächst lohnt es sich jedoch zu untersuchen, warum und wie wir an den heutigen Punkt gelangt sind.

Phase 1: Das Zeitalter der Rechenzentren

Beginnen wir unsere Reise vor etwa 20 Jahren, als Geschäftsdienste digital aus privat betriebenen Rechenzentren bereitgestellt wurden (der Begriff „Anwendungen“ war damals noch nicht gebräuchlich). Diese technische Strategie war für jene Zeit ausreichend und angemessen, vor allem weil damals nur die geschäftskritischsten Abläufe „digitalisiert“ waren. Einige Beispiele für digitale Geschäftsabläufe jener Zeit waren:

• Ein Onlinehändler würde lediglich das Einkaufserlebnis seiner 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“.

Da nur eine geringe Anzahl von Geschäftsabläufen – nämlich die wichtigsten – digital bereitgestellt und im Kontext einer für diese Zeit typischen Unternehmensorganisation betrachtet wurden (vertikal integrierte, am selben Standort tätige Belegschaften mit zentraler Steuerung der Organisation und IT-Infrastruktur), war es nur folgerichtig, dass sich dies organisatorisch in einem zentral betriebenen und von der IT verwalteten Rechenzentrum widerspiegelte, in dem monolithische „Anwendungen“ ausgeführt wurden, die größtenteils oder vollständig intern entwickelt worden waren. Infrastruktur, Sicherheit und Anwendungen (vormals „Geschäftsdienste“) bildeten einen einzigen vertikal integrierten Stack. Somit bildete der zentralisierte und monolithische Technologie-Stack die Organisations- und Geschäftsstrukturen im wahrsten Sinne des Wortes nach.

Phase 2: Das Cloud-Zeitalter

Der nächste Schritt in der Entwicklung von Anwendungen und ihres Technologie-Stacks wurde durch die Ausweitung der „Digitalisierung“ auf sekundäre Geschäftsabläufe vorangetrieben. Dadurch wurde das Spektrum digitaler Abläufe erweitert: Es umfasste nun nicht mehr nur kundenorientierte Abläufe, die zunehmend zur Standardware wurden, wie die Vielzahl von Apps in App-Stores zeigt, sondern auch unternehmensinterne betriebliche Abläufe, die häufig dem Trend zur digitalen Transformation von Unternehmen zugerechnet werden.

Infolgedessen waren Unternehmen gezwungen, ihre Organisationsstrategien zu überdenken. Angesichts der Herausforderung, den Geschäftsbetrieb schnell skalieren zu müssen, wurde insbesondere größerer Wert auf Kosteneffizienz und Agilität gelegt. Dadurch verlagerte sich das Zahlungsmodell hin zu einem verbrauchsabhängigen Preismodell, bei dem nur die tatsächlich genutzten Ressourcen bezahlt werden, anstatt im Voraus für eine möglicherweise erwartete höhere Auslastung zu zahlen und entsprechende Kapazitäten bereitzustellen. In der Finanzterminologie ausgedrückt, verlagerte sich das Finanzierungsmodell für die Anwendungsinfrastruktur zunehmend vom vorab finanzierten CapEx-Modell hin zu einer nutzungsabhängigen OpEx-Strategie. Ein weiterer zeitgleich auftretender Trend, der ebenfalls mit Kosteneffizienz und Agilität zusammenhing, war die Entwicklung hin zu einer geografisch stärker verteilten Belegschaft. Dadurch entstand ein größerer Bedarf an flächendeckender und zuverlässiger Konnektivität rund um die Uhr als in der Vergangenheit.

Die Auswirkungen dieser Anforderungen – die Digitalisierung einer weitaus größeren Zahl von Geschäftsabläufen, der Wunsch nach der Flexibilität des OpEx-Kostenmodells und die Notwendigkeit einer globalen Konnektivität rund um die Uhr – schufen ganz natürlich ein Umfeld, das ideale Voraussetzungen für den Aufbau eines globalen Netzwerks aus sehr großen, hochverfügbaren virtuellen Rechenzentren bot, deren Nutzung verbrauchsabhängig abgerechnet wurde. So entstand die Public Cloud.

Darüber hinaus entstand, nachdem die Grundlagen für die Public Cloud geschaffen waren, eine sich selbst verstärkende positive Rückkopplungsschleife. Mit zunehmender Reife der Public Cloud als Anwendungsplattform begann sie, einen Großteil der zugrunde liegenden Netzwerkinfrastruktur zu übernehmen, die zuvor von der traditionellen Unternehmens-IT verwaltet worden war. Infolgedessen verringerte sich in vielen Unternehmen der Aufgabenbereich der Netzwerkbetriebsteams, während sich die Unternehmen stattdessen auf die Bereitstellung und Auslieferung von Anwendungen (auch „DevOps“ genannt) sowie auf die Anwendungssicherheit (auch „SecOps“ genannt) konzentrierten. Dies galt natürlich nicht ausnahmslos: Dienstanbieter und große Unternehmen hatten sowohl den Bedarf als auch die Fähigkeit, NetOps für ihre kritischsten oder sensibelsten Workflows intern durchzuführen.

Diese Entwicklung kennzeichnete die erste Phase des Cloud-Zeitalters, in der die Public Cloud als eine Art ausgelagertes Rechenzentrum betrachtet werden konnte, dessen Zeit und Ressourcen gemeinsam genutzt wurden – mit anderen Worten: Die Public Cloud wurde als Infrastructure-as-a-Service (IaaS) abstrahiert.

Die nächste Phase des Cloud-Zeitalters wurde von zwei neu gewonnenen geschäftlichen Erkenntnissen vorangetrieben, die beide das Phase-1-/IaaS-Paradigma voraussetzten. Die erste dieser Erkenntnisse wurde durch die Möglichkeit eröffnet, die Bereitstellung des geschäftlichen Nutzens von der Implementierung des digitalen Workflows zu trennen. Konkret konnten Unternehmen nun eine Umsetzungsstrategie ins Auge fassen, bei der die unteren Ebenen der technologischen Infrastruktur – die inzwischen als Service der Public Cloud verwaltet wurden – von den Hauptanliegen der Unternehmensführung entkoppelt werden konnten, nämlich dem Wertversprechen des Unternehmens und seinen Alleinstellungsmerkmalen im Wettbewerb.

Die zweite geschäftliche Erkenntnis bestand darin, dass sich übergeordnete Geschäftsprozesse in wesentlich kürzeren Zeiträumen anpassen und optimieren ließen, je mehr traditionelle Arbeitsabläufe digitalisiert und automatisiert wurden. Ein separater Artikel erläutert diesen Effekt ausführlicher und beschreibt, wie sich digitale Arbeitsabläufe von der einfachen Aufgabenautomatisierung über die digitale Optimierung (auch „digitale Expansion“ genannt) bis hin zu KI-gestützten Geschäftserweiterungen entwickeln. Beispiele für diesen Trend sind so unterschiedliche Arbeitsabläufe wie Preisanpassungen, die Arbeitszeitplanung von Mitarbeitenden und die Bestandsverwaltung, die allesamt von der schnellen Anpassungsfähigkeit profitierten. Dafür wurde der Begriff „geschäftliche Agilität“ geprägt.

Diese beiden Erkenntnisse führten zu einem Aha-Erlebnis in der Geschäftswelt: Unternehmen erkannten, dass es häufig kosteneffizienter war, Bereiche auszulagern, die nicht zu ihren Kernkompetenzen gehörten. Dies wiederum führte zu einer für beide Seiten vorteilhaften Geschäftsbeziehung zwischen den Unternehmen und ihren Cloud-Anbietern. Beide Seiten waren bestrebt, die über die Public Cloud angebotenen Dienste weiterzuentwickeln und die Unternehmen dadurch von zusätzlichem technologischem Aufwand zu entlasten. Dieses Konzept wurde anschließend auf höherwertige Plattformfunktionen wie Datenbanken, Dateisysteme, API-Gateways und Serverless-Computing-Plattformen ausgeweitet, die ebenfalls als Dienste in der Public Cloud bereitgestellt wurden. Darüber hinaus boten Public-Cloud-Anbieter auch die Integration zusätzlicher Dienste an, insbesondere in den Bereichen Performance-Management und Sicherheit.

Als die Cloud-Ära über das IaaS-Modell der Phase 1 hinausreifte, führte dies zur Cloud-Phase 2 mit den Paradigmen Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS). In Cloud-Phase 2 konnte der Großteil, wenn nicht sogar die gesamte für den Betrieb einer Anwendung erforderliche Infrastruktur vom Unternehmen an Cloud-Anbieter ausgelagert werden. Diese konnten die Infrastruktur in großem Maßstab optimieren und größere Spezialistenteams einsetzen, die sich auf allgemein benötigte Anwendungsdienste konzentrierten. Dadurch konnten Unternehmen ihr Technologiebudget zwar auf die zentrale Geschäftslogik ausrichten, doch entstand häufig der aus Unternehmenssicht unerwünschte Nebeneffekt einer Abhängigkeit von einem bestimmten Cloud-Anbieter („Vendor-Lock-in“). Um diesen Effekt abzumildern, bemühten sich Unternehmen, ihre zentralen Geschäftswerte mithilfe anbieterunabhängiger Technologien zu definieren und in Code abzubilden. Dies galt insbesondere für die Schlüsselbereiche APIs und Computing-Modelle. Zur Umsetzung kamen REST- und gRPC-API-Technologien zum Einsatz, die auf einem virtualisierten und containerisierten Computing-Modell basierten: Kubernetes.

Phase 3: Digitalisierung physischer Dinge und Prozesse

Die dritte, derzeit im Entstehen begriffene Phase in der Entwicklung von „Anwendungen“ wird durch die Digitalisierung alltäglicher Aktivitäten vorangetrieben, die wir kaum als Arbeitsabläufe wahrnehmen. Im Gegensatz zu den Phasen 1 und 2, in denen vor allem Geschäftsprozesse und eine kleine Auswahl transaktionsbezogener Abläufe für Verbraucher online verlagert wurden, geht es in dieser Phase darum, allgegenwärtige digitale Erlebnisse zu schaffen, die nahtlos in unsere alltäglichen Handlungen integriert sind. Das gesamte Spektrum der Anwendungsfälle entwickelt sich noch, doch neue Einsatzmöglichkeiten, die Technologien wie Augmented Reality, automatisierte Überwachungssysteme für das Zuhause und die Steuerung von Stromnetzen nutzen, geben bereits einen Vorgeschmack auf den vielfältigen und vielversprechenden Weg, der vor uns liegt. Diese Lösungen interagieren insbesondere mit der realen, physischen Welt und nutzen dabei häufig intelligente Geräte – autonome Fahrzeuge, digitale Assistenten, Kameras und alle Arten von Smart-Home-Geräten.

Aus Unternehmenssicht wird bei diesem nächsten Übergang die Benutzererfahrung der digitalen Konsumenten deutlich stärker in den Mittelpunkt rücken. Dieser Fokus auf die Benutzererfahrung bedeutet in Verbindung mit der Erkenntnis, dass nicht Menschen, sondern Geräte die Mehrheit der direkten Nutzer digitaler Prozesse ausmachen werden, dass die Anforderungen der digitalen Konsumenten an die Benutzererfahrung wesentlich vielfältiger sein werden als in den vorherigen Phasen der digitalen Entwicklung. Dieser nächste Übergang von Phase 2 zu Phase 3 wird sich vom vorherigen Übergang (von Phase 1 zu Phase 2) unterscheiden. Konkret wird dieser nächste Schritt keine einfache Fortschreibung der üblichen Kennzahlen für digitale Erlebnisse sein (d. h. „schneller machen und die Latenz verringern“). Stattdessen wird es darum gehen, der „Anwendung“ wesentlich mehr Möglichkeiten zu geben, Zielkonflikte bei der Anwendungsbereitstellung abzuwägen, sodass die Benutzererfahrung im Kontext des jeweiligen Anwendungsfalls auf die Anforderungen der digitalen Konsumenten zugeschnitten werden kann.

Aus technologischer Sicht bedeuten die geschäftlichen Anforderungen, dass aufgrund der zunehmenden Vielfalt der Anforderungen an das Nutzungserlebnis entsprechend flexible und anpassungsfähige Möglichkeiten geschaffen werden müssen, um gängige Kennzahlen für die Anwendungsbereitstellung gegeneinander abzuwägen, festzulegen und zu optimieren: Latenz, Bandbreite, Zuverlässigkeit und Verfügbarkeit. Ein Augmented-Reality-System kann beispielsweise eine sehr geringe Latenz und eine hohe Bandbreite erfordern, zugleich aber den Verlust eines kleinen Teils des Netzwerkverkehrs eher tolerieren. Eine in einem Alarmsystem eingesetzte Heimkamera hingegen benötigt möglicherweise eine hohe Bandbreite, kann aber eine (vergleichsweise) längere Latenz im Sekundenbereich tolerieren. Ein intelligenter Stromzähler kann sowohl lange Latenzen als auch geringe Bandbreiten tolerieren, erfordert jedoch möglicherweise eine hohe letztendliche, wenn auch nicht zeitnahe, Zuverlässigkeit, damit der gesamte Energieverbrauch erfasst wird.

Das Design und die Architektur eines Systems, das flexibel und anpassungsfähig genug ist, um die Anforderungen dieser nächsten Phase der „Digitalisierung“ zu erfüllen, erfordern einen Mechanismus, mit dem sich die zahlreichen Komponenten, die zur Bereitstellung eines digitalen Erlebnisses beitragen, problemlos auf verschiedene Standorte entlang des Pfads der Anwendungsbereitstellung verteilen und bei Bedarf zwischen ihnen verschieben lassen. Die Verteilung dieser Anwendungskomponenten muss auf die durch die Anforderungen an das Benutzererlebnis bestimmten Bereitstellungsanforderungen – Latenz, Bandbreite und Zuverlässigkeit – zugeschnitten sein, und die Systeme müssen sich kontinuierlich an Veränderungen der Umgebung und Auslastung anpassen. Nicht zuletzt müssen die Sicherheitsfunktionen der Anwendung – Identitätsmanagement, Schutz vor Schadsoftware und Erkennung von Sicherheitsverletzungen – den Anwendungskomponenten nahtlos folgen, wenn diese innerhalb des Pfads der Anwendungsbereitstellung verschoben werden.

Mit Zuversicht auf den vor uns liegenden Weg

Was bedeutet das also konkret im Vergleich zu unserem heutigen Stand? Es bedeutet Folgendes:

• Erstens: Da die Mehrheit der Nutzer digitaler Erlebnisse andere Anwendungen und digitale Dienste sein werden, rücken APIs und das API-Management noch stärker in den Mittelpunkt.
• Zweitens werden die heute verfügbaren Orte für die Anwendungsbereitstellung – Rechenzentrum, Cloud und über die Cloud bereitgestellte Dienste – nicht ausreichen, um die Anforderungen der Zukunft zu erfüllen. Um ein umfassenderes Kundenerlebnis zu bieten, müssen wir insbesondere in der Lage sein, bestimmte Aspekte des digitalen Anwendungserlebnisses näher am Endnutzer bereitzustellen. Dazu können Technologien wie Intelligent Edge, Content- und Computing-Dienste im Bereitstellungspfad sowie SD-WAN im Bereitstellungspfad eingesetzt werden. Möglicherweise müssen wir den Anwendungsbereitstellungspfad sogar um clientseitige Sandbox-Technologien erweitern.
• Drittens wird der Edge zunehmend zum „Einstiegspunkt“ für die Bereitstellung digitaler Erlebnisse und damit als zentraler Orchestrierungspunkt für die Bereitstellung an Bedeutung gewinnen.
• Und schließlich muss Sicherheit nicht nur inhärent und allgegenwärtig sein, sondern auch unabhängig davon funktionieren, wie die Anwendungskomponenten entlang des Bereitstellungspfads der Anwendung verteilt sind.

Diese letzten drei Themen stehen im Mittelpunkt der nächsten Artikel dieser Reihe. Darin befassen wir uns mit dem „Edge“, seiner künftigen Entwicklung und anschließend mit der Frage, wie eine wirklich standortunabhängige Betrachtung der Sicherheit aussieht.

Über den Autor

Ken Arora

Weitere Blogbeiträge von Ken Arora