Blockchain and “cloud computing” — market adoption similarities

It’s common for experts to discuss how blockchain and related technologies will someday be “larger and more impactful than the Cloud.”

They aren’t wrong; the “cloud computing” metaphor applied to blockchain and related technology is extremely apt, and most people won’t realize why, because they don’t understand “the Cloud.”

Most people believe that technologies associated with “the Cloud” are wholly modern.

Alas.

Have you ever seen the show “The Americans?”

The series takes place in the 1980’s, and features two Soviet spies, living in the United States.

My wife and I sit and fold laundry while watching these kinds of shows, because when you have a lot of children, you fold a lot of laundry.

In the episode entitled “ARPANET” (Season 2, Episode 7), the spies are asked to learn more about the DoD-funded technology (which would someday become the Internet you are currently using to read this article).

Again, this episode takes place in the 1980’s, and I’ll remind the viewer that I joined the US military and started using this same technology in the 1980’s, within a combat communications squadron, so I’m here to tell you that the episode did a decent job of accurately depicting the state of technology at the time.

Anyhoo, there’s a scene where our Soviet spies are receiving a debrief of this new technology from a professor, who makes ample references to “virtual space,” and my wife (an educator, not a technologist) turned to me and said:

“Did he just describe the Cloud?”

Well, yes. More or less, he sort of did.

The basis of what we call “the Cloud” was actually introduced decades ago, and it took a long time to reach a state of mass adoption. Literally generations, in fact.

I don’t believe that it will take generations for blockchain and related “decentralized” technologies to become similarly ubiquitous, but there is room to acknowledge that it’s not going to happen overnight, and there’s wisdom in examining the adoption of “the Cloud” to gain insight into how blockchain and related infrastructure will likely be adopted.

When an IT person says that their computing and/or storage infrastructure is “in the Cloud,” most assume this means they are using “the Internet.”

If the audience is knowledgeable about technology, they may assume the IT person is speaking of Elastic, Amazon, or Azure.

Meaning: they assume that a company is using “public infrastructure.”

However, the truth is far more nuanced.

If you dig into the industry data, it becomes clear that there’s a significant portion of “cloud infrastructure” that’s deployed on premise, in the form of virtualized computational and storage infrastructure.

What qualifies as “on premise Cloud” is used for more proprietary or sensitive data and computational loads, as well as more intimate linkages to systems that are either legacy and/or proprietary to the company, or simply data and systems which are precluded from being deployed thus due to regulatory compliance constraints.

Of course, other portions of “the Cloud” are certainly deployed on AWS or Azure, etc., but this nuanced “public/private” use of cloud infrastructure is a metaphoric foreshadowing of how I believe blockchain and related technology will be adopted by companies and communities.

While I was CTO for Bitnation, I had a unique opportunity to study the use cases for a large number of communities which aspired to use blockchain to achieve commerce and governance autonomy.

Although the Bitnation “Pangea” infrastructure (designed, built, and deployed by my engineering team) was deployed on the Ethereum blockchain, not once did I find a community that was comfortable placing all transactions on the public ledger.

Why not?

They expressed a spirit of optimism that “someday” they could use this public ledger, but in the immediate time frame they did not want their transactions reverse-engineered by anonymous parties — likely meaning: nation-state entities.

They understood their reticence represented a visceral reaction on their part, and acknowledged that the future will present more nuanced and better-understood alternatives, but at the present there is no individual or group I’ve encountered yet that is comfortable with the use of public infrastructure for “vital” services (commerce and governance).

I’ll qualify this statement: there are plenty of people who SAY they will use public infrastructure for vital commerce and governance services, but I invite you to ask them to show you precisely how and where they are CURRENTLY using it.

My point is there’s a sizable delta between what people claim and what they are currently doing.

What they CLAIM is that they are whole hog invested in public ledgers.

What they are DOING is actually wise: being conservative about the stewardship of their vital services, and continuing to rely upon tested and known technologies, even if they aren’t decentralized.

This is why much of our commerce and governance platform for 214 Alpha is built on private blockchains, but with an architecture that will present what we call ‘gateways” into public blockchains and related technologies.

The way we see it, blockchain technology and related “decentralized” industries are very similar to the “Internet” industry in 1993 or so: a lot of promising ideas, but not enough actual applications/usage, and therefore almost no practical experience within the user community which may inform decisions regarding critical infrastructure.

To give an explicit scenario:

In 1994, the Netscape Navigator browser was released, and it was the first time people could actually begin to conceptualize the utility of this “web.”

Literally millions of people downloaded and began using Netscape, and it transformed people’s understanding in just 12–18 months.

A similar event has not really happened yet as it pertains to blockchain technology, with the notable exception being Coinbase and its consumer-friendly lens into the weird world of crypto-currencies.

But even considering that, crypto-currencies are such a substantially narrow representation of blockchain utility that it’s sad that most people believe that blockchain = bitcoin, if they’ve even heard of blockchain at all.

We have a long way to go, and we have only barely started.

At 214 Alpha we feel people will likely need to get comfortable with the use of this technology from within a framework that’s accessible, familiar, and perceived as safe.

Kind of like a wading pool.

“Cloud infrastructure” likewise got its start as companies and individuals began to experiment with virtualized infrastructure: on premise at first, and by degrees thereafter, gradually increasingly in the more public domain.

We believe that early adopters of this technology will get comfortable in their wading pools, and then venture step by step into the use of public infrastructure, through the gateways we and other vendors will provide.

An example of this may be a public/private reputation value per person, which might reflect their accrued reputation score within the community, and a less nuanced version of the same score available for examination by those within other circles/communities.

Give it 15 or so years, maybe a little more, and we may expect to see far more infrastructure on the public blockchains — hopefully by then they will have addressed the ghastly use of electricity, perhaps through the use of reversible computing or other metaphors, so the infrastructure may become more “anti-fragile.”

What’s “antifragile”? To quote Wiki:

“Antifragility is a property of systems that increase in capability to thrive as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures. It is a concept developed by Professor Nassim Nicholas Taleb in his book, Antifragile, and in technical paper.”

It’s common for enthusiasts of blockchain and related technology to describe how it could help the developing world, but similarly common for them to gloss over the fact that these technologies are frequently fragile, temperamental, and most def not antifragile.

For mass adoption to occur, these services will need to deliver consumer-class performance and ease-of-use using substandard infrastructure over crappy communication linkages.

Remember what it was like to use mobile web in 1998? Did your mobile device support this feature in 1998? I’ll bet not.

How about in 2008? 10 years later.

How well could your mobile device support access to the company intranet file share (likely using virtualized storage) in 2008? I’ll bet not very well.

(Virutalized storage is a component of cloud infrastructure).

How about in 2019? How well can you access Google apps via mobile when your phone has one bar connectivity?

(Google apps are a cloud-based computing and storage technology).

These technologies will be adopted in steps, and each step will take time.

These steps will necessitate a nuanced and pragmatic mix of traditional infrastructure and tentative introductions of new technologies, with each iteration reflecting a trade-off of performance, ease of use, stability, and so on.

We’ll get there, but it’s going to take a while, and the path of least resistance is actually the one that’s most challenging: through the lens of your community’s least technical user, because if you make it easy for them to understand, then you are golden for the rest of the community.