The Quest For Zero Maintenance - Blockchain As A Failover

Your tests have passed, you’ve pushed to production and your build has been successful. You’re done, right? Not quite. Things break. API’s you rely on change and any host of unforeseen factors can take your project offline. Like all things, running code in production comes with the burden of maintenance.

Well resourced tech products have this covered. SRE’s keep things ticking along and roadmaps cater for deprecation and migration, but what about things which don’t make money? Things that exist purely for the hell of it? Things that don’t have a financial incentive? Things that exist purely out of the goodwill of a community that want to keep them alive?

I’ve thought about this question recently as I was moving the hosting for this site from Vercel to Cloudflare Pages in order to avoid bandwidth caps. I’m happy to do the maintenance, but what happens if I die? How does it survive? How do we build software that doesn’t fail when we’re not there to fix it?

The answer to that question is very simple, we can’t. There are an infinite number of things that can go wrong, and it’s impossible to plan for all of them, but what’s the most robust way to reasonably architect our applications if we want to minimise that surface?

A good place to start would be to look at every single source of failure and build in some redundancy at each. That’s no easy task. You might start thinking about your front end serving, api layer and database - but those are just a few layers, and they’re just the ones that you have direct control over. What about the networking layers? Web and browser APIs? Legal requirements? Even then, the alternatives you conjure up for each of these failure modes may have the same systemic exposure as your original architecture.

A compelling alternative to this nightmare is to try and ignore the architecture altogether.

Why think about building redundancy for every single source of failure in your application when you can just open source your code and allow others to rebuild, and tweak it, at will? You don’t have to think about web APIs changing, cloud providers maintaining their existing plans and conforming to new legal standards that you hadn’t previously anticipated. You can move the onus of maintenance from a small number of individuals to a wider community and, If what you’ve created is important enough, someone else can pick up the tab of the debt you’ve left behind.

However, that only goes part of the way to addressing the problem. When you rely on open source:

• You lose state when you rebuild an application from its source (unless your application is purely static).
• You still rely on a third party to host your code - exposing another potential failure mode.
• Someone still has to volunteer to shoulder the cost of serving your application.
• There’s a technical barrier to recompiling your code, that only a (smallish) subset of people can overcome and which requires a non-trivial level of effort.

So you need an alternative to open sourcing your code which preserves state, keeps your application accessible to an end user without relying on it being rebuilt and doesn’t require the goodwill of a third party to serve your application.

That sounds like a blockchain use case.

Moving your application fully on chain moves your dependencies from corporations to protocols; preserving state openly, providing access by default and making your applications survival conditional on the durability of the chain - not the temporary offering of a centralised third party.

Those are the benefits, but what about the drawbacks?

A blockchain is essentially a slow, less scalable, eventually consistent database. Centralised systems are generally quicker, more scalable, cheaper and more familiar - all things users and developers care about.

Those tradeoffs may be worth it for a set of use cases that can only exist as a result of decentralised protocols (digital scarcity, decentralised finance, privacy), but making your product experience worse because your hosting provider might change their plan in a few years? That’s not a particularly compelling proposition, and it’s not one users generally opted for when web3 companies promised the re-imagination of every current company on a blockchain, but what about as a failover?

You could benefit from all the advantages of a centralised approach until you need the durability of your decentralised fallback - a shadow architecture that has a risk profile which is mostly uncorrelated with the centralised systems that you rely on.

That resolves the tradeoffs for users, but the barrier now becomes the increased complexity in developing that software. It’s just not worth it to duplicate and adapt your infrastructure unless there’s an immediate need, but does that need to be the case?

We have decentralised equivalents for so many services; ENS for DNS, smart contracts for compute, IPFS for storage, wallets for auth - and we’ve been pouring so attention into building with them from scratch that we haven’t thought too much about their capabilities in the context of backwards compatibility. Maybe the right approach isn’t to rebuild our existing products, but to focus on continuously porting them to an infrastructure that augments our existing approaches as opposed to replacing them.

If that’s the case we’ve been viewing blockchain wrong. It’s not a fundamental paradigm shift in how we build our software. It’s a methodology for developing new capabilities that can’t exist in trust based systems and a hedge against our existing capabilities, that thrive in those systems, from failing.