I don't agree with that I don't feel like I'm underpaid or overpaid, however, I know of great unjust between gender and ethnicity and all I want is equality for all.
Maybe I'm missing the right articles or I'm thinking about this the wrong way, but I can't seem to find any resources on how people run databases in these kinds of infrastructure stacks. I mean I have no problem understanding how I can deploy my 12 factor application on kubernetes for example and load balance to those, but persistence seems to be missing. Do people just use Amazons/Compose/etc Database offerings and don't worry about it themselves?
Yeah, I sort of alluded to it in the article but didn't expand on it - we're doing a combination of things.
1. Using AWS services where we can (DynamoDB)
2. Provisioning more "traditionally" to instances, and managing those independently of the Mesos scheduler
3. Experimenting with scheduler based solutions[1] (which are still pretty bleeding edge, but are promising)
As I mentioned, EMC are (to me) doing the most interesting stuff here[2] because they're leaning on a lot of existing production systems like EBS and Mesos' own scheduler.
I would love to see approaches similar to the attempt for elasticsearch for all major databases as out of the box highly available, that would make me sleep a lot better at night. For the mean time I'm just going to manage my databases traditionally (through a service or run by myself). It seems like its really a problem that needs to be solved, other than that I'm a huge fan of these infrastructure approaches.
However, you have to buy into BOSH and CF to make use of this
Also, most of the interesting and high-quality services are part of Pivotal's paid version of CF. Which might well be worth the money - many of the services are built by colleagues of mine, and i can assure you that they are of the finest quality! If not, there are a bunch of open-source contributed services. For example, a metrics service with InfluxDB and Grafana:
And i'm not even being paid to do this! Sorry that it came across that way - I absolutely understand how it could.
In my defence, the Cloud Foundry services are the only serious attempt I'm aware of to package highly available database setups for deployment on your own infrastructure, and that's something I really want to see become commonplace. I'd be even happier if some other group came along and did it in a way not tied to Cloud Foundry or BOSH, Ansible playbooks or something. But as yet, as far as I know, they haven't.
Similar work is progressing well for (off the top of my head) Kafka[1], Riak[2], and MySQL[3] though you'll note they're all quick to point out "don't use this for production yet."
I'll be keeping on top of these developments, but for now, managing yourself or leaning on AWS services is definitely the pragmatic decision.
Thanks for the resources, I will for sure be following these. My dream is that one day I can do something similar to `docker-compose scale db=5` and have a database that is highly available.
Couldn't agree more. Code is highly dimensional while our text editors are two dimensional at best. In case you don't know these talks I think you will enjoy The Future of Programming and Inventing on Principle both by Bret Victor.
I somehow felt like the docker team was closer with the Rancher team, so I thought docker might acquire Rancher at some point. I think this is a move to produce revenue in the future while Rancher is yet another open source project to monetize.
We spend a lot of time with all companies in the ecosystem, and feel it's important to stay close and to support both their technical and business interests.
We're engaged with over 300 companies that are technically integrating in to Docker to enhance their product offerings, with 6-10 added every week.
Is anyone else noticing the distracting optical illusion in the logo when reading the first paragraph on the landing page? If I am not the only one, someone should find a way to fix it.
Neat. I really liked Ubuntu One. However, if they seek to receive contributions I think GitHub would give them more exposure than launchpad, from what I can tell the history is not preserved (probably with good reasons) so the switch from bazaar would not have been painful.
They don't. This is a code dump for a dead project. From the FAQ:
"Will you take patches?"
In general, no.
We won’t have anybody assigned to reviewing and accepting code.
We’d encourage interested maintainers to fork the code [...]
They're only using Launchpad because it's a Canonical product and the way they always do distribution of this kind. I too would agree in your choice of Github as it tends to be more developer centric in it's social tools. I think it will get picked up more if it's there..
I agree, before you start implementing all these changes you should probably also spot the time consuming parts of your software using a profiler. Otherwise you might be making a bad trade-off. My software engineering professor always used to say: "Never start optimizing before you have measured [using a profiler]."
I've actually found JRuby to be very handy when it comes to packaging. Using warbler I can generate a jar file and then using the javapackager I can create self contained packages for all the major platforms/package managers: windows (.exe/.msi), linux (.rpm, .deb), osx (.dmg). Way more painless than packaging a ruby runtime. I've tried traveling ruby, but have not had the same seamless experience. Especially when it comes to multiple platforms. However, packaging with java, jruby and my application usually turn out to be quite large. Around 80Mb for a CLI and the startup time for short running programs like CLIs using JRuby can be quite long.
