Geht es nach den Web3-Befürwortern, handelt es sich im Kern um eine Reihe von Consumer-Technologien, die die transaktionalen Grundlagen des Webs ersetzen sollen. In meinen Augen handelt es sich bei Web3 eher um ein limitiertes Tool, das auf Blockchain-Technologien aufbaut und eine Teilmenge von Enterprise-Applikationen - mit Schwerpunkt auf elektronischem Datenaustausch - unterstützen kann. Schließlich handelt es sich bei der Blockchain im Wesentlichen um eine unveränderliche Datenstruktur, die auf vertrauenswürdige Weise zwischen nicht vertrauenswürdigen Partnern geteilt werden kann. Das macht die Technologie vor allem nützlich, wenn es um die Lieferkette geht, wo elektronische Dokumente eine vertragliche und rechtliche Grundlage haben, die in internationalen Verträgen verankert ist und in denen ein Ende der Lieferkette nur eine indirekte Beziehung zum anderen hat.

Microsofts Arbeit an Blockchains mit Proof-of-Membership-Konsensalgorithmen, die von Konsortien nicht vertrauenswürdiger Organisationen betrieben werden, bildet hier eine interessante Option und stellt eine schnelle und kostengünstige Alternative zu Proof-of-Work- und Proof-of-Stake-Systemen dar. Parallel bieten die aktuellen Versionen von SQL Server nun auch einen Immutable Ledger für Applikationen, die nicht zwischen verschiedenen Entitäten verteilt werden müssen.

Diese Blockchain-basierten Services kann man sich als eine Art elektronisches Äquivalent zur Bill of Lading vorstellen - ein Dokument, das Auskunft über die Ladung eines Schiffes gibt. Dieses Dokument durchläuft mehrere verschiedene Geschäftssysteme unverändert. Dabei sind möglicherweise nicht alle Entitäten bekannt, die mit den Dokumenten und Verträgen interagieren. Bei diesen Entitäten kann es sich unter anderem um Hersteller, Verlader, Lagerhäuser, Frachtschiffe, Zollbeamte oder Zollämter handeln. Sie alle benötigen Zugriff auf die Informationen - und die meisten sind dabei Teil eines komplexen Genehmigungsprozesses mit mehreren Beteiligten.

Dieses Modell könnte sich für Unternehmens-Blockchains eignen - allerdings müssen wir uns Gedanken darüber machen, wie wir die Technologie innerhalb moderner Entwicklungsumgebungen nutzen können. Schließlich bauen wir bereits verteilte Systeme in großem Maßstab für Cloud-native Anwendungen mit DevOps und CI/CD-Plattformen auf. Es stellt sich die Frage: Lassen sich diese Technologien auch für Web3 nutzen?

Enterprise Tools in der Blockchain nutzen

Donovan Brown von Microsoft wurde mit der Aufgabe betraut, zu untersuchen, wie Entwickler mit diesen verteilten Anwendungsplattformen arbeiten sollten. Brown, der jetzt zum CTO-Inkubationsteam von Mark Russinovich für Azure gehört, ist vor allem für seine Arbeit im Bereich DevOps bekannt. Von daher war es nicht überraschend, dass er schnell damit begann, beliebte Web3-Plattformen in ein DevOps-Framework zu integrieren. Dabei konnte er einige gute Ergebnisse erzielen - was ich zum Anlass genommen habe, mich mit ihm darüber zu unterhalten, wie man diese Technologien mit Unternehmenstools nutzen kann.

Dazu müssen sie zunächst für den Unternehmenseinsatz fit gemacht, in den Softwareentwicklungsprozess und in Entwicklungsplattformen sowie Build- und Testing-Tools integriert werden. Das Hauptaugenmerk liegt dabei darauf, die vielen Risiken die mit dem Web3 verbunden sind, zu minimieren - insbesondere, wenn es dabei um E-Commerce-Abwicklung oder andere wichtige Informations- und Wertflüsse geht. Ein Smart Contract, der gekapert und manipuliert werden kann, liegt nicht in unserem Interesse.

Ein Problem, das DevOps-Experte Brown bei seiner Arbeit identifiziert hat, ist die explosionsartige Zunahme von Tools, die lediglich leicht unterschiedliche Funktionen bieten. Eine solche Tool-Landschaft erschwere den Einstieg, da weder eine eindeutige Toolchain noch Best Practices existieren würden, so Brown. "Die ausgereiften Tools, die die Best Practices von Unternehmen unterstützen, müssen identifiziert werden, um sie in einen GitHub Codespace einzubinden oder in einer der virtuellen Entwicklungsumgebungen von Microsoft Dev Box verfügbar zu machen. Andernfalls ist der Einstieg schwierig."

Die Auswahl der Tools ist nur ein Teil des Problems und möglicherweise das geringfügigste: "Das größte Problem besteht darin, dass es sehr schwierig ist, diese neuen Tools in bestehende Pipelines zu integrieren, wenn bewährte Entwicklungsverfahren zum Einsatz kommen. Als ich mich näher damit befasste, wurde mir klar, dass diese Tools gar nicht für den Einsatz in einer Pipeline konzipiert sind", offenbart Brown. "Man verlässt sich zu sehr auf einfache Veröffentlichungstechniken, schreibt den Code selbst und veröffentlicht ihn einfach ohne formale Tests. Dieser Ansatz ist gut für selbst gehostete Experimente und Prototypen, eignet sich aber nicht, um Code in Enterprise-Qualität bereitzustellen."

DevOps-Pipeline in Azure aufbauen

Um die Tools in eine DevOps-Pipeline einzubinden, sollten Web3-Technologien zunächst nicht mehr isoliert vom Rest des Technologie-Stacks betrachtet werden. Dann lassen sich Integrationspunkte identifizieren - etwa die Integration von Smart Contracts in ein Test-Harness.

Microsoft-Experte Brown war in der Lage, eine Ethereum-basierte, verteilte Anwendungsumgebung aufzubauen, die Azure Pipelines mit Dev-, QA- und Produktions-Outputs verwendet, wobei das Anwendungs-Frontend auf Azure Static Web Apps gehostet wird. Entwicklungsimplementierungen laufen in einer privaten Ethereum-Instanz auf Azure Containers.

Das größte Problem bei diesem Ansatz: Smart Contracts in verschiedenen Umgebungen bereitzustellen. Smart Contracts verfügen nämlich über eine fest kodierte Adresse, die beim Kompilieren automatisch zum JSON des Smart Contracts hinzugefügt wird. Dadurch muss der gesamte Vertrag bei jeder Bereitstellung neu erstellt werden, was mehrere Neukonstruktionen für jede Umgebung erfordert.

Wie Brown anmerkt, handelt es sich hierbei um ein DevOps-Antipattern: "Sie sollten nur einmal kompilieren müssen und die umgebungsspezifischen Werte zur Laufzeit hinzufügen. Den Front-End-Code der Anwendung so umzuschreiben, dass eine externe Quelle für die Netzwerkadresse unterstützt wird, war Einiges an Arbeit. Dieser Ansatz macht es einfacher, den Dienst zu nutzen, wenn eine Vertragsadresse nicht gefunden werden kann, indem eine Azure-Funktion verwendet wird, um die Adresse bei Abfrage zu liefern."

Auf diese Weise muss Browns Code das Frontend nur einmal erstellen und kann es in jeder Phase der Bereitstellungspipeline verwenden. Er könnte dann Standard-JavaScript-Test-Frameworks mit seiner Anwendung verwenden. Alle erforderlichen Schritte, um die einzelnen Umgebungen aus einem GitHub-Repository zu erstellen und bereitzustellen, könnten in eine einzige Azure-Pipeline integriert werden - wobei die Umgebungen nach jeder Validierung gelöscht werden. Tools wie Azure Container Apps helfen hier und ermöglichen eine schnelle Bereitstellung von Build-Artefakten.

Von diesem Ausgangspunkt aus ist es möglich, Unterstützung für zusätzliche Frameworks in jeder Umgebung sowie Infrastructure-as-Code-Tools wie Bicep und Systemverwaltungsskripte in der Azure CLI und PowerShell hinzuzufügen. So ist auch eine wiederholbare Umgebung sichergestellt und Sie sind in der Lage, eine betriebsbereite Anwendung und alle zur Unterstützung erforderlichen Server und Dienste bereitzustellen. Wenn Sie in Azure mit Infrastructure-as-a-Service- und Platform-as-a-Service-Tools arbeiten, können Sie ungenutzte Umgebungen entfernen, nachdem sie nicht mehr benötigt werden. Das spart Geld und stellt sicher, dass Ihre Anwendung und ihre Umgebung idempotente verteilt sind, wobei jede Änderung an Ihrem Code eine vollständige Neuverteilung der gesamten Anwendung und der unterstützenden Infrastruktur erfordert.

Auf dem Weg zum Blockchain-Reifegradmodell

Browns Arbeit zeigt, wie Web3-Technologien als Teil eines modernen Anwendungs-Frameworks in eine vertraute Unternehmensumgebung integriert werden können. Es besteht keine Notwendigkeit, vertraute Tools wie GitHub, Azure Devops, Azure Container Apps oder VS Code über Bord zu werfen.

Klar ist jedoch, dass die Art und Weise verändert werden muss, wie Web3-Frameworks mit Umgebungsvariablen und dynamischen Ressourcen arbeiten. Sie sind nicht für die Arbeit in einer mehrstufigen Pipeline konzipiert und erfordern Änderungen, wenn sie den angemessenen Reifegrad für den Einsatz im großen Maßstab in Unternehmensanwendungen bieten sollen. Außerdem ist eine bessere Telemetrie erforderlich, damit die Entwickler einen genaueren Überblick über die Performance ihrer Anwendungen und Smart Contracts erhalten.

Im Ergebnis steht ein interessanter Mix aus Vertrautem und Neuem. Das ist gut so, denn es erleichtert Entwicklern, neue Technologien zu übernehmen und in bestehende Entwicklungsprozesse einzubringen. Unternehmen wie Microsoft können dazu beitragen, dass aufkommende Innovationen schneller reifen, wenn sie sich eingehend mit diesen Technologien beschäftigen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.