congrats to the team
27 karma · joined January 9, 2012
Strong opinions, loosely held
please reach out to family, friends, anyone and to talk through any problems
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're running on (mostly) raw lxc, with networking via openvswitch, cgroups, yada yada. so I don't think it's applicable to us at this point
A containerized world makes a lot of sense, but it still seems like a really young ecosystem. It's really the 'wild west'at this point.
To be honest, I'd rather back an accepted standard, then a specific implementation.
Don't get me wrong, Tools like this are super valuable, and generally make my day to day life easier
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.
We scale on storage / memory, we try to keep the storage and memory scaling to a defined ratio for optimal performance
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
also see our blog post: https://blog.compose.io/weve-open-sourced-the-new-compose-tr...
The most important thing though is having the culture that includes remove workers in the day to day conversations. The water-cooler is where a lot of magic happens, and that's the first thing that you miss if your corporate culture doesn't embrace remoteness.