Early in the new year, AppDynamics hosted a hackathon to give employees a chance to explore technologies they were curious about, have fun, and build cross-functional relationships.
I teamed up with a group of women who were interested in researching blockchain. Other members of the team included Balwinder Kaur, Nicole Hu, Audrey Nahrvar, Jeanie Oh, and Ana Le.
There has been much speculation that blockchain will be as disruptive as the Internet revolution of the 90s. This got us thinking about what we could learn from building a dapp, a decentralized application where the backend code runs on a peer-to-peer network. We also wanted to understand the performance aspects of executing and maintaining the application on the blockchain.
A voting app struck us as a great example of a blockchain use case. As a voter, you want to be anonymous but verifiable, and you want your vote to be tamper proof. Blockchain solves these requirements in a couple of ways. It uses public key cryptography to ensure that each vote is recorded accurately. At the same time, the integrity of each transaction is safeguarded by the multiple nodes on a blockchain, making blockchain applications extremely secure. Our goal was not only to code an application but to learn the entire process of deploying smart contracts on the blockchain. We wanted to interact with the blockchain, identify the performance metrics associated with our app, and ingest those metrics into an AppDynamics dashboard. To that end, we bootstrapped a Smart Ballot dapp that initialized the contestants running in the election and tracked the total votes received by each of the contestants. We developed the application on Ganache, a personal blockchain for Ethereum for reasons I’ll explain below.
We chose the Ethereum blockchain because we thought the large and supportive community would make it easier for us to set up the development environment and publish an application during the two-day hackathon.
The next step was to use Raspberry Pi as a voting device running Web3js (an Ethereum compatible Javascript API). The end-to-end flow of our application was designed to work in the real world in the following way: Each time someone placed a vote on our voting machine, it would convert the ballot into a smart contract that was then compiled into bytecode and sent to the blockchain. The blockchain would then execute this contract, record it in a block (the equivalent of a page in a ledger book), and add the block to the blockchain. From a business perspective, the total cost of processing the smart contracts translated into the cost of registering each vote
With the end-to-end flow in place we now had the opportunity to monitor the performance aspects of the voting application. For example, the total cost of executing each smart contract could be tracked, and if it began to fluctuate in a way that didn’t match our expectations we could decide whether our implementation needed adjustment. Research into blockchain metrics led us to Geth (the Go implementation of the Ethereum protocol). We learned that Geth processes were created when we spun up an Ethereum blockchain environment. Once created, these processes kept track of arbitrary events and measured their duration. We queried a variety of metrics derived from the Geth processes through an RPC API.
One of the most important metrics we looked at was “Gas.” In the blockchain world, gas is the price of computation that is paid to individuals, known as miners, who participate in transacting on the blockchain. Gas is correlated to tera-hashes per second. When a transaction is originated, it has a gas price associated with it, allowing miners to pick and choose the most lucrative transactions. Typically, transactions vary in cost depending on the computational power they require to complete various operations. In this experiment we captured costs per transaction using gas price multiplied by the transaction volume. We also looked at “Difficulty,” which is a standard blockchain measure of how difficult it can be to find a hash below a given target. Significant departures from the baseline performance of the application triggered an alert.
Finally, we wanted to provide visibility into any network issues that could be affecting blockchain actors. We understood that any issues would clearly impact end users as well as applications relying on a blockchain transaction. To that end we captured, total requests/min and response times. Here is a view of the metrics we collected on the AppDynamics IoT dashboard:
Naturally, we encountered some glitches. The main problem we faced was creating an account for ourselves on the Ethereum blockchain. It turns out that it’s huge and not suitable for quickly getting up and running. We tried for twelve hours to download the entire Ethereum development environment before we decided to use the Ganache client.
Experimenting with a new technology is always rewarding. It was gratifying to see how easy it was to deploy AppDynamics to monitor a distributed application running on a blockchain and begin collecting useful information. It is one thing to know that metrics are available in theory, and other to see them displayed on a screen, tracking transactions as new blocks were mined and added to the chain.
