Solving for the Biggest Risk in Web3 with an Open Deployment Layer
Open Source vs Open Backend: The risks of centralized services as systemic failure points for dApps, and how build resilient dApps with an agnostic open deployment layer.
or
Why Web3 isn’t going mainstream because the code that powers it is controlled by greedy middlemen.
Problem 1: API Risk
TL:DR: Web3 devs take shortcuts to glue together dApps quickly using VC backed centralized API services
Most of these services have unsustainable business models. Their headcount is reliant on their ability to fundraise. The math is not hard to calculate their runway.
Headcount x ~10k USD (mix of US and overseas workforce) X 2 for additional OPEX + cloud burn = monthly burn
Eg. 50 employees = 500k month x 2 or 1m/month. If you raised 24m in 2022 then either raise more by the end of 2024 or go under.
Yes they could in theory have revenue to extend indefinitely but c’mon this is web3 - all promise no usage.. yet
Problem 2: Source Risk
TL:DR: Closed source or not fully open source = systemic vendor risk
Totally Closed Source
This is where you call api.vcbackedservice.com and receive back some useful data. Could be RPC data, or price feeds, etc. This could also be fully fledged WYSIWYG Squarespace like Web3 services.
Caveat: Squarespace is a great company. People don’t usually worry about their website poof disappearing because Squarespace makes money and has a good survivability bias from being in business for so long.
With Web3 there could in theory be onchain revenue to back the survivability of these closed services - but again they get paid as a fiat SaaS black box so there is no way to really know.
Examples: Vottun, Magic Wallet, Bonfire.xyz
Open Front Closed Back
AKA party in the frontend, closed in the backend
These are open SDK services with easy frontend tooling to help devs get started easier. Example: Ethers.js is hard to use to sync natively. So instead use this one simple SDK to call a centralized service instead.
On the surface, such solutions seem totally open source.
There is a Github with tons of activity.
To get started navigate to a centralized server to generate a centralized DRM secret key to use all of the amazing tools.
Then input said API secret into your dApp and boom easy days ahead!
Has anyone ever considered what happens if said service ever ceases to exist? How would a dApp go about switching out one provider for the next? Is it even possible to change an engine on your dApp airplane mid flight without crashing..
Examples: Every dApp infra layer company in Web3
Problem 3: Cloud Risk
So you’ve glued together a bunch of centralized VC backed APIs to build your dApp - now what?
Where are you going to run said dApp? The big three GCP, Azure, AWS?
What if they don’t like you and turn you off?
What if they charge such extortionate rates to cover their H100 buying spree you’ll go bankrupt paying your cloud bills?
Where are the Terraform scripts and other devops tooling to help you migrate from one cloud to the next?
Enterprises aren’t dumb
They’ll build a toy quickly on a closed system, but will not bet the farm on a small closed source vendor.
Size matters. Once a service reaches too big to fail status, then sure relying on their closed backend becomes an easier business decision. But who in Web3 has achieved such a scale? Answer: Alas only Google has.
Instead of complaining for an entire article, why don’t we go about solving this mess in a sustainable open source way.
Solution: Agnostic Docker Deployment Layer
How can we possibly solve for these 3 huge problems: API risk, Source risk, and Cloud risk all in one fell swoop?
DOCKER BABY!
What is Docker? A centralized container building software (but hey at least it’s publicly traded)
