12 ms·

Wonderful. We just containerized all of our apps and are in the process of choosing our approach for running and deploying them in a cluster. Now what? Flynn?

Wonderful. We just containerized all of our apps and are in the process of choosing our approach for running and deploying them in a cluster. Now what? Flynn? Deis? Kubernetes? Mesos? Shipyard? Pure Fig instead? CoreOS, Serf, Maestro? Rather stay on AWS with Elastic Beanstalk or the new docker service? Welcome to the party, Swarm and Compose. By now we are not even sure anymore if Docker itself is still the way to go, now that Rocket and LXD have arrived. I don't even have the time to compare all these options, respectively get a deeper look into architectural considerations. What to decide by? Company backing? Because it's good or bad? Github stars? Deis for self-announcing it's 1.0, even if it's based on pre1.0 components or Flynn for being honest they're still in beta? Honestly, I've rarely been as tired of new technologies as I have been by now. I could roll a dice as well. If you have a good and reasonable choice for me, let me know (I'm actually serious)

cgswong 12y ago
We are in a similar position as yourself and share your opinion. What we are essentially doing is: 1. reviewing our immediate requirements 2. doing a quick paper research for those that match 3. selecting a top five based on GitHub stars and helpful resources on the web that we can find 4. proceeding with a more complete technology assessment We plan to make things as agnostic as possible so we can keep a watch on the space as things progress and if things change we can swap out a component for something else which may better meet our future requirements and/or have better long term mindshare or traction.
borjaburgos 12y ago
I'd invite you to check out http://tutum.co http://tutum.co , but then again, I'm one of the cofounders, so I'm 100% biased. Take my invitation with a grain of salt. Feedback welcomed. Cheers,
- thomasfromcdnjs 12y ago
  Was reading this earlier and saw your comment. A few hours later while Googling you came up number one in results =D Giving it a shot now.
joshpadnick 12y ago
Through all the noise, this comment is exactly what I care about. For a new project, which tech's should I choose? If I were Docker, I would organize the ecosystem for the end user on a nice clean website that explicitly lists the specific layers and technology options, some of which are from Docker, and some of which are from third-parties. Yes, they'll give mention to competitors, but at least it creates clarity and puts some meat behind their claims of "Open". At present, I'm thinking of the following: * CONTAINER: Stick w/ Docker since until a competing standard like Rocket is mature, everyone has to support Docker, even CoreOS * CONTAINER MANAGEMENT: Use CoreOS. Per above, they have to support Docker until Rocket is fully baked. Then Rocket and CoreOS will probably have synergies you can't get with Docker / CoreOS. Also, from [1]: These three [Docker] orchestration services are targeted for general availability in Q2, 2015. I honestly don't know what the other layers and decisions are yet. Perspective and clarification is welcome. [1] http://blog.docker.com/2014/12/docker-announces-orchestration-for-multi-container-distributed-apps/ http://blog.docker.com/2014/12/docker-announces-orchestratio...
girvo 12y ago
Where I work the answer is easy: We're holding off on moving to containers for anything other than local development work (it's faster than Vagrant, hooray). When AWS gets around to releasing their Docker support (beyond what Elastic Beanstalk does) with 1:n VM:container support we will move to using that along with the rest of Amazon's infrastructure (which we already use). Basically, we're going to let Amazon do it for us. Makes it easier that way :)

cgswong 12y ago

We are in a similar position as yourself and share your opinion. What we are essentially doing is: 1. reviewing our immediate requirements 2. doing a quick paper research for those that match 3. selecting a top five based on GitHub stars and helpful resources on the web that we can find 4. proceeding with a more complete technology assessment We plan to make things as agnostic as possible so we can keep a watch on the space as things progress and if things change we can swap out a component for something else which may better meet our future requirements and/or have better long term mindshare or traction.

borjaburgos 12y ago

I'd invite you to check out http://tutum.co http://tutum.co , but then again, I'm one of the cofounders, so I'm 100% biased. Take my invitation with a grain of salt. Feedback welcomed. Cheers,

thomasfromcdnjs 12y ago
Was reading this earlier and saw your comment. A few hours later while Googling you came up number one in results =D Giving it a shot now.

joshpadnick 12y ago

Through all the noise, this comment is exactly what I care about. For a new project, which tech's should I choose? If I were Docker, I would organize the ecosystem for the end user on a nice clean website that explicitly lists the specific layers and technology options, some of which are from Docker, and some of which are from third-parties. Yes, they'll give mention to competitors, but at least it creates clarity and puts some meat behind their claims of "Open". At present, I'm thinking of the following: * CONTAINER: Stick w/ Docker since until a competing standard like Rocket is mature, everyone has to support Docker, even CoreOS * CONTAINER MANAGEMENT: Use CoreOS. Per above, they have to support Docker until Rocket is fully baked. Then Rocket and CoreOS will probably have synergies you can't get with Docker / CoreOS. Also, from [1]: These three [Docker] orchestration services are targeted for general availability in Q2, 2015. I honestly don't know what the other layers and decisions are yet. Perspective and clarification is welcome. [1] http://blog.docker.com/2014/12/docker-announces-orchestration-for-multi-container-distributed-apps/ http://blog.docker.com/2014/12/docker-announces-orchestratio...

girvo 12y ago

Where I work the answer is easy: We're holding off on moving to containers for anything other than local development work (it's faster than Vagrant, hooray). When AWS gets around to releasing their Docker support (beyond what Elastic Beanstalk does) with 1:n VM:container support we will move to using that along with the rest of Amazon's infrastructure (which we already use). Basically, we're going to let Amazon do it for us. Makes it easier that way :)