docs(adopters): update with details from arista and comcast

Related: openebs#2719 Updated the ADOPTER.md with details from new companies Also refactor to list using alphabetical order. Signed-off-by: kmova <kiran.mova@mayadata.io>
haxorsprogramming · Sep 21, 2019 · 204b597 · 204b597
1 parent 6e35a4a
commit 204b597
Show file tree

Hide file tree

Showing 3 changed files with 49 additions and 4 deletions.
diff --git a/ADOPTERS.md b/ADOPTERS.md
@@ -8,18 +8,20 @@ The list of organizations that have publicly shared the usage of OpenEBS:
 
 | Organization | Stateful Workloads | Success Story |
 | :--- | :--- | :--- |
-| [Plaid Cloud](https://github.com/PlaidCloud) | Redis, Prometheus, Elasticsearch, Postgresql | [English](./adopters/plaidcloud/README.md) |
-| [Code Wave](https://codewave.eu/) | Bitwarden, Bookstack, Allegros Ralph, Limesurvey, Grafana, Hackmd/Codimd, Minio, Nextcloud, Percona XtraDB Cluster Operator, Nextcloud, Sonarqube, Sentry, Jupyterhub | [English](./adopters/codewave/README.md) |
-| [Clouds Sky GmbH](https://cloudssky.com/en/) | Confluent Kafka, Strimzi Kafka, Elasticsearch, Prometheus | [English](./adopters/cloudssky/README.md) |
+| [Arista Networks](https://www.arista.com/en/) | Gerrit (multiple flavors), NPM, Maven, Redis, NFS, Sonarqube, Internal tools | [English](./adopters/arista/README.md) |
 | [CLEW Medical](https://clewmed.com/) | Postgresql, Keycloak, RabbitMQ | [English](./adopters/clewmedical/README.md) |
+| [Clouds Sky GmbH](https://cloudssky.com/en/) | Confluent Kafka, Strimzi Kafka, Elasticsearch, Prometheus | [English](./adopters/cloudssky/README.md) |
+| [Code Wave](https://codewave.eu/) | Bitwarden, Bookstack, Allegros Ralph, Limesurvey, Grafana, Hackmd/Codimd, Minio, Nextcloud, Percona XtraDB Cluster Operator, Nextcloud, Sonarqube, Sentry, Jupyterhub | [English](./adopters/codewave/README.md) |
+| [Comcast](https://github.com/Comcast) | Prometheus, Alertmanager, Influxdb, Helm Chartmuseum | [English](./adopters/comcast/README.md) |
+| [Plaid Cloud](https://github.com/PlaidCloud) | Redis, Prometheus, Elasticsearch, Postgresql | [English](./adopters/plaidcloud/README.md) |
 
 
 The list of users that have publicly shared the usage of OpenEBS.
 
 | User | Stateful Workloads | Success Story |
 | :--- | :--- | :--- |
-| [tardich](https://github.com/tardich) | Postfix Mail Relay, NextCloud, Nexus Repository, Plex | [English](./adopters/users/tardich/README.md)  | 
 | [proegssilb](https://github.com/proegssilb) | PostgreSQL, Redis, Factorio (video game server) | [English](./adopters/users/proegssilb/README.md)  | 
+| [tardich](https://github.com/tardich) | Postfix Mail Relay, NextCloud, Nexus Repository, Plex | [English](./adopters/users/tardich/README.md)  | 
 
 
 

diff --git a/adopters/arista/README.md b/adopters/arista/README.md
@@ -0,0 +1,23 @@
+### Company: Arista Networks (https://www.arista.com/en/)
+
+### Stateful Applications that you are running on OpenEBS
+- Gerrit (multiple flavors), NPM, Maven, Redis, NFS, Sonarqube
+- Various internal tooling requiring stateful storage.
+
+### Type of OpenEBS Storage Engines behind the above application - cStor, Jiva or Local PV?
+About ~90% cStor, 10% Jiva.
+
+### Are you evaluating or already using in development, CI/CD, production
+Used in dev, staging, and production clusters.
+
+### Are you using for home use or for your organization
+For Arista Networks.
+
+### A brief description of the use case or details on how OpenEBS is helping your projects.
+- Easy for developers to use: developers don't have to worry beyond choosing the right storageclass and size of storage. Decouples developers from storage integrity and unnecessary details that they shouldn't have to worry about.
+- Withstand cluster disasters: OpenEBS' ability to spread volumes across multiple nodes in a kubernetes cluster as well as automatic recovery of degraded replicas without operator involvement was our highest requirement for a storage solution, and OpenEBS met this perfectly. Rolling upgrades with kubernetes is a breeze thanks OpenEBS, since we only need to maintain quorum and not require all replicas/nodes to be online.
+- Separation of application from storage in terms of physical location: application is entirely decoupled from where the storage is thanks to iSCSI backbone. We can optimize storage nodes vs. nodes serving applications thanks to OpenEBS being built on networked storage.
+- Configurability and ease of deployment: deployment of the entire stack is very easy. As an early adopter, upgrades are a pain point, but I'm pleased to see the team have fixed this in later versions with helm, which is the right thing to do. Configurable NDM and cStor pools that allowed us to have
+ extensive custom configurations for our storage nodes vs. application nodes.
+- Doesn't require 139746387243 nodes to operate (exaggeration): compared to Ceph, amount of starting nodes required to operate OpenEBS is incomparably lower/efficient. 
+- Uses age old technologies proven to work, rather than unproven solutions: built on iSCSI, ZFS. Standard solutions. No unknown unicorn magic.
diff --git a/adopters/comcast/README.md b/adopters/comcast/README.md
@@ -0,0 +1,20 @@
+### Company: Comcast (https://github.com/Comcast)
+
+### Stateful Applications that you are running on OpenEBS
+- Prometheus
+- Alertmanager
+- Influxdb
+- Helm Chartmuseum
+
+### Type of OpenEBS Storage Engine(s)
+cStor
+
+### Are you evaluating or already using in development, CI/CD, production
+Already using in dev and production
+
+### Are you using for home use or for your organization
+Using for the organization
+
+### A brief description of the use case or details on how OpenEBS is helping your projects.
+We are currently using openebs as persistent storage for a lot of our monitoring, alerting, and metrics gathering applications (Prometheus, Alertmanager, and Influxdb).  We are also using it as the backend storage for [helm chartmuseum](https://github.com/helm/chartmuseum) where we store our custom helm charts used for deployments.
+