autonomic-cooperative/autonomic.zone
Archived
5
0
Fork 0
Code Issues 15 Pull Requests 2 Releases Activity

Lots of edits

Browse Source
This commit is contained in:
KawaiiPunk 2021-02-23 17:54:10 +00:00 committed by Luke Murphy
parent 2d86a3ed56
commit cc2425e1cd
No known key found for this signature in database
GPG Key ID: 5E2EF5A63E3718CC
1 changed files with 27 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
src/_posts/2021-02-16-coop-cloud.md
View File

@ -7,53 +7,61 @@ category: coop, cloud, docker, swarm, free-software
date: 2021-02-16 date: 2021-02-16
--- ---
Running [free software] apps and infrastructure for ourselves and our clients is central to what we do at Autonomic. Now, after a year of work, we're stoked to share our "Cooperative Cloud" system with the world, to make it easier for others to join the party, ditch corporate spyware, and make their tools [sustainable, transparent and private]. Running [free software] apps and infrastructure for ourselves and our clients is central to what we do at Autonomic. Now, after a year of work, we're stoked to share our "Co-op Cloud" project with the world. We want to make it easier for others to join the party, ditch corporate spyware, and make their tools [sustainable, transparent and private].
## Why a new tool? ## Why a new tool?
We started out using [Cloudron], which provides a very simple-to-use web interface for deploying hundreds of free software apps like Nextcloud, Mediawiki, and Rocket.chat with a few clicks. We started out using [Cloudron], which provides a very simple-to-use web interface for deploying free software apps like Nextcloud, Mediawiki, and Rocket.chat with only a few clicks.
Cloudron allowed us to radically reduce our initial and ongoing costs for services -- because we don't need to maintain a separate server for each service, or even manage app updates ourselves. So, we've been able to take on a lot more "solidarity clients": people doing important work, but on a shoestring, grassroots budget. Cloudron allowed us to radically reduce our initial and ongoing server costs. We didn't need to maintain a separate server for each service and clients applications could share computing resources whilst containerisation was still allowing us meeting their data privacy needs. Consequently, we've been able to take on many more "solidarity clients", people doing important work, but on a shoestring budget.
As time has gone on, though, we've had a few moments when we questioned our reliance on Cloudron, and whether it was sustainable for us and for our clients: As time has gone on, though, we've had a few moments when we questioned our reliance on Cloudron, and whether it was a sustainable choice for us and for our clients. We came to realise:
- Parts of the system officially [became proprietary] -- this was somewhat understandable given Cloudron's licensing model, but rang alarm bells for us about its long-term future. - Core parts of the system officially [became proprietary] software. This rang alarm bells for us about its long-term future.
- We realised that the work to package the available applications is done [entirely by the Cloudron team itself] and doesn't re-use the existing rich ecosystem of free software packaging work already going on. This seems like a big risk: if Cloudron goes under, someone would need to take on that huge, specific, and non-transferable packaging work, or we'd quickly be leaving ourselves and our clients running on outdated software. - The work to package the available applications is done [entirely by the Cloudron team itself] and doesn't re-use the existing rich ecosystem of free software packaging work that's already being done. This seems like a big risk. If Cloudron UG, the company goes under, someone or some entity would need to take on that laborious, technically specific and non-transferable packaging work or we'd quickly be leaving ourselves and our clients running outdated and unmaintained software.
- Some aspects of Cloudron's architecture are getting in the way: requiring each app to be a single Docker image makes certain deployments hard-to-impossible (as far as we know, nobody has yet managed to get Mediawiki's visual editor working in Cloudron, for example), and not being able to delegate user management to specific groups has made it hard for us to use Cloudron's Single Sign On system with groups who are growing more users quickly. - Some aspects of Cloudron's architecture were causing problems. Requiring each app to be a single Docker image makes common application deployment configurations impossible (as far as we know, nobody has yet managed to get Mediawiki's visual editor working in Cloudron, for example).
We also have a general fear of centralising so much of our core business on a commercial entity, which could change its prices at any time and have a massive effect on our ability to operate. - Not being able to delegate user management to specific groups has made it hard for us to use Cloudron's Single Sign On system with groups who manage their own users.
- Cloudron's central paradigm is focussed on "non-technical" users with the nice web front end for managing apps. However, we found our clients actually need to know what "domain name" or "storage volumes" are. That's why they pay us for support. They want it to "just work". Using an interface designed for non-technical users is not suitable for technical users and adds a lot of bloat.
- Cloudron is a bit of a [black box](https://en.wikipedia.org/wiki/Black_box). When something breaks, it breaks hard and requires technical users to respond and investigate and then fix the issues.
- Cloudron doesn't encourage collective and public collaboration on configuration files.
- We have a general fear of centralising so much of our core business on a commercial entity, which could change its prices at any time and have a massive effect on our ability to operate.
## A New Hope ## A New Hope
So, around the end of 2019, we tried to map out a few core principles of a system which might work a lot like Cloudron, but give us more guarantees that we can depend on, which we've started calling the Cooperative Cloud (or "Coop Cloud" for short): So, around the end of 2019, we tried to map out a few core principles of a system which might work a lot like Cloudron, but give us more guarantees that we can depend on. We started calling the new project Co-op Cloud. Here are some of the principles we identified:
- Coop Cloud should always be available under [copyleft licenses] to retain the shared work as public property. This doesn't mean we can't pursue commercial work, but we can't rely on creating false scarcity to earn money. - Co-op Cloud should always be available under [copyleft licenses] to retain the shared work as part of the [commons](https://en.wikipedia.org/wiki/Commons). We shouldn't rely on creating [artificial scarcity](https://en.wikipedia.org/wiki/Artificial_scarcity) as a business model.
- Coop Cloud doesn't re-invent the wheel. We aim to work with existing free software communities who are already packaging and publishing their software. (Nextcloud, Gitea, Mediawiki, Rocket.chat, the list goes on...). We want to be involved in their community spaces and build bridges between infrastructure, software development and end-users. - Co-op Cloud doesn't re-invent the wheel. We aim to work with existing free software communities who are already packaging and publishing their software (Nextcloud, Gitea, Mediawiki, Rocket.chat, the list goes on and on...). We want to be involved in their community spaces and build bridges between infrastructure, software development and end-users.
- Coop Cloud has democratic governance at the core of the project. We want to collaborate as much as possible with other cooperatives to build up good decision-making structures, so we can all rely on this project into the future. - Co-op Cloud has democratic governance at the core of the project. We want to collaborate as much as possible with other co-operatives to build up good decision-making structures so we can all rely on this project into the future.
In our spare time (partly funded by income from working for our wonderful clients 😀) we've been putting the pieces together, and, after a year of work -- and two technical dead-ends -- we're ready to launch an alpha version of Cooperative Cloud to the public. In our spare time (partly funded by income from working for our wonderful clients 😀) we've been putting the pieces together; and after a year of work (including two "back to the drawing board" moments), we're ready to launch an [alpha version](https://en.wikipedia.org/wiki/Software_release_life_cycle) of Co-op Cloud to the public.
## Coop Cloud alpha ## Coop Cloud public alpha
Coop Cloud is a simple packaging format using existing [open standards] to build a catalogue of applications, and a command-line client to read the catalogue and deploy those applications. Coop Cloud is a simple packaging format using existing [open standards] to build a catalogue of applications, and a command-line client to read the catalogue and deploy those applications.
If you'd like to learn more about Coop Cloud, please read [our documentation] -- where we explain the decisions we've made so far in more depth. What technologies we're using, how we fit into the existing ecosystem, ways to contribute, what applications are available and so on. If you'd like to learn more about Coop Cloud, please read [our documentation], where we explain the decisions we've made so far in more depth. What technologies we're using, how we fit into the existing ecosystem, ways to contribute, what applications are available and so on.
You can also dive straight in by installing [`abra`, CoopCloud's command-line tool]. You can also dive straight in by installing [`abra`, CoopCloud's command-line tool].
You can use Coop Cloud right now to deploy any of our [30+ applications] to your own Virtual Private Server, including Nextcloud for file-, calendar- and contact-sharing, Rocket.chat for instant messaging, Keycloak for Single Sign-On, Statping for service monitoring, and websites using Wordpress, Pelican, Jekyll, or static HTML. You can use Coop Cloud right now to deploy any of our [30+ applications] to your own physical server or virtual server. These include [Nextcloud](https://nextcloud.com/) (for file, calendar, contacts etc) [Rocket.chat](https://rocket.chat/) for instant messaging, [Keycloak](https://www.keycloak.org/) for Single Sign-On, [Statping](https://statping.com/) for service monitoring, and websites using [Wordpress](https://wordpress.org/), [Pelican](https://blog.getpelican.com/), [Jekyll](https://jekyllrb.com/), or static HTML.
We've already been testing a sort of "dual power" strategy, using CoopCloud to run some of our own and our clients' infrastructure while continuing with Cloudron for the rest, and we're seeing promising stability. We've already been deploying Co-op Cloud as part of "dual power" strategy. We use Co-op Cloud to run some of our own and our clients' infrastructure while continuing with Cloudron and other strategies for the time being. We're seeing promising stability and it's been a joy to work with.
Apps deployed via CoopCloud have automatic SSL certificates, and many come with pre-configured e-mail, backups, or Single Sign-On options. Apps deployed via CoopCloud have automatic SSL certificates, and many come with pre-configured e-mail, backups, or Single Sign-On options.
Packaging new applications for CoopCloud is straightforward in most cases: you can re-use an application's own Docker image (or even `docker-compose.yml` file) with minimal changes -- we managed to [make a CoopCloud version of the Matomo web analytics platform in about 20 minutes]. This architecture also means that nobody using CoopCloud is dependent on us for updates: when a new Wordpress update comes out, you can easily install it yourself, without waiting for us to update some arcane custom Docker image. Packaging new applications for CoopCloud is straightforward in most cases: you can re-use an application's own Docker image (or even `docker-compose.yml` file) with minimal changes. We managed to [make a CoopCloud version of the Matomo web analytics platform in about 20 minutes]. This standardised architecture also means that nobody using CoopCloud is dependent on Autonomic for updates. When a new Wordpress update comes out, you can easily install it yourself or automatically without waiting for us to update some arcane custom Docker image.
At this point, we'd like to invite other cooperatives to take a look at what we're working on and come and have a chat with us. We think a common platform for hosting free software infrastructure could make a big difference in terms of what we're able to offer as a movement. At this point, we'd like to invite other worker co-operatives or democratic collectives to take a look at what we're working on and have a chat with us. We think a common platform for hosting free software infrastructure could make a big difference in terms of what we're able to offer as a movement.
If you're interested in getting involved with CoopCloud development, or if you'd like help trying out CoopCloud-hosted services for yourself or your organisation, please [get in touch]! If you're interested in getting involved with CoopCloud development, or if you'd like help trying out CoopCloud-hosted services for yourself or your organisation, please [get in touch]!