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.
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.
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].
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?
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.
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.
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.
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.
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.
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?
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.
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 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.
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!
"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.
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.
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?).
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...
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?
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.)
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