Platform Earth aims to create a sustainable suite of microservices for the commons. The community of providers so conceived, serves both json, static html5, and federated microservices. Here we look at how we might provide servers for this content in a pragmatic way that aligns with the decentralized architecture that we envisage.
Our argument is that decentralization is a social and political process, not simply a technical one. A technical architecture will revert to a centralised one, should this be supported by conventional market incentives.
Pure P2P technology stacks, provide us tools with which we can Redecentralize the web. However they do not provide the full social stack. For that we need both pragmatix, and a path towards that end - not simply tools that facilitate the end goal.
# My server
For a server to meet these needs it needs to be as easy to run and maintain as any conventional software package - say a word processor. And just like a word-processor it needs to run locally, or to be more precise it needs to be Owned.
That is the server must have an owner that is empowered to run their application wherever they feel they would like it - either on their laptop, their mobile phone, or in The Cloud. It is only then that the psychological and social incentives will be aligned to support real federation, and data privacy.
# A docker in my pocket
Docker provides us with a technical infrastructure on top of which we can build a federated server based architecture that is flexible, and supports continuous deployment of services. The very same server can then be run and maintained on the desktop as well as the cloud.
Using docker as a form of package manager for a desktop server, may not be a conventional use of the technology, but in reality it is simply an extension of the current use of dockerisation to provide a local development environment.
1. We can take advantage of containers to provide us with optional layers of functionality 1. We can leverage development pipelines to enable continuous deployment of software services 1. Distribution is simply a matter of distributing light-weight (docker) text files 1. Single code base for servers, desktop and decentralised apps.
# Clusters and loose-coupling
Containers enable a loose-coupling of services to the federation. Instead of a single server, we can envisage multiple types of server providing different specialised services to the federation. Each server can be built using it's own appropriate software stack.
Such containers can then be composed into single deployable entities or broken up into separate server clusters enabling a range of ways to scale and deploy services.
# Possible drawbacks
We may not be able to push this line too far. Container based, docker based installation may be cumbersome, and the need for a full server based stack including the operating system, may be overkill.
However based on current experience of developing plugins for fedwiki using this environment, and the potential for fast and automated builds, this avenue looks promising.
Given a suitable container based format, there is nothing to prevent compilation pipelines that are able to create native applications on the various platforms from a central core container based image.
Container based federation hosting looks like an excellent way forwards in terms of building a more robust, scaleable, and sustainable architecture for the federation.
Only practical experience will tell if the toolchains used prove to be more of a burden than conventional package managers.