While the various technologies that have been dubbed “Web 3” are unlikely to replace the huge infrastructure and software investments we’ve made over the past three decades, there are still some interesting ones out there. The first question we need to ask is, what problems can they solve?
Web 3 proponents suggest that at heart, it is a vast set of consumer technologies that could replace the transactional foundation of the Web. I think of it as a more limited tool, capable of building blockchain technology to support a subset of enterprise applications, with a focus on electronic data interchange (EDI). Because once you strip the blockchain back to its core, it’s an immutable data structure that can be shared between untrusted partners in a trusted way. This makes it useful in supply chains where electronic documents have a contractual and legal basis that is included in international agreements and where one end of the supply chain has an indirect relationship with another.
An interesting alternative here is Microsoft’s work on proof-of-membership consensus blockchains run by consortia of untrusted organizations, offering a faster and lower-impact alternative to proof-of-work and proof-of-stake systems. At the same time, recent releases of SQL Server now provide an immutable ledger for applications that do not need to be distributed across multiple entities.
You can think of these blockchain-based services as something like the electronic equivalent of a bill of lading used to describe a ship’s cargo, which travels through different business systems without change and where you don’t know all the different entities that interact with it. Documents and Agreements. These entities can be original manufacturers, shippers, warehouses, cargo ships, customs agents, customs offices and more. All need access to the documents and many need to add their own signatures as part of a complex multi-party approval process.
We can build them into an enterprise blockchain, but we need to start thinking about how we use them within a modern development environment. We’re already building distributed systems at scale for cloud-native applications using DevOps and CI/CD platforms, so can we use these techniques for Web 3?
Using enterprise tools with blockchain
Microsoft’s Donovan Brown was tasked with looking at how developers should work with these distributed application platforms. Now part of Mark Russinovich’s CTO incubation team at Azure, Brown is best known for his DevOps work, so it was no surprise that he quickly began bringing popular Web 3 platforms into a DevOps framework. It has had some good results. I recently had a conversation with him about how he was able to leverage these technologies with enterprise tools.
If we want to make these tools ready for use in the enterprise, they need to become part of the way we build code by integrating with both our development platform and our build and test tools. It is important that the tools we use avoid the many public pitfalls associated with Web 3, especially with trade management and other key information and value flows. We don’t want a smart contract for a bill of lading that can be hijacked to change the cargo delivered to our warehouse or even diverted to another destination.
Part of the problem Brown identified was an explosion of tools that offered slightly different sets of features. It’s a landscape that makes it hard to get on board, because there’s no clear toolchain and no set of best practices to help you build that toolchain. This means that there is a need to identify mature tools that support enterprise best practices, with the intention of wrapping it in a GitHub codespace or making it available in one of Microsoft’s Dev Box virtual development environments. Otherwise it’s hard to get started, with no easy way to onboard new developers to your team.
Tool selection is part of the problem and perhaps the easiest to overcome. The biggest problem is that it’s very difficult to shoehorn these new tools into existing pipelines if you’re using development best practices. As Brown says, “As I dug deeper into it, I realized, wow, these tools weren’t even designed to be put in pipelines.” Too much reliance on common publishing techniques, writing code yourself and publishing it without formal testing. This approach is great for self-hosted tests and prototypes, but it doesn’t scale to deliver enterprise-grade code.
Building a DevOps Pipeline for Smart Contracts on Azure
How can you bring them into a devops pipeline? First, we need to stop thinking of Web 3 technologies as isolated from the rest of the enterprise application stack. Once we do, we can find points of integration, for example, putting smart contracts to an experimental use and using test-first development techniques.
Brown has now been able to build an Ethereum-based distributed application environment that uses Azure Pipelines with Dev, QA and production outputs, hosting the Azure Static Web Apps app front end. Dev deployments are performed on a private Ethereum instance in Azure containers. The biggest problem for a developer taking this approach is deploying a smart contract in different environments.
It turns out that the smart contract hard-codes an address that is automatically added to the contract JSON when it is compiled. This requires rebuilding the entire contract for each deployment, multiple rebuilds for each environment. As Brown notes, this is a devops antipattern. By adding environment-specific values at runtime you only need to compile once. This requires some work to rewrite the application front-end code to support an external source for the network address This method makes it easy to use the service when no contract address can be found, using Azure functions to provide the address when queried.
From this start, it’s possible to add support for additional frameworks to each environment, as well as infrastructure for code tools like Bicep and system management scripts in Azure CLI and PowerShell so that you have a repeatable environment and you can. To provide a ready-to-run application and all necessary servers and services to support it. Working with infrastructure-as-a-service and platform-as-a-service tools in Azure allows you to remove unused environments when they’re no longer needed, saving money and ensuring that your application and its environment are an immutable distribution, of your code. Each change requires a complete redeployment of the entire application and supporting infrastructure.
Towards a Maturity Model for Blockchain Technology
Brown’s work goes a long way in showing how Web 3 technologies can be built into a familiar enterprise environment as part of a modern application framework. No need to go beyond familiar tools—GitHub, Azure Devops, Azure Container Apps, VS Code. It is clear, however, that changes are needed in how the Web 3 framework works with environment variables and dynamic resources. They are not designed to work in a multistage pipeline, and modifications are necessary if they are to offer a level of maturity suitable for use at scale in enterprise applications. Better telemetry is needed so developers can see more clearly how their applications and contracts are performing.
The result is an interesting hybrid of the familiar and the new. This is a good thing, as it makes it easier for a developer to adopt new technologies and bring them into existing development processes. Keeping a close eye on new technologies is important for companies like Microsoft, as they can accelerate the maturation of emerging innovations. Companies can offer an incubation path from experimental to enterprise, informed by years of enterprise application development experience inside and outside of their own platform.
Copyright © 2022 IDG Communications, Inc.