Establishing a Libre Hosting Syndicate


#1

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

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

Declarative infrastructure

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.

Official packages

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.

Industry Standards

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.

  • Indie.Host
    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.net
    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

and feel invited to ask questions or give feedback!

Mission

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.

Reference infrastructure

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.

Catalogs

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.

Hostable application

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.

Industry Standards

What is our relation to the current industry standards?

proposal

We have an opiniated vision of it:

  • kubernetes
  • flannel
  • helm charts
  • rook
  • prometheus
  • grafana
  • EFK
  • 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.

Official packages

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.

Linked Catalogs

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:

preliminary conclusion

  • 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?

Comments

Jon

2018-02-27 15-32

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?

Pierre

2018-02-27 15-35

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

Nikos

2018-02-28 09-41

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.

Laurent

2018-02-28 12-27

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


#2

I’d like to separate the syndicate, the political part outside from the tool itself.

I was thinking about LibreHosters.

Then we keep libre.sh focused on the technical bits.