Live data from Hacker News

Flynn: first preview release

flynn.io

71–80 of 80 posts

Re: Flynn: first preview release

#71

Earlier quoted context omitted.

Flynn definitely isn't "ready" yet. This is a preview release, production grade stability is still a few months away. I haven't looked closely at Deis in several months, but Flynn doesn't use Chef (or anything similar) anywhere and don't plan to.

Deis dev here. We've removed the Chef dependency as of v0.7.0 in favour of CoreOS and fleet for container/machine job scheduling. That ship set sail only recently in master. :)

Good riddance. Oh, and Chef is still in your website's meta tags (and therefore google results).

Re: Flynn: first preview release

#72
post #35

Can anybody discuss how Flynn compares to Mesos? Superficially, it seems to be solving the same sort of problems.

1. Mesos is very mature software, we take reliability, quality, and backwards compatible upgrades very seriously as there are companies currently relying on these properties.

2. At a high level, Mesos aims to provide abstraction for building distributed applications. This means "frameworks" are either built on top, like Aurora, Marathon, Chronos, etc. Or frameworks are existing distributed applications that are made to run on top, like Spark, Hadoop, Jenkins, distcc, etc. The goal being to run these distributed applications together in the same cluster in order to simplify operational complexity and gain efficiency. In this sense, Mesos is trying to build and grow the common lower level abstraction, akin to a "kernel" for the datacenter.

3. Flynn is aiming to solve a much broader set of problems, by providing a PaaS, (Mesos is more like an IaaS, PaaS should be built / run on top). Flynn is aiming to provide something that is immediately useful on its own, that means things in the layer 1 listed on the website are included. Flynn is aiming to provide some of these "schedulers" out of the box. That is my understanding from reading their website.

4. I'm not sure the authors of Flynn fully comprehend the subtlety that exists between Omega and Mesos. Unfortunately, there are some primitives in Mesos that have been discussed for quite some time and have yet to be implemented that aim to alleviate the issues brought up the Omega paper. I think the Omega model makes sense at Google, where they have complete control over the schedulers. However, in the open source world, I think the Mesos model is more appropriate (this claim really warrants it's own post). With additional primitives, like "optimistic offers", "revocable offers", and "over-subscription", many of the issues discussed in the Omega paper should be remediated.

Dislaimer: I am a Mesos PMC member. :)

Re: Flynn: first preview release

#73

I'm not a DevOps person. Can someone explain in less jargony terms what this is? Is it like Heroku? I have no idea.

In short yes, it's like self-hosted heroku. They use docker and the heroku buildpack interface and many different components to coordinate container management, logging, etc to provide a whole system.

Re: Flynn: first preview release

#74

Earlier quoted context omitted.

Flynn definitely isn't "ready" yet. This is a preview release, production grade stability is still a few months away. I haven't looked closely at Deis in several months, but Flynn doesn't use Chef (or anything similar) anywhere and don't plan to.

Deis dev here. We've removed the Chef dependency as of v0.7.0 in favour of CoreOS and fleet for container/machine job scheduling. That ship set sail only recently in master. :)

oh good... time to have another look at Deis then :)

Re: Flynn: first preview release

#75
post #71

Earlier quoted context omitted.

Deis dev here. We've removed the Chef dependency as of v0.7.0 in favour of CoreOS and fleet for container/machine job scheduling. That ship set sail only recently in master. :)

Good riddance. Oh, and Chef is still in your website's meta tags (and therefore google results).

We'll be updating the website in preparation for our next release. Most users are still on v0.7.0 or earlier. Once it's been released then our website should reflect the changes in master.

Re: Flynn: first preview release

#76
My first impression was that it has to do something with TRON's Kevin Flynn. Quoting him: "I tried to picture clusters of information as they moved through the computer. What did they look like? Ships? Motorcycles? Were the circuits like freeways?"

Re: Flynn: first preview release

#78
post #22

Earlier quoted context omitted.

Actually after Jeff Lindsay latest blog post[0] I thought that the project was put on the back burner. What is the relationship between cupcake and the initial author(s) ? [0]: http://progrium.com/blog/2014/02/06/the-start-of-the-age-of-...

Cupcake (Apollic Software) has been the company behind Flynn (and Tent) since day 0 (we tend to downplay the branding because we think both projects can stand on their own). Most of the development on Flynn (nearly all of the 2014 work) was done by Jonathan Rudenberg (@titanous), one of the founders of Cupcake. We brought in Jeff as a contractor and paid him out of the crowdfunding campaign. He contributed to the ini…

Yeah, Flynn is open source so I can contribute as necessary, but Cupcake is continuing to maintain and build the project.

My specific long-term plan is still vague, but it will involve Flynn and so far I've been finding ways to fund my time to invest in some R&D type projects for the Flynn ecosystem.

DigitalOcean's plan is not set either, but my work there should involve Flynn and that ecosystem / architecture / worldview.

Re: Flynn: first preview release

#79
post #40
post #35

Can anybody discuss how Flynn compares to Mesos? Superficially, it seems to be solving the same sort of problems.

It seems to partially duplicate the functionality of Mesos, as they are writing their own task scheduling framework [0] based on Google's Omega [1]. The Omega authors claim that Mesos' system of application specific schedulers accepting resource offers from the Mesos master is well suited toward short-lived jobs (think ephemeral Map/Reduce or MPI type workloads) but is not well suited for long lived 'service' jobs (l…

Mesos is exceptionally good at managing long-running service and that use case represents about 50% of the workloads I've seen on large production clusters.

"Scheduling" long-running services is straightforward, as they typically only need to be run "once." It's trivial to use something like Marathon [0] to do that, and you then immediately benefit from Mesos' fault-tolerance and self-healing. Marathon also makes it easy to elastically scale the long-running processes (e.g., start more Rails servers when traffic increases).

[0] - https://github.com/mesosphere/marathon

Re: Flynn: first preview release

#80

Could someone point out to me (non superficial) differences between various service discovery projects that have popped up recently like, [1]. etcd [2] skydock [3] consul [4] zookeper ( ok this is not new) [5] flynn They all seem to be doing the exact same to me. 1. https://github.com/coreos/etcd 2. https://github.com/crosbymichael/skydock 3. https://github.com/hashicorp/consul/ 5. https://flynn.io/ Edit: flynn uses…

Check this out for an excellent and detailed technical comparison of consul vs zookeeper/etcd/doozerd/chef/serf/skydns/etc:

http://www.consul.io/intro/vs/index.html

Also, discoverd is pluggable, but currently relies on etcd.

Post reply on HN