Here we explore how we might implement a microservice architecture in a federated way.
# First things
The first thing to note is that there really is no problem simply finding a local reset server and manually adding these addresses to software so that your local wiki knows where to find local services - nothing too fancy is required at this stage. Automation and load balancing can come later.
# Micropayments Micropayments are a natural fit for federated microservices. The payment do not have to be, or at least start micro - but they should be seamless and automated. We imagine their use as part of a sustainable commons for social hosting of wiki farms. We call this initiative: - WISP
# Round Robin DNS
A first thought is that we could use round-robin dns as an easy initial implementation.
In its simplest implementation, Round-robin DNS works by responding to DNS requests not only with a single potential IP address, but with one out of a list of potential IP addresses corresponding to several servers that host identical services.
Although easy to implement, round robin DNS has problematic drawbacks, such as those arising from record caching in the DNS hierarchy itself, as well as client-side address caching and reuse, the combination of which can be difficult to manage.
Round robin DNS should not solely be relied upon for service availability. If a service at one of the addresses in the list fails, the DNS will continue to hand out that address and clients will still attempt to reach the inoperable service.
# Implementation
If we assign a single microservice which is designed to simply rotate DNS setting for a domain (passed as a parameter to that service).
After a n calls for example to a micorservice "echo" we can simply call the Robin Micorservice to change the DNS settings for the rest API route to the "echo" microservice.
We can then have another Round Microservice whose job it is to rotate a list of functioning IP addresses for a given microservice. The Round Microservice would ping each of the services in it's list for a given microservice, and see if they are online and functioning.
It could also accept calls to add or delete items to the list (baisc CRUD operations), and serve as a framework for regularly and rondomly testing the microservices on offer.
Given that we already have a full API for DNS servers on both Digital Ocean and Dynadot, creating the Round-robin Microservices would not be difficult.
# Alternative implementations
We could simply maintain lists of available services in wiki. The wiki client itself can then choose a round-robin IP address for the transporter from a list that either it itself stores (in it's markup} or that if fetches from a Wiki JSON Object.
The latter has the advantage in that is comes with it's own RESTful service that would allow server side round robin rotation of the ordered JSON using the same sort of mechanism as above.