4 ms·

Flynn CTO here, happy to answer any questions about Flynn. This is the first release in our stable channel with an update path, we'll be releasing weekly from n

Flynn CTO here, happy to answer any questions about Flynn. This is the first release in our stable channel with an update path, we'll be releasing weekly from now on. It may not be "production ready" for everyone, though please try it out and let us know how it goes. If you're in SF, please come to our meetup in Tuesday and we can talk in person: https://www.eventbrite.com/e/flynn-stable-sf-meetup-tickets-19406472281 https://www.eventbrite.com/e/flynn-stable-sf-meetup-tickets-...

TranquilMarmot 11y ago
Any plans to support C#/ASP.NET? If you haven't seen it yet, ASP.NET nVext will ship with native support for Linux/OS X and is much more package-oriented so it would lend itself pretty well to Flynn. It's still in beta, but I think they're planning a full release in Q1 2016. https://github.com/aspnet/home https://github.com/aspnet/home
- Titanous 11y ago
  No current plans, but if there's enough demand for it we'd be quite happy to implement it (or accept a contribution!). Please file a feature request on GitHub if you'd like to see it in Flynn: https://github.com/flynn/flynn/issues/new https://github.com/flynn/flynn/issues/new Edited to add: It looks like there is already a buildpack for ASP.NET 5 (uses Mono) that's worth a try: https://github.com/heroku/dotnet-buildpack https://github.com/heroku/dotnet-buildpack
vishvananda 11y ago
I noticed you removed etcd recently in favor of running raft internally. I have a couple of questions: 1) Why did you remove etcd? 2) Why use the hashicorp raft implementation[1] over the coreos raft implementation[2]? [1] https://github.com/hashicorp/raft https://github.com/hashicorp/raft [2] https://github.com/coreos/etcd/tree/master/raft https://github.com/coreos/etcd/tree/master/raft
- Titanous 11y ago
  We didn't really need all the features of etcd, this change is part of a longer term plan to only use Raft for leader election and service metadata with service instances propagated using cluster gossip. We also ran into some issues with etcd that were very hard to diagnose, and the developer who worked on the project was familiar with and confident in the Hashicorp package.
jlu 11y ago
Does it support zero downtime deployment?
- Titanous 11y ago
  Yes, absolutely. We do a rolling deployment of new app instances, requests are not dropped.
  - jlu 11y ago
    Sounds great, will check out the documentation and try to hook it into our CD system, thanks for the update.
matt2000 11y ago
Flynn looks very exciting, congrats! I am having trouble figuring out what the minimal and recommended setups would be across providers. And what exactly happens when I issue scale commands? I'm looking to get an idea of costs to compare different providers, but also to compare against running on heroku. Thanks!
- Titanous 11y ago
  Thanks! Minimum high availability setup would be three nodes with 1GB of memory each, more memory if you're using a heavier application framework like Rails. When you run a scale command Flynn creates new application containers that are balanced across the cluster, so if you scaled to six instances with three hosts in the cluster, you'd end up with two instances on each of the three hosts.
sciurus 11y ago
How would you compare/contrast Flynn to OpenShift 3? http://www.openshift.org/#v3 http://www.openshift.org/#v3
mikejarema 11y ago
Congrats on the release, looks like a great platform for my use case (an app with a series of microservices, each of which needs to scale independently and for which requests are usually long running). I do have a question re: Flynn's router. The router README [1] states that it uses a random load balancing algorithm. I worry that at scale it would exhibit issues similar to what Heroku's "routing mesh" has (had?) as explained in [2], namely that some nodes would sit idle while others simultaneously let requests build up in their queue, hurting overall latency and reducing the marginal value of each additional node. Any chance of something like HAProxy's leastconn algorithm landing in Flynn's router to mitigate this type of worry? [1] https://github.com/flynn/flynn/tree/master/router https://github.com/flynn/flynn/tree/master/router [2] http://genius.com/James-somers-herokus-ugly-secret-annotated http://genius.com/James-somers-herokus-ugly-secret-annotated
- Titanous 11y ago
  Great question! We're aware of the Heroku issues, and they don't fully apply in our case. We currently do not have any queues in the router other than the kernel's accept queue. All incoming connections are assigned a goroutine immediately and the requests are proxied back to service instances without queuing. So if your application instances can handle concurrent requests, the performance impact of random load balancing should not be huge. We are absolutely open to implementing other balancing algorithms, including least connections. The one caveat is that at any time multiple routers will be in operation and we're not going to do extensive coordination between them, so the balancing will never be perfect.
  - mikejarema 11y ago
    Got it, makes complete sense. Thanks for the direct answer. A bit more info on the app I'm thinking of testing with Flynn: each instance has a single dedicated resource (actually a psuedo terminal sitting on top of a command line tool). Any given instance is incapable of handling requests concurrently, they queue up at the instance. So the app's concurrency model relies on smart load balancing at the router itself. I've got HAProxy playing this role, but have done a bit of a hack job juggling the containers which implement the various microservices. I'll give Flynn a go to see if the simplicity it gives me in managing my deployment is worth the routing tradeoff for now, but I would definitely love to see Flynn's router adapted as you describe.

TranquilMarmot 11y ago

Any plans to support C#/ASP.NET? If you haven't seen it yet, ASP.NET nVext will ship with native support for Linux/OS X and is much more package-oriented so it would lend itself pretty well to Flynn. It's still in beta, but I think they're planning a full release in Q1 2016. https://github.com/aspnet/home https://github.com/aspnet/home

Titanous 11y ago
No current plans, but if there's enough demand for it we'd be quite happy to implement it (or accept a contribution!). Please file a feature request on GitHub if you'd like to see it in Flynn: https://github.com/flynn/flynn/issues/new https://github.com/flynn/flynn/issues/new Edited to add: It looks like there is already a buildpack for ASP.NET 5 (uses Mono) that's worth a try: https://github.com/heroku/dotnet-buildpack https://github.com/heroku/dotnet-buildpack

vishvananda 11y ago

I noticed you removed etcd recently in favor of running raft internally. I have a couple of questions: 1) Why did you remove etcd? 2) Why use the hashicorp raft implementation[1] over the coreos raft implementation[2]? [1] https://github.com/hashicorp/raft https://github.com/hashicorp/raft [2] https://github.com/coreos/etcd/tree/master/raft https://github.com/coreos/etcd/tree/master/raft

Titanous 11y ago
We didn't really need all the features of etcd, this change is part of a longer term plan to only use Raft for leader election and service metadata with service instances propagated using cluster gossip. We also ran into some issues with etcd that were very hard to diagnose, and the developer who worked on the project was familiar with and confident in the Hashicorp package.

jlu 11y ago

Does it support zero downtime deployment?

Titanous 11y ago
Yes, absolutely. We do a rolling deployment of new app instances, requests are not dropped.
- jlu 11y ago
  Sounds great, will check out the documentation and try to hook it into our CD system, thanks for the update.

matt2000 11y ago

Flynn looks very exciting, congrats! I am having trouble figuring out what the minimal and recommended setups would be across providers. And what exactly happens when I issue scale commands? I'm looking to get an idea of costs to compare different providers, but also to compare against running on heroku. Thanks!

Titanous 11y ago
Thanks! Minimum high availability setup would be three nodes with 1GB of memory each, more memory if you're using a heavier application framework like Rails. When you run a scale command Flynn creates new application containers that are balanced across the cluster, so if you scaled to six instances with three hosts in the cluster, you'd end up with two instances on each of the three hosts.

sciurus 11y ago

How would you compare/contrast Flynn to OpenShift 3? http://www.openshift.org/#v3 http://www.openshift.org/#v3

mikejarema 11y ago

Congrats on the release, looks like a great platform for my use case (an app with a series of microservices, each of which needs to scale independently and for which requests are usually long running). I do have a question re: Flynn's router. The router README [1] states that it uses a random load balancing algorithm. I worry that at scale it would exhibit issues similar to what Heroku's "routing mesh" has (had?) as explained in [2], namely that some nodes would sit idle while others simultaneously let requests build up in their queue, hurting overall latency and reducing the marginal value of each additional node. Any chance of something like HAProxy's leastconn algorithm landing in Flynn's router to mitigate this type of worry? [1] https://github.com/flynn/flynn/tree/master/router https://github.com/flynn/flynn/tree/master/router [2] http://genius.com/James-somers-herokus-ugly-secret-annotated http://genius.com/James-somers-herokus-ugly-secret-annotated

Titanous 11y ago
Great question! We're aware of the Heroku issues, and they don't fully apply in our case. We currently do not have any queues in the router other than the kernel's accept queue. All incoming connections are assigned a goroutine immediately and the requests are proxied back to service instances without queuing. So if your application instances can handle concurrent requests, the performance impact of random load balancing should not be huge. We are absolutely open to implementing other balancing algorithms, including least connections. The one caveat is that at any time multiple routers will be in operation and we're not going to do extensive coordination between them, so the balancing will never be perfect.
- mikejarema 11y ago
  Got it, makes complete sense. Thanks for the direct answer. A bit more info on the app I'm thinking of testing with Flynn: each instance has a single dedicated resource (actually a psuedo terminal sitting on top of a command line tool). Any given instance is incapable of handling requests concurrently, they queue up at the instance. So the app's concurrency model relies on smart load balancing at the router itself. I've got HAProxy playing this role, but have done a bit of a hack job juggling the containers which implement the various microservices. I'll give Flynn a go to see if the simplicity it gives me in managing my deployment is worth the routing tradeoff for now, but I would definitely love to see Flynn's router adapted as you describe.