Akash is a decentralized application hosting solution that went live at the beginning of March, and as I have a couple of dozen WordPress sites under my professional care, I’ve been wanting to kick the tires on this bad boy and figure out the best ways to utilize this new capability.
I’ll put the philosophical/political theories into “why decentralization” in another post; in this one I just want to describe coming to terms with the Akash deployment process.
The first piece of understanding an Akash deployment is understanding Docker. Docker is a containerization solution that is in wide use in the Web2.0 world of web hosting and production. It’s programmable software deployment on a bare OS, that is dependent on its host for just the critical basics: power, CPU scheduling, memory space and network access. All other software dependencies are included in the programming of the ‘container’, so it will run exactly the same way on any (Linux) device that runs Docker, regardless of neighboring containers or their dependencies. That’s the good news.
The bad news is that data within Docker is ‘ephemeral’. This means that while the Docker container is running, it contains your data. If it needs to be redeployed, a fresh container is created without your data. So backups become reeealy important, and it’s critical to understand this is the way Docker works.
Akash makes use of Kubernetes, which is a container orchestration system for Docker. This is more functional than Docker is, as it makes use of scheduling among several computers in order to keep containers online and connected to their data volumes. When you’re deploying on Akash, you’re negotiating with a Kubernetes-reinforced Docker system that can speak Akash.
Finally we get to Akash’s particular contribution to the deployment process. Akash makes use of the Stack Definition Language used by Kubernetes (and to a lesser extent Docker) to define the resources required by the website deployer, and allows him to load up an escrow account containing his coin in the form of the Akash Network token $AKT.
Once the terms have been proposed, provider systems place automated bids on new deployment proposals based on their available capacity. The deployer accepts a bid, creates a lease and uploads his SDL code again in the form of a YAML (literally means “YAML Ain’t Markup Language”–geek humor) deployment manifest, and the provider node starts to deploy the docker containers as described in the YAML, and the escrow account starts paying for the hosting at the agreed rate.
To sum up the process:
Install Akash deployment software
Import wallet with at least 5 $AKT in it
Create Deployment with YAML
Accept Bid, create Lease, upload YAML to Provider
Receive Akash domain endpoint to reach your app via the web (IE sobfgovqq59fhbkq4ucqkvhshk.ingress.ewr1p0.mainnet.akashian.io)
Even for a coder, the command-line toolset is a little much. In this early stage of adoption, deploying requires painstaking setting of environmental variables, copying and pasting lines of code and picking through jungles of JSON which emerge in response to the commands.
All this is standard Web2.0 operating procedure for dealing with programmatic elements such as API’s and procedure calls, and no one expects retail customers to be wading through the JSON with us early risers; instead, Akash is a system of requesting and delivering resources upon which other applications will be used to operate with much more click-and drag ease.
Devs to the Rescue
True to form, the moment a problem arises in the world of Open Source, someone will come up with a solution. Before I had even worked through the documents to try to understand the process requirements, a Twitter mention led me to Tom Beynon, a Ruby developer who had already created a web-based, Dockerized UI for deploying other applications on Akash. You can follow up with him here at his Github page, and access the software for your own deployments. Thank him for sharing his tools with us while you do so.
WordPress is Live!
Without too much further ado, mostly having to do with errors in my YAML documents, I was able to deploy this site with the following YAML code. As you glance through this, it’s formalized but quite human readable what is being requested.
The only final step to getting a functional website was to point the hostname in my DNS to the Akash domain endpoint as a CNAME. At this point, the site is decentralized with these exceptions:
Domain registration and DNS: centralized service, options are coming online for decentralized DNS and domain name registration. The risks of centralization in this area are very low, however.
Backup endpoint: this is up to the deployer how much they trust Google Drive or Dropbox to adequately hold their backups, but this usage is not something likely to be known by activists or hactivists, as it is very far in the back-end of a system. Most secure would likely be a detachable drive.