jbw976

I think the scope for Rook is to provide orchestration and management for storage solutions in cloud-native environments. The way it does that is by providing a set of custom controllers and custom resources (CRDs) that you can use to deploy storage solutions that have "active reconciliation". This is also known as the "operator pattern": https://coreos.com/blog/introducing-operators.html

The ongoing management you get from the Rook operators is something you don't get from a Helm chart. The Rook operators are always running, monitoring the environment, and able to take corrective action if anything goes awry.

After you've deployed one of Rook's supported storage systems into your cluster using these operators, you can also use Rook to dynamically provision storage from these systems for your apps. For example, if you want a volume for your pod, you could declare a PersistentVolumeClaim (PVC) that will result in a Ceph RBD block device being dynamically provisioned, attached, mounted and connected to your pod by Rook.

Dynamic provisioning of other types of storage resources such as databases and buckets, similar to how it's done for volumes, is something I also think has a ton of value, as it would greatly improve the portability of all apps. I think there's great opportunity for integration between Rook and the Crossplane project (https://crossplane.io/) to enable those types of multicloud scenarios.

You may find these "Rook Intro" slides from the last Kubecon to also be informative: https://docs.google.com/presentation/d/1mXFmMZqTF3JV357ICkIG...

And here's the recording of that Kubecon talk: https://www.youtube.com/watch?v=pwVsFHy2EdE&index=2&list=PLP...

(source: i'm a maintainer on both Rook and Crossplane)

This article on their blog gets into the compatibility that cockroachdb offers and why they even decided to do that in the first place: https://www.cockroachlabs.com/blog/why-postgres/

It's also very useful to be portable across many cloud providers (in addition to on-premises), which is what crossplane is providing for your apps. In terms of databases, Amazon RDS, Google Cloud SQL, and Azure PostgreSQL are all abstracted away from the developer so that their application should work across those without changes as well.

The intent is that the app dev only cares about getting a database that speaks postgres on the wire (which CockroachDB does). The administrator, via a ResourceClass, gets to specify the actual infrastructure that gets deployed to fulfill that need for postgres. That could be Cloud SQL, or RDS, or even CockroachDB. To the app dev that just needs postgres, those are all the same. Crossplane is already doing similar "dynamic provisioning" for MySQL, Kubernetes clusters, object storage buckets and with more to come like key value stores, message queues, caches, etc.

This is very similar to how a StorageClass is used when a pod asks for a volume. The admin specifies if that's a Google PersistentDisk or Amazon EBS or Ceph RBD, etc. The pod doesn't have to care, it just gets its request for a volume fulfilled.

I'll have to look more into Stolon, that could be interesting here, thanks for that pointer.

(source: i'm a maintainer on both crossplane and rook)

the in app tipping that lyft provides is what seals the deal for me. the drivers are performing a service for me and having an integrated way to enhance their compensation is really nice. a lot of the drivers have a hard time making a good living especially considering vehicle related costs are all on their shoulders. I'm happy to have a 1-click way to give them a bit extra.

I've never understood why uber doesn't let you tip from within the app. it further solidifies the perception that uber doesn't care about its drivers. they can't wait to replace all their human drivers with a self driving fleet. can the same be said about lyft? maybe. but at least the humans are being compensated better by lyft right now.