Movement hosting infrastructure
Introduction round
Everyone answers "Infrastructure is":
Running water
Tool of communication with our networks
Collaborate across distances
The people who are part of it
People
Independent sustainability
All the tools and systems that we use to make our work happen
Skeleton for everything else to work
Interoperable
Collective
It facilitates communications between people
A series of tools
the physical and material system that allows data and water to be distributed
technology that it has already been developed
tools and systems that we control and trust
system and processes,and don't necessarily have to do with tech
the power of a community to communicate onits own terms
During the past few years there have been a lot of conversations about infrastructure: movement ifnrastructure, feminist infrastructure, etc.
We are trying to find how to have mutual support and solidarity.
Today we want to talk about a part of it, the technology.
- - - - What kind of tech infrastructure to build for movements?
How to adapt tech that we see used successfully by corporations, for the benefit of our movements?
We have a few ideas.
1) Contrainers: a self contained operating system.
You make changes, and automatically they get pushed to a registry. It's a away to encapsulate your containers and put them in the network.
What does this solve? Example: I have a server and then something happens, I need to update or configure something and it's a lot of work, and there are library compatibility issues.
In this way: you just have to find the right script and you don't risk to break everything when you want to configure or update something.
2) Infrastructure as code
Overtime now, you get snowflakes servers. You are not sure how to reproduce them if you needed to.
We don't like snowflakes servers. We like phoenix servers! It they get hit by lightning or the governments takes them down, they can come back seamelessly.
They are ephemeral servers: you have configured the logic of all the ways in whcih that servers need to be set up. And if the machine dies, you re-run the program, and everything is set up back again as it is supposed to. Your whole infrastructure is expressed as code. there is source control of physical machines.
3) IAAS: Infrastructure as a service ("cloudy stuff")
Hardware is abstracted away. You have command lines that you can run to create virtual machine.
We surely want the ideas 1 + 2. Number 3 is a maybe. - - - -
The possible ways to work out the above: A small, B medium, C big.
A) Minimum viable solution to use containers and infrastrcture as code, no cloudy stuff needed.
You have some concise configuration. The images of containers get deployed to your hardware.
Code to git > testing > the image goes to the registry [git,test, registtry:these three parts can be shared] > then we are able to download these images in the correct machines where they need to be.
In addition to the above, we want to encode best practices: network security (seucre and encrypted)
centralized logging
patch management and vulnerability scanning
monitoring
secure backups
& others,but the main ones are those three.
Participant questions:
Are you worried about creating redundancy?
Do you do your own configuration for containers packing?
C)
Plan C is the aim to add 1) high availability and 2) scalability.
Openshift is an open source version of Google's Kubernetes.
Visulaizing it:
We have a muber of servers.
On it, there is a high resource intensive abstraction of Google Kubernet.
On top I have different servce classes.
What the abstraction layer does is to scale automatically.
Pros: this solution allows different orgs to share the same servers.
Cons:This is very complicated. And requires a lot of resources. And it is very centralized and doesn't allow decentralization. (Kubernetes is not tailored for decentralization)
B)
Achieve the benefits of plan C in a way that is more simple, tailored to the small groups that we are, less expensive, and it is decentralized.
Cons: it is not in prodcution, we do not know if it could work. And it is mainly in the mind of one person only so far.
- - - -
The session we had so far is only about the infrastructure layer.
Next step, moving on from the infrastructure layer, would be to address the question: What are the applications that we would run then?
Participants ask for a session about apps. Great, going to happen.
"Cloudy stuff" and plan C are big questions marks. The rest, especially containers, are work that seems very well worth our work now.
Much of debate now is: How much to focus on plan C. Maybe plans A and B will already take a lot of energy and thinking about plan C is not good use of our limited time and resources.
Q: What apps would need plan C?
A: Well, people are now used to have their data anywhere they are at any time.
Q: Are there white papers or code we can see about this?
A: Facilitator says: We don't have white papers yet, but I can put together code bases you can look at.