forked from toolshed/docs.coopcloud.tech
		
	move 'What about -> Comparisons page
This commit is contained in:
		
							
								
								
									
										121
									
								
								docs/intro/comparisons.md
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										121
									
								
								docs/intro/comparisons.md
									
									
									
									
									
										Normal file
									
								
							| @ -0,0 +1,121 @@ | ||||
| --- | ||||
| title: Comparisons | ||||
| --- | ||||
|  | ||||
| We think it's important to understand that *Co-op Cloud* is more than just | ||||
| software and technical configurations. It is also a novel organization of *how* | ||||
| to [create technology socially](https://docs.coopcloud.tech/federation). | ||||
| However, strictly technically speaking you may be wondering: | ||||
|  | ||||
| ### What about `$alternative`? | ||||
|  | ||||
| We have various technical critiques of other similar projects which are already up-and-running in the ecosystem, as they don't necessarily meet our needs as a small tech co-op. However, Co-op Cloud isn't meant to be a replacement for these other projects. | ||||
|  | ||||
| Here is a short overview of the pros/cons we see, in relation to our goals and needs. | ||||
|  | ||||
| ### Cloudron | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Decent web interface for app, domain & user management. | ||||
| - 👍 Large library of apps. | ||||
| - 👍 Built-in SSO using LDAP, which is compatible with more apps and often has a better user interface than OAuth. | ||||
| - 👍 Apps are actively maintained by the Cloudron team. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Moving away from open source. The core is now proprietary software. | ||||
| - 👎 Libre tier has a single app limit. | ||||
| - 👎 Based on Docker images, not stacks, so multi-process apps (e.g. parsoid visual editor for Mediawiki) are a non-starter. | ||||
| - 👎 Difficult to extend apps. | ||||
| - 👎 Only supported on Ubuntu LTS. | ||||
| - 👎 Upstream libre software communities aren't involved in packaging. | ||||
| - 👎 Limited to vertical scaling. | ||||
| - 👎 Tension between needs of hosting provider and non-technical user. | ||||
| - 👎 LDAP introduces security problems - one vulnerable app can expose a user's password for all apps. | ||||
| - 👎 Bit of a [black box](https://en.wikipedia.org/wiki/Black_box). | ||||
|  | ||||
| ### YunoHost | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Lovely web interface for app, domain & user management. | ||||
| - 👍 Bigger library of apps. | ||||
| - 👍 Awesome backup / deploy / restore continuous integration testing. | ||||
| - 👍 Supports hosting apps in subdirectories as well as subdomains. | ||||
| - 👍 Doesn't require a public-facing IP. | ||||
| - 👍 Supports system-wide mutualisation of resources for apps (e.g. sharing databases by default) | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Upstream libre software communities aren't involved in packaging. | ||||
| - 👎 Uninstalling apps leaves growing cruft. | ||||
| - 👎 Limited to vertical scaling. | ||||
| - 👎 Not intended for use by hosting providers. | ||||
|  | ||||
| ### Caprover | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Bigger library of apps. | ||||
| - 👍 Easy set-up using a DigitalOcean one-click app. | ||||
| - 👍 Works without a domain name or a public IP, in non-HTTPS mode (good for homeservers). | ||||
| - 👍 Deploy any app with a `docker-compose.yml` file as a "One Click App" via the web interface. | ||||
| - 👍 Multi-node (multi-server) set-up works by default. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Single-file app definition format, difficult to tweak using entrypoint scripts. | ||||
| - 👎 Nginx instead of Traefik for load-balancing. | ||||
| - 👎 Command-line client requires NodeJS / `npm`. | ||||
| - 👎 [Requires 512MB RAM for a single app](https://github.com/caprover/caprover/issues/28). | ||||
| - 👎 [Backup/restore is "experimental"](https://caprover.com/docs/backup-and-restore.html), and doesn't currently help with backing up Docker volumes. | ||||
| - 👎 Exposes its bespoke management interface to the internet via HTTPS by default. | ||||
|  | ||||
| ### Ansible | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Includes server creation and bootstrapping. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Upstream libre software communities aren't publishing Ansible roles. | ||||
| - 👎 Lots of manual work involved in things like app isolation, backups, updates. | ||||
|  | ||||
| ### Kubernetes | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Helm charts are available for some key apps already. | ||||
| - 👍 Scale all the things. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Too big -- requires 3rd party tools to run a single-node instance. | ||||
| - 👎 Not suitable for a small to mid size hosting provider. | ||||
|  | ||||
| ### Docker-compose | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Quick to set up and familiar for many developers. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Manual work required for process monitoring. | ||||
| - 👎 Secret storage not available yet. | ||||
| - 👎 [Swarm is the new best practice](https://github.com/BretFisher/ama/issues/8#issuecomment-367575011). | ||||
|  | ||||
| ### Doing it Manually (Old School) | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Simple - just follow upstream instructions to install and update. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Loads of manual work required for app isolation and backups. | ||||
| - 👎 Array of sysadmin skills required to install and maintain apps. | ||||
| - 👎 Hard to share configurations into the commons. | ||||
| - 👎 No idea who has done what change when. | ||||
| @ -40,118 +40,6 @@ Also see our [strategy page](../strategy/). | ||||
|  | ||||
| See ["Package your first recipe"](/maintainers/tutorial/#package-your-first-recipe) for more. | ||||
|  | ||||
| ## What about `$alternative`? | ||||
|  | ||||
| We have various technical critiques of other similar projects which are already up-and-running in the ecosystem, as they don't necessarily meet our needs as a small tech co-op. However, Co-op Cloud isn't meant to be a replacement for these other projects. | ||||
|  | ||||
| Here is a short overview of the pros/cons we see, in relation to our goals and needs. | ||||
|  | ||||
| ### Cloudron | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Decent web interface for app, domain & user management. | ||||
| - 👍 Large library of apps. | ||||
| - 👍 Built-in SSO using LDAP, which is compatible with more apps and often has a better user interface than OAuth. | ||||
| - 👍 Apps are actively maintained by the Cloudron team. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Moving away from open source. The core is now proprietary software. | ||||
| - 👎 Libre tier has a single app limit. | ||||
| - 👎 Based on Docker images, not stacks, so multi-process apps (e.g. parsoid visual editor for Mediawiki) are a non-starter. | ||||
| - 👎 Difficult to extend apps. | ||||
| - 👎 Only supported on Ubuntu LTS. | ||||
| - 👎 Upstream libre software communities aren't involved in packaging. | ||||
| - 👎 Limited to vertical scaling. | ||||
| - 👎 Tension between needs of hosting provider and non-technical user. | ||||
| - 👎 LDAP introduces security problems - one vulnerable app can expose a user's password for all apps. | ||||
| - 👎 Bit of a [black box](https://en.wikipedia.org/wiki/Black_box). | ||||
|  | ||||
| ### YunoHost | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Lovely web interface for app, domain & user management. | ||||
| - 👍 Bigger library of apps. | ||||
| - 👍 Awesome backup / deploy / restore continuous integration testing. | ||||
| - 👍 Supports hosting apps in subdirectories as well as subdomains. | ||||
| - 👍 Doesn't require a public-facing IP. | ||||
| - 👍 Supports system-wide mutualisation of resources for apps (e.g. sharing databases by default) | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Upstream libre software communities aren't involved in packaging. | ||||
| - 👎 Uninstalling apps leaves growing cruft. | ||||
| - 👎 Limited to vertical scaling. | ||||
| - 👎 Not intended for use by hosting providers. | ||||
|  | ||||
| ### Caprover | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Bigger library of apps. | ||||
| - 👍 Easy set-up using a DigitalOcean one-click app. | ||||
| - 👍 Works without a domain name or a public IP, in non-HTTPS mode (good for homeservers). | ||||
| - 👍 Deploy any app with a `docker-compose.yml` file as a "One Click App" via the web interface. | ||||
| - 👍 Multi-node (multi-server) set-up works by default. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Single-file app definition format, difficult to tweak using entrypoint scripts. | ||||
| - 👎 Nginx instead of Traefik for load-balancing. | ||||
| - 👎 Command-line client requires NodeJS / `npm`. | ||||
| - 👎 [Requires 512MB RAM for a single app](https://github.com/caprover/caprover/issues/28). | ||||
| - 👎 [Backup/restore is "experimental"](https://caprover.com/docs/backup-and-restore.html), and doesn't currently help with backing up Docker volumes. | ||||
| - 👎 Exposes its bespoke management interface to the internet via HTTPS by default. | ||||
|  | ||||
| ### Ansible | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Includes server creation and bootstrapping. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Upstream libre software communities aren't publishing Ansible roles. | ||||
| - 👎 Lots of manual work involved in things like app isolation, backups, updates. | ||||
|  | ||||
| ### Kubernetes | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Helm charts are available for some key apps already. | ||||
| - 👍 Scale all the things. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Too big -- requires 3rd party tools to run a single-node instance. | ||||
| - 👎 Not suitable for a small to mid size hosting provider. | ||||
|  | ||||
| ### Docker-compose | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Quick to set up and familiar for many developers. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Manual work required for process monitoring. | ||||
| - 👎 Secret storage not available yet. | ||||
| - 👎 [Swarm is the new best practice](https://github.com/BretFisher/ama/issues/8#issuecomment-367575011). | ||||
|  | ||||
| ### Doing it Manually (Old School) | ||||
|  | ||||
| #### Pros | ||||
|  | ||||
| - 👍 Simple - just follow upstream instructions to install and update. | ||||
|  | ||||
| #### Cons | ||||
|  | ||||
| - 👎 Loads of manual work required for app isolation and backups. | ||||
| - 👎 Array of sysadmin skills required to install and maintain apps. | ||||
| - 👎 Hard to share configurations into the commons. | ||||
| - 👎 No idea who has done what change when. | ||||
|  | ||||
| ## Which technologies are used? | ||||
|  | ||||
|  | ||||
		Reference in New Issue
	
	Block a user