Docker, Mesos, Marathon, and the End of Pets
blog.factual.com
Docker, Mesos, Marathon, and the End of Pets
1–10 of 36 posts
Re: Docker, Mesos, Marathon, and the End of Pets
#2I think the main problem with all of these systems is that are just so damn complex.
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)
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)
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.
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)
Re: Docker, Mesos, Marathon, and the End of Pets
#3I think the main problem with all of these systems is that are just so damn complex. 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) Mesos is just over kill for everything. How many people actually need shared image programs bigger than a 64 core machine with 512gigs of…
Docker is great also to hide complexity during implementation. Discourse.org is doing a great work "enveloping" their complex rails app in containers to easy the install process. And is not stateless.
Re: Docker, Mesos, Marathon, and the End of Pets
#4I think the main problem with all of these systems is that are just so damn complex. 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) Mesos is just over kill for everything. How many people actually need shared image programs bigger than a 64 core machine with 512gigs of…
There are some surprising places where you can enforce state where it seems impossible. Once you have that, the benefits coalesce.
That's why I built ShutIt, which we've used to encapsulate complex legacy environments to produce stateless builds:
http://ianmiell.github.io/shutit/
For example, teams can have a development environment (with _everything_ in it) rebuilt daily. As everyone uses it, everyone curates it, and they're all talking about the same thing - one pet if you like, rather than n, where n is the number of developer/development envs.
Re: Docker, Mesos, Marathon, and the End of Pets
#5I think the main problem with all of these systems is that are just so damn complex. 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) Mesos is just over kill for everything. How many people actually need shared image programs bigger than a 64 core machine with 512gigs of…
You might like Lattice[0], which is extracted from Cloud Foundry.
Basically, everyone is racing back to PaaSes. Heroku pioneered it and are still out there. Red Hat have OpenShift and are making noises about turning it into a Docker+Kubernetes thing in version 3. Cloud Foundry has been around for a few years now. There are other also-rans.
The thing is that apart from Heroku, you've not heard of installable PaaSes because they're being pitched to the Fortune 500s.
I've worked on Cloud Foundry and I work for the company which donates the most effort to the Foundation. It's been surreal to watch other people introduce pieces of a PaaS and see the excitement about the pieces. Meanwhile, we literally have an entire turnkey system already. If you need a full PaaS -- push your app or service and have it running in seconds, with health management, centralised logging, auto-placement, service injection, the works -- we built it already. Free and opensource, owned by an independent Cloud Foundry Foundation.
Anyhow, I'm obviously biased, YMMV etc etc. But I'd play with Lattice, to get the hang of things.
Re: Docker, Mesos, Marathon, and the End of Pets
#6The Circle CI post http://blog.circleci.com/its-the-future/ reads as a parody on this one.
Re: Docker, Mesos, Marathon, and the End of Pets
#7I think the main problem with all of these systems is that are just so damn complex. 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) Mesos is just over kill for everything. How many people actually need shared image programs bigger than a 64 core machine with 512gigs of…
Docker is great also to hide complexity during implementation. Discourse.org is doing a great work "enveloping" their complex rails app in containers to easy the install process. And is not stateless.
By shipping only in a Docker container you will limit the audience for your app. That is the reason we ship GitLab as Omnibus packages (deb/rpm).
Re: Docker, Mesos, Marathon, and the End of Pets
#8Factual have done what lots of people do, which is invent the first 20% of a PaaS.
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.
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.
Interesting times.
Re: Docker, Mesos, Marathon, and the End of Pets
#9Is anyone running Marathon in production? Real production. The kind where any downtime means lost money.
I see a lot of intro-level tutorials, but almost nothing on the more advanced side.
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.
(This is specifically about Marathon. Mesos itself has proven more reliable)
Re: Docker, Mesos, Marathon, and the End of Pets
#10Earlier quoted context omitted.
Docker is great also to hide complexity during implementation. Discourse.org is doing a great work "enveloping" their complex rails app in containers to easy the install process. And is not stateless.
By shipping only in a Docker container you will limit the audience for your app. That is the reason we ship GitLab as Omnibus packages (deb/rpm).
While deb/rpm packages are better than a monolithic container, having used one of your rpms, I'd say they're only just barely better.