The Holo vision: Serverless 2.0
Disclaimer: This information is based on my own research and I make no guarantees about the correctness or fit for any particular use. Let me know in the comments if you have something constructive to add, but don’t freak out, OK? 😉
Holo is an ambitious project to build out a new type of internet infrastructure on top of the Holochain technology.
Holo is currently up for ICO after a successful crowdfunding campaign to develop and ship Holo hosts.
At a low level, the Holo project is a bridge from the internet (browsers, DNS, etc.) to hosts running the Holochain software. This will allow end-users to interact with apps on the network through their web browser.
At a high level though, the Holo paves the way for a totally new breed of serverless web applications and business models.
Who needs a server anyway?
Every year web applications become more interactive and dynamic, packed with rich media and realtime p2p features.
Servers have provided surprisingly little to facilitate this trend, due in part to fundamental design limitations imposed by their role:
- Everything is a request/response (fixed protocols)
- Communication is over a global network (latency)
- Data must be co-ordinated (complexity)
Consequently, most innovation server-side has focussed on raw performance, scalability, and ops improvements.
Meanwhile, the client-side web is nearly unrecognisable from its humble beginnings. Here is a short list of features that each reinvented the user experience, that were either absent or crippled when I started my career:
- Vector/Canvas graphics
- Audio/Video elements
- Most async tools, standardised events, DOM Observers and multithreading
- Hardware accelerated graphics/animations
- Fonts
- Responsive design APIs
- Internationalisation/Accessibility
- Websockets/Realtime networking
For the most part, as clients become more powerful they can handle more of their own processing locally and even communicate directly P2P with other clients.
We see the traditional monolithic server make way to ever slimmer processes, each picking up some tiny leftovers that our fattened clients haven’t quite consumed yet. This trend has nice buzzwords like “serverless” and “microservices” that we can plot on a graph.
So the obvious question. What can’t a web client do?
As it turns out, not as much as you might think:
- Application security — Identity management, API layers, cryptography, etc.
- Data validation/storage — Databases, file systems, etc.
- Long running processes — Sending emails, queue processing, etc.
These three roles can typically be fully decoupled. We can easily setup one server issuing authentication tokens while another churns through a backlog of emails to send out. This decoupling is a powerful enabler and driving force behind the adoption of serverless and microservice architectures.
Where Serverless falls short today
Just like wireless internet has wires somewhere, serverless architectures still have servers somewhere.
What ‘serverless’ really means is that, as a developer you don’t have to think about those servers. You just focus on code.
The most popular serverless options are all built on the cloud products offered by the biggest players — AWS, Microsoft, IBM and Google as commercial products. There are other “indie” options such as stdlib and webtask.io and open source clones like Kubeless.io but the market is still pretty limited.
While it’s fair to say the technology is still all very new and the situation will improve over time, the reality is that right now, to do this well requires highly abstracted software platforms deployed on cloud style infrastructure. This all requires serious capital and/or technical knowhow to maintain.
The serverless trend is awesome for developers who “just want to code” but shitty for the overall decentralisation of the internet. Developers can also get lumped with a nasty refactor if they want to migrate their code to another vendor. Serverless platforms come with vendor specific logic, walled gardens, pricing and contracts, leading to the rise of toolkits and middlemen attempting to paper over the rough edges.
Serverless compute also shares the same regulatory hurdles as the base cloud computing platform. For businesses looking to expand overseas, or located in less economically strong or populous regions, this can be a real pain. Vendors often charge a premium, offer limited services or no local data centres at all in many regions, yet many local lawmakers still expect data to be stored and processed securely within national borders. In many locations sensitive and classified data such as government, medical or legal records can be difficult or impossible to store in a cloud environment without legal consequences.
Holo as Serverless 2.0
All Holochain applications (which Holo is based on) disconnected from the internet look a lot like a local serverless setup:
- A key/value or document data store
- JavaScript functions to access the data store and expose API endpoints
- A Single Page Application (SPA) client served by the app
It’s easy to imagine how applications could be built on this stack, as many applications are already built on this stack today.
A direct AWS analogy might look something like:
- DynamoDB data store
- API Gateway + Lambda
- React JS front end served by S3/Cloudfront
The neat thing about Holochain is that when it connects to the internet, the data marked as “public” in the key/value store is synced with everyone else running the same version of the app. This sync works in the same way as bittorrent, with some extra logic to facilitate security and performance, so it can be confidently used as a database layer.
After your app is connected, your JavaScript functions run against both your private data (only on the current computer) and the shared data (synced over the network). Large file assets, such as video and audio, are sharded and shared exactly like bittorrent files.
The network you connect to for sharing this data is determined by the combination (hash) of your codebase (e.g. package.json + yarn.lock) and your app config (dna.json) file. This guarantees that everyone on the same network is running the same code, with the same network config, allowing the work of verifying and storing data to be shared across participants.
Your SPA can’t tell the difference between an AWS backend or a Holochain backend at this point, except that Holochain is sitting on http://localhost:8000 while AWS has a nice HTTPS protected, custom domain backed by a global CDN…
If you’re building a Holochain app for an OS like a mobile app or an Electron application then this might be fine, but it’s a total showstopper for anything browser based.
This is where Holo comes in.
Holo connects existing web infrastructure like DNS and HTTPS to route web requests to a decentralised network of hosts. Apps wanting to leverage Holo can configure minimum requirements for their hosts, from criteria such as:
- price
- uptime
- latency
- throughput
- processing speed
- geographical location
- bulk storage capacities
- relationship / trust metrics
- industry/regulatory certifications/compliance (PCI-DSS, HIPAA, etc.)
This allows developers to always get the best possible deal on compliant hardware and guarantee service continuity, even in the face of multiple vendors being simultaneously wiped out.
For a developer building the next wikipedia, it might be an advantage to spread across thousands of low spec/security boxes sitting in garages and TV units. If you’re working with legal/medical/financial records you undoubtably have a list of stringent security and legislative requirements each host must fulfil.
The pre-ICO crowdfunding campaign raised ~$650k for preconfigured public boxes, enough to release at least 1000 servers into the wild at launch.
There are benefits for hosts too. A data centre can analyse a gap in the market from aggregate usage data, hit compliance requirements, then start generating revenue immediately. No enterprise sales cycles or long term support/SLA contracts required.
To prove compliance, a host would work through an audit/attestation process identical to the existing audits required by many of these certifications. After the audit, a digitally issued cryptographic signature is provided to the host, allowing it to participate in the premium network. The digital signature would expire as the next audit is due, providing an iron clad guarantee that regular audits are being conducted.
Getting paid by Holo
Holo is launching with a new cryptocurrency called Fuel. This will be provided as a Holo app with an API.
As your Holo app consumes network resources the Fuel app automatically triggers micropayments to the hosts and the Holo organisation.
If you want to generate revenue for yourself or facilitate (micro)payments between your users, simply bridge to the Holo fuel app from your standard Holo functions. Every item of data in the network is cryptographically signed by the originating user, so rewarding artists, musicians, authors, creatives or anyone else for providing great content is really easy.
Alternatively you can create your own cryptocurrency, ICO style, as a new Holo app. Simply fork or use the Fuel app as a reference implementation to get started.
If you want to build a decentralised credit card system on PCI-DSS compliant Holo hosts, please do it! that would be awesome 😃
Identity on Holo
Like all cryptocurrencies, Holo(chain) is backed by public/private key pairs.
Unlike most other cryptocurrencies, there is no intention that users remain anonymous/pseudonymous in the system.
There is a distributed key/identity management Holochain application to allow for native Single Sign On (SSO) style identities to be shared across other applications through a bridge.
OAuth and auth token (e.g. JWT) support is on the roadmap for the identity management systems, so integration with existing social logins etc. should all be possible.
Open questions (queue processing mostly…)
Of the three initial services provided by servers - security, storage, processing - the third is least fleshed out in the Holo literature/roadmap.
The core principles of Holochain require that compute is distributed and implements eventually consistent logic (CALM, specifically). It’s not immediately obvious how this might be reconciled with the idea of a queue with certain guarantees like “each item is processed once and only once” and “First In First Out (FIFO) ordering”.
The problem here is that queues are centrally co-ordinated and are linear in some way — often the result of processing a queue item is some irrevocable, unique action like “send email” or “update data”. Meanwhile, data shared between Holochain apps can be sent to many users in any order over a long period of time…
Luckily each item of data is always committed and verified locally to someone’s computer before it is allowed to be shared on the network. In many situations this distinction between committing locally and sharing publicly should be enough to facilitate “once off” tasks, but probably won’t cover every possible use-case.
The nice thing about the decoupled serverless/SPA approach is that we’re not wedded to Holochain for every aspect of our application. It’s always possible to build Holo app UIs that hit standard serverless endpoints for niche uses.
Preparing for Holo
While Holochain is live and has years of development behind it, Holo is still only halfway through the ICO. Much of what is described in this article is aspirational only at this stage.
The only difference between a Holochain and Holo app, from a development perspective, should be minor configuration updates to deploy to the Holo network.
The native testing harness and CLI tools provided by Holochain allows for simulating multiple users simultaneously on your local environment.
There are community efforts towards more sophisticated multi-user setups on a local environment, even allowing for “Holo lite” style deployments by proxying agents through standard hosting environments.
All this means that you can develop your SPA locally using the Holochain web server and be ready on day 1 for Holo launch!
