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/
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.
But they have been... for years! We've been creating fat jars to deploy services for a while already.
First Dropwizard and then Spring boot has been leading the way. But Micro is not about building a microservice, is about building a microservice ecosystem.
The main thing I've tried to focus on is simplicity - you can just use it by changing some URLs.
There are definitely other services out there which address the same thing, the closest one is probably https://rsz.io/ which even includes some more processing features, but it doesn't have the CDN and I couldn't find any info about uptime.
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.
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.
Michael, I appreciate this. I'm sure ClusterHQ was at times brutally hard work and you and team have worked hard on making things happen. I'm sorry it didn't work out and hopefully the future will be brighter with new lights.
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
Maybe donation of the code to an FOSS foundation, like maybe Apache, might be a way of ensuring the community continues. Or, at least, gives it the fighting chance to do so...
I raised that question during the final company meeting yesterday. The ownership of the code is in limbo until the investors decide what to do with it at least a few months from now.
You might be able to replace Jenkins :-). Runnable builds every branch as soon as it's updated with a push, and then deploys it. This allows you to spin off branches for your app and use/test them in a matter of seconds. Builds are exportable as Docker images which are stored in an authenticated registry.
Would love to hear what your use-case is and whether it's a good for or not! Send me an email jorge@runnable.com
