I think the main problem with all of these systems is that are just so damn complex.<p>Docker, its great if you have no state. But then if you have no state shit is easy. Mapping images to highspeed storage securely and reliably is genuinely hard. (unless you use NFSv4 and kerberos)<p>Mesos is just over kill for everything. How many people actually need shared image programs bigger than a 64 core machine with 512gigs of ram? (and now good are you at juggling NUMA or NUMA like interfaces)<p>I can't help thinking that what people would really like is just a nice easy to use distributed CPU scheduler. Fleet basically, just without the theology that comes with it.<p>Seriously, mainframes look super sexy right now. Easy resource management, highly scalable real UNIX. (no need to spin up/down, just spawn a new process)
The real problem is going from tutorial to something you would use in production. Throw in logging, security and service discovery and you can have a few engineers hacking away for months.<p>So I want to plug a project I've been contributing to: <a href="https://github.com/CiscoCloud/microservices-infrastructure" rel="nofollow">https://github.com/CiscoCloud/microservices-infrastructure</a><p>We're trying to make it super easy to deploy these tools. For example every time you launch a docker container, it will register with consul and be added to haproxy. The nice thing about using Mesos is we can support data like workloads Cassandra, HDFS, and Kafka on the same cluster your run Docker images on.<p>We use terraform to deploy to multiple clouds so you don't get locked in to something like cloudformation.
The Circle CI post <a href="http://blog.circleci.com/its-the-future/" rel="nofollow">http://blog.circleci.com/its-the-future/</a> reads as a parody on this one.
Is anyone running Marathon in production? <i>Real</i> production. The kind where any downtime means lost money.<p>I see a lot of intro-level tutorials, but almost nothing on the more advanced side.<p>My (completely casual) experience with Marathon is pretty bad, with the main process crashing quite regularly even under no load, so I'm wondering if people who write about these systems have actually used them for non-trivial tasks. And for something as critical as Marathon, which is supposed to handle... well... all my services, I'd rather be sure that the system is rock solid.<p>(This is specifically about Marathon. Mesos itself has proven more reliable)
Factual have done what lots of people do, which is invent the first 20% of a PaaS.<p>PaaSes are awesome. They also, once you go past the basics, require enormous engineering effort. And that's the problem: engineering effort spent on curating your own homegrown PaaS is engineering effort not available for creating user value.<p>5 years ago rolling your own was a source of competitive advantage. Today you can get an installable PaaS (Cloud Foundry or OpenShift) off the shelf and run it. In 2 years Docker, Mesos and CoreOS will probably all have PaaSes of their own.<p>Interesting times.
To be honest, I still have yet to see one of these systems that beats simply using Bash. They're all trying to make a scripting problem into a configuration problem. That's sometimes a reasonable idea, when what you're doing is common enough that only a few things here and there need to diverge from the defaults. But <i>every</i> image I've ever had to create contained far more edge cases than default cases, and half of those edge cases are things nobody thought of and therefore their system doesn't handle it. Rather than trying to fight with one of these systems to get them to do something I could easily do with a few Bash commands, I find it easier to just script the setup in Bash to begin with.<p>Obviously that doesn't work for Windows systems.