Live data from Hacker News

Flynn: first preview release

flynn.io

31–40 of 80 posts

Re: Flynn: first preview release

#31

Earlier quoted context omitted.

Flynn isn't a service discovery library by itself. It's more of a self hosted Heroku. Though, it does use etcd for service discovery.

Are you sure flynn uses etcd for service discovery instead of its own[1]? Looks like it uses Google Omega instead of RAFT which etcd uses. https://github.com/flynn/discoverd

As I understand it Google Omega and RAFT are two different things. Google Omega is Google's answer to Apache Mesos. Omega would need a service like Raft to understand what services are currently available. In short, Google Omega is not a service discovery service.

Re: Flynn: first preview release

#32
post #27

Earlier quoted context omitted.

Are you sure flynn uses etcd for service discovery instead of its own[1]? Looks like it uses Google Omega instead of RAFT which etcd uses. https://github.com/flynn/discoverd

Very first line of discoverd's README: It's currently backed by etcd[...]

totally missed that. thank you.

Re: Flynn: first preview release

#33

Are these sorts of services good enough? I want somewhere to deploy my Django apps, ideally I should be able to get a beefy server and deploy every app as a single thing on that server, completely compartmentalized. The problem I keep hitting is that these things have a tradeoff between ease of use and power. I want to use Docker, but it has no easy way to say "take this file that contains instructions and make every…

Built-in database appliances are a big part of what Flynn will offer in the next few months (right now it's only Postgres).

Re: Flynn: first preview release

#34
Does anyone know if Flynn components can be run on CoreOS? Also, does Fylnn offer the ability to use sub-domains for accessing apps, with either a random string or custom, eg. //dev.example.com? Thx

Re: Flynn: first preview release

#36
post #22

Earlier quoted context omitted.

We actually did a crowdfunding campaign[1] last summer to pay for the development time. [1] https://news.ycombinator.com/item?id=6058662

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 initial architecture and prototypes but stepped back in December.

I don't want to speak for Jeff (@progrium) but my understanding is that he'll keep evangelizing the project at conferences and may be working on a proprietary version/components at Digital Ocean.

The Cupcake team (especially Jonathan) will keep developing Flynn (of course with open source contributions) full time in the future.

Re: Flynn: first preview release

#37
post #6

Earlier quoted context omitted.

There are currently no tutorial-style instructions for using anything but Vagrant, but you should be able to just to run these commands in whatever environment you are using: https://github.com/flynn/flynn-demo/blob/26fcd98cd7646199513...

PSA to anyone trying this on Ubuntu 14: the docker command seems to be "docker.io" now.

There is an ongoing conundrum in the downstream Debian/Ubuntu packaging of Docker. Our friends at Debian and Ubuntu are doing their best to solve it.

In the meantime, you should either a) install the latest docker from the official docker APT repos http://docs.docker.io/installation/ or b) do something like ln /usr/bin/docker{.io,}

In any case, don't leave your Docker install without a docker binary in your path. That will universally break all tutorials and scripts ever written for Docker, and is unsupported by us (Docker maintainers).

Re: Flynn: first preview release

#38
post #35

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

Right now Flynn Layer 0 is very immature compared to Mesos, but yes they're trying to solve similar problems. After Flynn reaches production stability and builds out more features, we expect Layer 0 to be a valid (and much lighter weight) alternative to Mesos that we hope will be a superior solution for a broad class of users.

I feel like the projects have very different prospective user bases and communities (Mesos is an Apache project, hundreds of thousands of lines of C++; Flynn Layer 0 is run by a startup and only a few thousand lines of Go) and will likely develop in very different directions to service those communities.

That being said, we've explored creating a version of Flynn layer 1 components that run on Mesos instead of Flynn Layer 0 for users who are already deeply invested in the Mesos ecosystem.

Re: Flynn: first preview release

#39
post #34

Does anyone know if Flynn components can be run on CoreOS? Also, does Fylnn offer the ability to use sub-domains for accessing apps, with either a random string or custom, eg. //dev.example.com? Thx

Flynn is designed to run on any modern Linux kernel. We haven't tested CoreOS yet, but once we put out a few fires we'll explore more fully.

You can add any route to any app in Flynn, so different subdomains, domains, and TCP ports are pretty easy.

Re: Flynn: first preview release

#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 (like a Rails app or DB server). As this seems to be an important use-case for Flynn, it would seem like a valid architecture decision to not use Mesos.

[0] - https://github.com/flynn/flynn-host/tree/master/sampi

[1] - http://eurosys2013.tudos.org/wp-content/uploads/2013/paper/S...

Post reply on HN