Integrate Web 3 technologies with Azure Devops

While the various technologies that make up what has been dubbed “Web 3” are unlikely to replace the massive infrastructure and software investments we’ve made over the past three decades, there’s still something interesting in them. The first question we have to ask is, what problem do they solve?

Proponents of Web 3 believe that it is essentially a set of mass consumer technologies that can replace the basis of web transactions. I see it as a more limited tool capable of being built on top of blockchain technology to support a subset of enterprise applications focused on electronic data interchange (EDI). That’s because once you strip away the blockchain, it’s an immutable data structure that can be shared in a trusted manner between untrusted partners. This makes it useful in supply chains where electronic documents have a contractual and legal basis set out in international treaties and where one end of the supply chain has only an indirect relationship to the other.

Microsoft’s work on a proof-of-member consensus blockchain run by a consortium of untrusted organizations is an interesting option that offers a fast and low-impact alternative to proof-of-work and proof-of-stake systems. At the same time, the recently released SQL Server now provides an immutable ledger for applications that do not need to be distributed among different entities.

You can think of these blockchain-based services as the electronic equivalent of a bill of lading used to describe a ship’s cargo, which can be transmitted without change across a number of different business systems, and you may not know all of the people you interact with. Various physical documents and contracts. These entities can be any original manufacturer, shipper, warehouse, cargo ship, customs agent, customs office, etc. All need access to the documents, and many need to add their signatures as part of a complex, multi-party approval process.

We can build them into enterprise blockchains, but we need to start thinking about how to use them in a modern development environment. We are already using devops and CI/CD platforms to build distributed systems at scale for cloud native applications, so can we use these technologies for Web 3?

Using Enterprise Tools with Blockchain

Microsoft’s Donovan Brown was tasked with studying how developers should use these distributed application platforms. Brown is now part of Mark Russinovich’s Azure CTO incubation team and is known for his devops work, so it’s no surprise that he soon started bringing popular Web 3 platforms into the devops framework. He has had some good results. I recently spoke with him about how he uses these technologies in conjunction with enterprise tools.

If we’re going to get these tools ready for use in the enterprise, they need to be part of the way we build code, integrated with our development platforms and our build and test tools. Importantly, the tools we use can avoid many of the common disasters associated with Web 3, especially when it comes to handling business and other critical information and value streams. We don’t want the bill of lading’s smart contract to be hijacked to alter the delivery to our warehouse or even transfer to another destination.

Part of the problem Brown identified was the explosion of tools that offered slightly different feature sets. It’s a difficult environment to join because there’s no obvious toolchain, and no real set of best practices to help you build that. This means identifying mature tools that support enterprise best practices, with the goal of wrapping them in a GitHub Codespace or making them available in one of Microsoft’s Dev Box virtual development environments. Otherwise it’s hard to get started and there’s no easy path to onboard new developers on the team.

Choosing a tool is only part of the problem, and it’s probably the easiest to overcome. The biggest problem is that if you’re using development best practices, it’s hard to shoehorn these new tools into your existing pipeline. As Brown puts it, “When I dug into it, I realized, wow, these tools weren’t even designed to be put in the pipeline.” Too much reliance on easy release techniques, writing code yourself, and directly release. This approach is great for self-hosting experiments and prototypes, but doesn’t scale to deliver enterprise-grade code.

Build a DevOps pipeline for smart contracts in Azure

How to bring them into the devops pipeline? First, we need to stop isolating Web 3 technologies from the rest of the enterprise application stack. Once we do that, we can find integration points, for example, putting smart contracts into test harnesses and using test-first development techniques.

Brown has now been able to build an Ethereum-based distributed application environment that uses Azure Pipelines for development, QA, and production output, with Azure Static Web Apps hosting the application front end. Development deployments run in private Ethereum instances on Azure Containers. The biggest problem faced by developers taking this approach is deploying smart contracts to different environments.

It turns out that the smart contract hardcodes an address which is automatically added to the contract JSON at compile time. This requires rebuilding the entire contract on every deployment, requiring multiple rebuilds for each environment. As Brown pointed out, this is a devops anti-pattern. You should only need to compile once, adding environment-specific values ​​at runtime. This required some work to rewrite the application front-end code to support external sources of network addresses. This approach makes it easier to use the service when the contract address cannot be found, and use Azure Functions to pass the address when it is queried.

This allows Brown’s code to build the frontend only once, allowing it to be used at every stage of the deployment pipeline. He can then use standard JavaScript testing frameworks in his application. All the steps required to build and deploy each environment from a GitHub repository can be built into a single Azure Pipeline, with the environment removed as each step is validated. Tools like Azure Container Apps help here, allowing rapid deployment of build artifacts.

From here, support for other frameworks can be added in each environment, along with code tools like Bicep and infrastructure like Azure CLI and system management scripts in PowerShell to ensure you have repeatable environments and can deliver anytime The application available and all the servers and services required to support it. Working in Azure with infrastructure-as-a-service and platform-as-a-service tools allows you to delete unused environments after they are no longer needed, saving money and ensuring that your application and its environments are idempotently distributed, with every Changes require 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 familiar enterprise environments as part of a modern application framework. No need to step out of familiar tools – GitHub, Azure Devops, Azure Container Apps, VS Code. However, it’s clear that changes are necessary in the way Web 3 frameworks use environment variables and dynamic resources. They were not designed to work in multi-stage pipelines and would have to change if they were to provide the appropriate level of maturity for use at scale in enterprise applications. There is also a need for better telemetry so that developers can have a clearer picture of how their applications and contracts are performing.

The result is an interesting mix of the familiar and the new. This is a good thing because it makes it easier for developers to adopt new technologies and introduce them into existing development processes. It is important for a company like Microsoft to delve into new technologies because they can accelerate the maturation of emerging innovations. The company can offer an incubation path from experimentation to enterprise, built on years of enterprise application development experience both on and off its own platform.

Copyright © 2022 IDG Communications, Inc.

Leave a Reply

Your email address will not be published. Required fields are marked *