libre.sh is developing out of indie.host together with ecobytes.net into a Libre Hosting Syndicate.
Here @pierreozoux and me want to share with you a whitepaper that outlines the mission of such another collective and would like to invite your comments into:
The document as of now is pasted below for reference and searchability:
Context: description for an OpenCollective Page for libre.sh
The aim of the libre.sh collective is to help hosting providers all around the world and to create automatisation examples for bootstraping them in localised, small communities. We are united Site-Reliability Engineers (SREs) and wish to bring better hosting practices to not-for-profit civic initiatives.
Libre Hosting Syndicate
We are a collective of hosters that shares the vision on how hosting should be done:
- with declarative infrastructure
- by providing official packages
- and following industry standards
We now have the tools to stop ssh’ing into servers and doing our black magic to heal them.
Instead, we can now use declarative infrastructure and make collaboration possible by design.
That’s why we promote declarative infrastructure.
Remember the Presentation of the FreedomBox from James Vasile? The idea to push everything upstream to Debian is a powerful idea, and we want to pursue this vision by constructing reproducible builds of the whole of an infrastructure’s inventory.
We want to lower the price of hosting, and improve reliability. There are not many ways of doing it, we have to use enterprise grade techonology.
Nowadays the open source tools for hosting is a thriving market, so let’s take the opportunity to build on that!
Who we are and how to contact us
These collectives endorse this libre.sh founding charter:
If you wish to endorse this document, sign with the name of your organisation here.
If you are wondering about IndieHosters, the Libre Hosting Syndicate it is a reboot of the networking idea behind. IndieHosters will turn into Indie.Host and be one of the hosters within the libre.sh collective.
Ecobytes is a community-led hosting association which focuses on ecological practicioners and political activists alike. We maintain infrastructure for the common good and help to coordinate transformative software development processes.
- … your group?
To participate in the conversation, join us in the
- libre.sh forum for deliberate, slow discussion
#libre.shmatrix chat for reactive, quick discussion
- libre.sh rocket chat for the indie.host perspective.
and feel invited to ask questions or give feedback!
Our mission is to help hosters focus more on their job: helping end users.
With the power of the union we identified many possible ways to standardize and collaborate:
- reference infrastructure
- application and service provider catalog
In order to achieve this, we will need help to fund the various missions.
The functional requirements
To move forward with implementing an environment supportive for this endeavour, we intend to comply with the following functional requirements.
We want to build and maintain a reference design on the current best practices for hosters.
As hosters that use free software and care about end user rights, we can’t deploy our software on popular cloud providers. So it means, we need to deploy it on bare metal. As most of the industry is shifting to cloud providers, it comes with some challenges to deploy a standardized and secure infrastructure on physical servers.
We want to make this process easier.
Another recurring issue: How do we list the software we host in a store?
A connected issue for free software developers is how to list service providers.
We call those catalogs, and we want to work on this topic. We already have some ideas on the way to solve it.
A hostable application is an application designed for hoster too.
That means multiple things :
- an application that can be easily configured via file system rather than via web interface only
- an application that can be backuped and restored easily and whithout necessarily backup all the source files since this ones can be retrived via an official repository
- an application that follows the 12 factor as much as possible
- an application that can be updated not only via web interface
We have to work with publisher to make this happen.
The technical requirements
Technical communities are invited to comment and build from these technical requirements we are aware of. Below you find an introduction to mandatory, testable components which make up a libre hoster.
What is our relation to the current industry standards?
We have an opiniated vision of it:
- helm charts
- nginx ingress
It is the current standard to boot a perfect hosting solution for free software.
You don’t need to use the full stack, this is just our reference design.
You can use other components, as long as we collaborate on helm charts, it is the most important.
Of course, we can develop our little hacks locally on how to install this or that software, it is fast.
It takes more time to create an official Docker image. But once done, then we can collaborate with millions of other users.
So we’ll promote the use of official packages:
To go back to the freedombox parallel, our OS of choice is kubernetes, and our package manager is helm. This environment supports SREs in creating predictable environments for building distributed software applications.
Backup and Restore
Part of our work on official packages, we will standardize backup and restore procedures.
We already do it (poorly) for http://libre.sh but the idea here is to push helm charts to provide a standard way.
We think that Linked Data is the way to solve the catalog problem, and we’ll lobby software developers and hosters to do so.
How to move on?
Since we are already doing all of this in our free time, it is a good question to ask how to find funding for these activities. We want to avoid ever-impending burnout and commit the neccessary work in a professional manner. Therefore we are:
- building a community of infrastructure maintainers that shares experience
- looking for funding, not only through an OpenCollective entry for libre.sh, but also by actively approaching funding institutions
- inviting for feedback from the wider community of libre hosters
- collectively writing this charter for a libre hosting syndicate
- … your idea?
Unions are usually here for workers to represent them in contract negotiations with employers. They are also called syndicates. The term has also been adapted for housing cooperatives under the umbrella organisation https://www.syndikat.org/de/
Libre hosting syndicate?
It is a bit the idea, but well, this is just an idea.
I just want to convey the idea of hosters that own their production mean.
I’m thinking that this is kind of lobby thing.
Unite together behind a brand to be stronger.
syndicate is nice also
yes, I see a lot of technical preferences that I wouldn’t expect to see in Federation/Union document. For instance we tend to use CentOS, instead and we have good reasons to do so. I’d expect a document like this to focus more on principles and values.
Great for the mission (help hosters focus more on their job: helping end users). We waste times managing server and apps and we have not time to assist users changing their habits. Why ? Not enough contributors to manage servers, to create and maintain app packages. We have to share technical ressources.
So my thoughts : Libre Hosting Union should focus to build a standardize solution for deploying an app catalog : create the solution and the catalog. Hosters contribute to the solution, deploy it and try locally to promote ready-to-use app for end users. Cloudron is the closest solution to this idea.
So Backup/Restore is not enough : Upgrade and Migrate is required. We waste time upgrading app package already deployed. End users need to be reassured about continuity of service if hoster stops the service. With the Union, the hoster could be migrate packages already deployed to another hoster.
I’m wondering about bare metal and kubernetes.
First, cloud solutions are “Infrastructure as a service” and provide tools to save time. It’s expensive but a way to help a new hoster go faster before evangelizing end users.
Secondly Kubernetes is “complicated” (but i never use it). By using it, there is a risk : the hoster should have a person in his team with the kubernetes skill (and it’s a rare skill). It should be hidden for the hoster. Example : I use sloppy.io and it’s really an easy way to deploy an app. Inspirational.
Third, I’m not sure if scalable app is required (and so Kubernetes). Needs of our end users are small. Traffic is small. No need to have a big SLA. One server for N apps using X docker image is enough. Server is full ? We create a new server to deployer more apps. Server failed ? With the ready-to-install solution, 10mn to create a new server and install the backup of the apps.
I hope helping the reboot brainstorm and writing an understandable english