I can attest that persistent storage is the hard part! Full disclosure, I work for a company[1] who makes a persistent storage solution for containers/Kubernetes. We are absolutely seeing that our large customers (folks like GE, Verizon, Dreamworks, Comcast, etc) are running "cloud native" applications on-prem as well as in the public cloud so this is a really smart move for Google.
NIO, the self-driving car company is doing this. They did a pretty detailed interview on their use case which includes a 120 PB data lake, and Cassandra, Kafka, TensorFlow, HDFS. You can read here: https://portworx.com/architects-corner-kubernetes-satya-koma... . (Disclosure, I work for Portworx the solution they use for container storage, but hopefully the content speaks for itself).
Michael from Portworx here. Thanks for the shout out. Just for some context, we just announced a partnership with Mesosphere today to help accelerate adoption of DCOS for stateful services [0] in fact. We handle the automation of all the state management mentioned above, not just volume provisioning. Our customers include big companies like GE and Dreamworks but also a lot of smaller companies. You can use PX-Dev[1] for free up to 3 nodes. Would love feedback.
Correct, it is not opensource but you can use it for free on up to 3 nodes. Not sure what "enterprisey" means but to me that sounds like it works well for large deployments and that is true. We have customers running us with Mesos on up to 1000 nodes and K8s on hundreds of nodes.
Ceph is not a good solution at all for databases. Your performance is going to be terrible.
Ceph is object-based SDS solution designed to take servers with local drives and create a SAN out of them. In order to do this, they take each LUN (Ceph volume) and scatter the data across all nodes in the cluster. They do not assume that applications will run on these servers themselves... they assume compute is elsewhere, like a traditional SAN. The goal is to replace a SAN with servers, not create a converged platform. Also, Ceph was designed during an age where an Intel server did NOT have tier-1 capacity (8 - 20 TB), which is why they shard a volume across so many servers.
This causes a problem for modern applications like Cassandra, Mongo, Kafka etc, where they like to scaleout themselves and want a converged system, where data is not scattered, but on the node where an instance of that cluster runs. Ceph also disrupts (undo) the HA capabilities that these scaleout applications have (For example, a Cassandra instances data will not be on a node on which it thinks it is).
You can use Portworx[1] to transfer data between servers and datacenters. It has a native kubernetes driver, is production ready being used by GE and Lufthansa airlines among others and does sync and async replication of data between environments. (disclosure I work for Portworx).
[1] https://portworx.com/
Not surprising that s3 is in the lead, but somewhat that Azure is growing so fast, while Google is not. Of course, not representative of all use cases, but still, probably a pretty good proxy for overall cloud market share.
Yes, Flocker will remain open-source and my hope is that the community continues to improve it. Fli too, btw, for creating and managing ZFS snapshots https://github.com/ClusterHQ/fli
This is Michael from ClusterHQ. Just wanted to say thanks to everyone in the community who helped make the last 2 and a half years a great experience. Sad that it's ending now, but excited for what's to come.
Hi, this is Michael, I work at ClusterHQ. We don't support running Flocker with a Google persistent disk backend yet, but would like to. If you add that idea here, it will help us prioritize https://feedback.clusterhq.com/forums/305266-feedback-for-fl...
This article mentions EMC backends (ScaleIO and XtremIO) but flocker also has a mechanism to connect to any storage backend. Curious what type of storage people want to use for their microsevices. https://docs.clusterhq.com/en/1.0.0/gettinginvolved/plugins....