Flynn Beta (YC S14) | Hacker News Reader

Flynn Beta (YC S14)

flynn.io

150 pointsdubcanada70 comments

Flynn still needs to do a much better job on the documentation front. It's entirely unclear how to use Flynn. Instead of just having vague architecture/philosophy discussions, they need very clear explanations.

From the demo/documentation they do have, it's unclear why Flynn is better than Deis, Heroku, etc.[1]

I had hoped that Flynn was/would be a tool for orchestrating complicated multi-container apps, not just deploying Procfiles. I don't need Procfiles, I need something which will let me integrate and orchestrate multiple Docker containers across multiple nodes. Most/many significant apps don't fit into the simplicity of Procfiles (we have over a dozen different services, some with relatively customize environments, all communicating with RabbitMQ middleware). At least for development, Docker containers have proven to be an ideal way to manage these services. As of yet, there doesn't seem to be a good tool for deploying them to production. I wish Flynn would tackle that head on (and document it!), instead of being yet another generic PaaS.

[1] https://github.com/flynn/flynn/tree/master/demo

While Flynn is capable of a lot more, as evidenced by its architecture, leading up to the first production release we're focused on solving some of the simpler use cases really well.

A solid "private Heroku" was the primary desire of a lot of our early sponsors, and we want to make sure we deliver on that promise.

Once Flynn is stable, we can focus on the more complex use cases which, frankly, are what really excites our team.

Is private heroku still the right thing to build? I don't know the answer, it just sounded like you're building it because you said you would, but along the way have you found other/better use cases?

Take a look at Fedora's atomic host. Heck, if all you need is orchestration of multiple hosts with docker containers, you only need a single bit from project atomic, geard[1].

[1] http://openshift.github.io/geard/

FWIW, Deis really wants to help orchestrate multiple containers across nodes. There's talk about scheduling/pinning apps to certain nodes (such as if you really need your workers on a machine with more CPU), and currently we also support deploying from both Dockerfiles and pulling images bit-for-bit from an in-house registry or from DockerHub. We have documentation, but ASCIIcasts seem to show this workflow better. Check it out! http://deis.io/demo-deis-pull-in-action/

I dig what Deis is doing here, but for me it's no good until it can run under Mesos (which is coming, I gather). I have more than just Deis needing to grab resources in my cluster.

It's on the roadmap :)

> It's entirely unclear how to use Flynn

I'll go a step further: it's unclear _what_ Flynn is. I read the homepage and was still confused.

I am standing at the same step as you. It is confusing what is Flynn. Maybe it is CLU (Codified Likeness Utility) created by Kevin Flynn of TRON.

Flynn.io needs to fight for the user experience... no docs = poor UX

I think in this case it's no docs = no UX

I've given it a test but all it's done is cost me a couple of micropennies on aws so far, I'm nowhere closer to understanding

Same here. How it is possible nowadays to have fronpage that is impossible to understand what your flagship product do.

I know what it is only from being around since it's inception. If I was new to it, I'd probably be confused too.

I've been around since its inception and I've no idea what it does.

It could do with the "explain like I'm 5" version - can I put wordpress on it and have it auto scale over my servers? Is that even a valid use case for this, does Flynn even do that sort of thing?

Like I say I've realised I actually have no idea what Flynn does

> Flynn still needs to do a much better job on the documentation front. It's entirely unclear how to use Flynn.

Yes. I mean nothing bad about the people behind it in saying this, but this is kind of a red flag to me for this kind of project - ie: when you're talking about basic infrastructure I look to see that the people behind it have a culture of continuous and rigorous documentation. Features shouldn't be allowed to be released in any form unless the documentation for them is included. If the product is as far along as it claims to be (a beta available), yet there is still almost zero documentation (at least, as evidenced on their site), then it's in a seriously bad situation. I'd urge them to do some reflection about this and institute some policies that ensure that documentation is emerging as a natural part of their process and not an afterthought that they plan to address later.

I tried reading most of the site and didn't understand what exactly it is. Am I the only one who doesn't have a clue on what "ops" is/are?

This was my take away. I just figured the people who need this product would understand. I'm still really confused.

I know what "ops" is... but they do need to work on better messaging of their product (it's hard to do). I kinda missed the point of what they are doing, how are they better than AWS OpsWorks or other PaSS.

Nope i spent a few minutes browsing the site and still don't understand the solution they present.

It's Ops as in DevOps: http://en.wikipedia.org/wiki/Devops

Thanks!

Ops is what you do after you write an application. Deploying it to one or more servers, connecting to databases, detecting, diagnosing, and fixing problems.

Flynn is a layer of software that sits between your application code and the servers it runs on to make all of that a lot easier, especially at scale.

Flynn is open source heroku.

I like this tag line! Maybe Flynn guys should use this.

Well, "open source Heroku" implies that they're compatible with Heroku's API. That means application release management, runtime configuration (config:set), application collaboration via "sharing"... From what I see in https://github.com/flynn/flynn/tree/master/demo, half of the API isn't there yet. We'll see how it goes over the next few months.

We certainly not cloning Heroku's API, but we have most of the things you describe and much more in our API and CLI, including release management, configuration, job control, resource provisioning, log access, docker image releases, interactive and detached one-off processes, etc.

It's not actually like that, it is it's own product, but this helps you understand what it kinda does.

I feel like this post would benefit from a succinct description of what the product is either in the title or on the linked page.

I'm not sure if the title box has enough characters to explain it properly. Basically it's a PaaS framework that can be hosted on your own environment.

Anyone have any ideas on what to put?

I'd describe Flynn as a private version of Heroku, not sure if they'd like that description or not though.

Flynn is a (adjective) PaaS platform that can be hosted on your own servers so you can make it work for you.

Flynn can (verb) as a PaaS platform that allows you to do what you need to within your existing infrastructure.

Flynn runs on your servers as a PaaS platform that you can build upon to (whatever a PaaS does).

I don't really know what PaaSes do, but those should work if you find interesting words (not just generic ones) to put where I've noted. Adding extremely informative details in a sub heading would be very beneficial.

I find it almost impossible to figure out what to do with Flynn after I have installed it (just comparing it to deis, deis on the other hand has a large amount of documentation). Is there going to be some more documentation on how exactly stuff is setup and how to manage it now that it is in beta?

Yep, tons more, soon. For now, start here https://github.com/flynn/flynn/tree/master/demo. We're moving this and more like it to the docs.

Documentation is key for adoption, creating a community and having more contributors. I hope they address this soon. :)

As others have raised points about need for better documentation and "didn't understand what exactly it is", I wanted to say that the Story of Flynn is missing a very clear "Why Flynn?". That seems to be at the root of why others aren't fully able to understand you. So, Why Flynn?

Some sentences selected from the post: "It regularly took longer to deploy apps to AWS or our own servers than to write them....It wasn’t just about deploying stateless web apps, it was scaling them....Ops could manage a single platform that provided self-serve resources for development, testing, and production to the rest of the organization...."

I know its not popular to say this: would Google App Engine have solved this, since it was made for this specific use case? The "ops" could have been simplified (yes, GAE has problems - there is lock-in, pricing etc. but that kicks in only after Tent.io has many many users - and that would be a good/welcome problem to solve.

Maybe I am missing something - but I would really like to understand "Why Flynn was made?". Thank you in advance for the clarification.

Flynn cofounder here, happy to answer any questions

What exactly is it? I'm sorry, I don't think I have enough experience to understand from your website

In the simplest sense it's an open source Paas (think Heroku), but with much more flexible technology. It's designed for ops teams who can run a single platform instead of doing custom deployment work for each application and database

Could you explain to me what an ops team is?

Could you also explain to me what running a single platform instead of custom deployment means? A lot of solutions solve that problem. I don't understand how your product does that.

The ops team at a company is the group responsible for running and scaling the apps after they've been written. The role varies from company to company, but in general they manage databases, underlying infrastructure, and other technology that power apps.

You could think of them as the sysadmins or IT team that powers especially public-facing services and websites. Think Twitter, HN, etc. The people in charge for making sure there are no fail whales are the ops team.

Awesome, Thanks!

That seems like something that should be on the website...

Is ongoing development primarily being funded by your sponsors and do you have any (public) plans along other paths for the future?

We're currently raising a VC round (we're in the current YC batch).

We've already done paid support contracts on the enterprise side and are developing the management service into a SaaS offering.

One thing that I really like with other PasS companies is that they package that content up -- setup, architecture, documentation of a n-tier application (I am assuming you already built something like that for contracting work). How would I create a website with database and caching ect... using your services.

Great, thanks for sharing. :)

Any plans to integrate with kubernetes?

No, we have our own scheduling framework and schedulers inspired by the Google Omega paper.

Does https://dashboard.flynn.io build on top of the beta version of Flynn?

I don't really understand this:

"Non-cooperating services often use service discovery information in configuration, such as the backends for a load balancer defined in an HAproxy configuration. A generalized configuration rendering system is used to tie service discovery into most non-cooperating services."

The problem is to generate the config file, which etcd doesn't help.

We can use sdutil[0] to render info from service discovery into a config template.

[0] https://github.com/flynn/flynn/blob/master/sdutil/configure....

Looks like a neat project, best of luck to you!

This is a nitpick, but it really turns me off from coming back to applications, and I'd want to know about it if I were you: after I registered on dashboard.flynn.io, neither the password remembering functionality built into chrome nor my password manager (LastPass) seems to know how to autofill your login form. I haven't looked into why that would be at all, but it's a real nuisance!

What is Flynn? I read the link and the homepage on my phone, and couldn't figure out for the life of me what the product was.

Sorry to be cruel - but I really think you should cut down the usage of buzzwords and abbrevations on your homepage and in describing your service.

I think there is a bug on the pricing page. It appears that the startup plan is more expensive during beta.

http://i.imgur.com/CtWIytj.png

But why use Flynn? Getting a CoreOS cluster up and controlling it with Fleet, and deploying docker images to it, seems quite a bit easier.

Who can come up with a better headline? I like "Open Source PaaS for the Future"

https://www.dropbox.com/s/ret624lf739til4/Screenshot%202014-...

A more clear header would help with messaging.

Not a huge fan of the "for the Future" bit but the rest at least says or hints a bit better as to what it is.

I've been following flynn from the start but honestly I'm less sure of what it is now than I was before it started

It appears that download issues with the ruby buildpack still aren't fixed. Really you guys should be hosting these on your own S3 account as literally every time I've tried to use Flynn or Deis they are unusable because both utilities use heroku hosted buildpacks and they're consistently broken (slugbuilder related I think?).

What download issues do you speak of? They work great in Deis' test infrastructure: http://ci.deis.io/view/example-apps/job/test-integration-rub...

-----> Ruby app detected ! ! Command: 'set -o pipefail; curl --fail --retry 3 --retry-delay 1 --connect-timeout 3 --max-time 30 https://s3-external-1.amazonaws.com/heroku-buildpack-ruby/bu... -s -o - | tar zxf - ' failed unexpectedly: ! ! gzip: stdin: unexpected end of file ! tar: Child returned status 1 ! tar: Error is not recoverable: exiting now

I opened an issue request with Deis a while back for the same problem and they reported it being an upstream issue with slugbuilder.

Edit: Heh, apparently we already talked about this https://github.com/deis/deis/issues/1016

Yep. It was because slugbuilder didn't lock buildpacks to a known working version when you ran a `docker build`. It always pulled master, which may or may not work. We fixed that up, and we're in sync with Heroku's buildpack version that's running in prod now: https://github.com/deis/slugbuilder/blob/deis/builder/instal...

Didn't notice the issue get closed. Thanks! I'll re-install Deis again :D

We're tracking this issue at https://github.com/flynn/flynn/issues/85

To date we've tried to push fixes upstream to buildpacks so that we can avoid the maintenance burden of keeping forks up-to-date.

Understand it's hard to explain. I'd list the canonical use cases, so people know whether to dig in to the docs.

Flynn lets you tie GIT deployment to a system that uses heroku buildpacks and launch using Docker containers. But what if I don't want to use a buildpack but a Dockerfile?

Just gonna leave this here... http://docs.deis.io/en/latest/using_deis/using-dockerfiles/

If you have a Docker image on a registry somewhere you can create a release in Flynn from it using the `flynn release add` command (or the API).

Fwiw, I'd find a single line description of what Flynn is helpful. I gave up trying to find out after seeing a long story on the about page.

Credit-card only option? Sorry, but no thanks. I'll come back to Flynn when I can pay for it with a method other than credit card. (Startups should not assume the whole world wants to use credit cards.)

Reply on news.ycombinator.com