not just to be able to make something work,
but being able to manage the scope of the solution to keep things simple
sometimes you get a better solution by doing less
We've been using containers rather heavily in our infrastructure for a few years now (neither rocket, nor docker) and we've developed our own toolset to handle the container images, and to manage the containers.
Even though although it kind of deprecates a lot of our work, I really see the value in having a standard that can be used with different container runtimes, and I'll be looking at migrating our internal format to the app container specs. Having tools like this to handle migrations makes a lot of sense to me. We can continue developing our tools, without marrying a specific backend.
I'm not sure if it's clear in the docs that we've written, we have plans to include other databases as a source other then mongo. i.e. Using rethink Change feeds ( http://rethinkdb.com/docs/changefeeds/ruby/ ) would be an interesting way to get data out of rethink and into other databases, we can likely leverage redis replication in order to take data from redis and then push it to other data stores. We plan to make as many sources as possible able to function as both a data 'source' and 'sink.'
We use the otto javascript interpreter to embed a js runtime into the go app, so that it's reasonably easy to manipulate documents, I'm wondering what the community things about the way the application.js is laid out.
There are some rough edges here, but we're actively developing it, and excited to see people using it