Photo: VectorMine – shutterstock.com
At its core, Web3 proponents have their way, it’s a set of consumer technologies designed to replace the transactional underpinnings of the web. In my eyes, Web3 is more of a limited tool built on blockchain technologies and capable of supporting a subset of enterprise applications, with a focus on electronic data interchange. After all, the blockchain is essentially an immutable data structure that can be reliably shared between untrusted partners. This makes the technology particularly useful when it comes to the supply chain, where electronic documents have a contractual and legal basis enshrined in international treaties and where one end of the supply chain has only one indirect relationship with the other.
Microsoft’s work on blockchains with proof-of-membership consensus algorithms operated by consortia of untrusted organizations is an attractive option here, and represents a fast and low-cost alternative to proof-of-work and proof-of-trust systems. participation. At the same time, the current versions of SQL Server now also offer an immutable registry for applications that do not have to be split between different entities.
These blockchain-based services can be thought of as a sort of electronic equivalent of the bill of lading – a document that provides information about a ship’s cargo. This document traverses several different business systems without change. Not all entities that interact with documents and contracts may be known. These entities may include, but are not limited to, manufacturers, shippers, warehouses, freighters, customs agents or customs offices. They all need access to information – and most are part of a complex multi-party approval process.
This model could be suitable for enterprise blockchains – however, we need to think about how we can use the technology in modern development environments. Finally, we build already distributed systems at scale for cloud-native applications using DevOps and CI/CD platforms. The question arises: can these technologies also be used for Web3?
Microsoft’s Donovan Brown was tasked with investigating how developers should work with these distributed application platforms. Brown, now part of Mark Russinovich’s CTO incubation team for Azure, is best known for his work in the DevOps space. So it’s no surprise that he quickly started integrating popular Web3 platforms into a DevOps framework. He has had good results in this area, which prompted me to discuss with him how these technologies can be leveraged with enterprise tools.
To do this, they must first be adapted for enterprise use, integrated into the software development process and development platforms as well as build and test tools. The main objective is to minimize the many risks associated with Web3, particularly with regard to the processing of e-commerce or other important flows of information and value. A smart contract that can be hijacked and manipulated is not in our interest.
One of the problems DevOps expert Brown has identified in his work is the explosion of tools that only offer slightly different functionality. Such a landscape of tools makes it difficult to get started, as there is no clear tool chain or best practices, according to Brown. “Mature tools that support enterprise best practices should be identified for inclusion in a GitHub codespace or made available in one of Microsoft Dev Box’s virtual development environments. Otherwise, it is difficult to start.”
Tool selection is only part of the problem, and perhaps the most minor: “The biggest problem is that it is very difficult to integrate these new tools into existing pipelines when using best development practices. As I delved into this, I realized that these tools weren’t designed to be used in a pipeline at all,” Brown reveals. “People rely too much on simple release techniques, write the code themselves and just release it without formal testing. This approach is good for experiments and self-hosted prototypes, but it doesn’t lend itself to deploying enterprise-grade code.”
In order to integrate the tools into a DevOps pipeline, Web3 technologies should no longer be considered in isolation from the rest of the technology stack. Then integration points can be identified – such as integrating smart contracts into a test harness.
Microsoft expert Brown was able to build an Ethereum-based distributed application environment using Azure Pipelines with development, QA, and production releases, with the front-end application hosted on Azure Static Web Apps . Development implementations run in a private Ethereum instance on Azure Containers.
The biggest problem with this approach: deploying smart contracts in different environments. This is because smart contracts have a hard-coded address that is automatically added to the smart contract’s JSON when compiled. This requires the entire contract to be rebuilt with each deployment, requiring multiple rebuilds for each environment.
As Brown notes, this is a DevOps anti-pattern: “You should only need to compile once and add the environment-specific values at runtime. Rewrite the front-end code of the application to support an external source for the network address, was quite a bit of work This approach makes it easier to use the service when a contract address cannot be found by using an Azure function to return the address on request.
This way, Brown’s code only has to build the frontend once and can use it at any stage of the deployment pipeline. He could then use standard JavaScript testing frameworks with his application. All of the steps required to build and deploy each environment from a GitHub repository could be integrated into a single Azure pipeline, with environments being deleted after each commit. Tools like Azure Container Apps help here and allow quick deployment of build artifacts.
From this starting point, it is possible to add support for additional frameworks in any environment, as well as infrastructure-as-code tools such as Bicep and system management scripts in Azure CLI and PowerShell. It also ensures a repeatable environment and you are able to deploy a working application and all the servers and services needed to support it. When working in Azure with the Infrastructure-as-a-Service and Platform-as-a-Service tools, you can delete unused environments when they are no longer needed. This saves money and ensures that your application and its environment are distributed idempotently, with any changes to your code requiring a complete re-distribution of the entire application and supporting infrastructure.
Brown’s work shows how Web3 technologies can be integrated into a familiar enterprise environment as part of a modern application framework. There’s no need to ditch familiar tools like GitHub, Azure Devops, Azure Container Apps, or VS Code.
What is clear, however, is that the way Web3 frameworks work with environment variables and dynamic resources needs to change. They are not designed to work in a multi-stage pipeline and require modification if they are to provide the appropriate level of maturity for large-scale deployment in enterprise applications. Better telemetry is also needed to give developers a more accurate view of the performance of their apps and smart contracts.
The result is an interesting mix of familiar and new. This is good because it makes it easier for developers to adopt new technologies and integrate them into existing development processes. Companies like Microsoft can help emerging innovations mature faster by digging deeper into these technologies. (MF)
This article is based on an article from our American sister publication Infoworld.