Flynn 1.0 is here
flynn.io
flynn.io
Also, the logo links to the product page, not to some blog aggregation page as many other announcement do.
Not saying there's a legitimate reason to do that, but just saying that's usually the technical reason for it.
What do you recommend? I spent some time last night looking into all the big names atm, Flynn, Deis, Nomad, Kubernetes, Docker, etcetc. They all seem so complex for my needs.
Sure, if my app grows, being able to boot up a few extra VMs, add them to my "cloud", and then deploy my app to my new machines easily sounds appealing, but honestly right now that's so beyond my scope that it seems silly. I just want easy deployments, and easy installation of whatever i end up using (Flynn/Deis/etc).
So with that said.. any opinions on the simplest? Dokku seams to be the simplest.. but it's hard for me to say atm, i don't have much experience of perspective.
Dokku is architecturally simpler because it only focuses on single-host use cases, but we hope Flynn is just as easy or easier to install and use.
Disclaimer: managed cloudron customer (I have not used the selfhosted option).
The other thing that has come in very handy is being able to deploy Dockerfile builds directly, is this something that Flynn can do as well, or is support planned?
Flynn is natively highly available and multi-host, which makes doing volume storage tricky. Our current immediate plan for this is to support NFS mounts for apps so that you can point at an external file server (or service like AWS EFS). Feel free to watch or thumbs-up this issue: https://github.com/flynn/flynn/issues/1521
As far as plugins go, Flynn is entirely API-driven so you should be able to hook in and do whatever you want without modifying Flynn itself. If you run into something that you want to do that makes sense as an integration but isn't currently possible, please open an issue and we can discuss how to make it happen.
> The other thing that has come in very handy is being able to deploy Dockerfile builds directly, is this something that Flynn can do as well, or is support planned?
We support pushing Docker images to a registry built-in to Flynn: https://flynn.io/docs/docker
Building Dockerfiles is currently tricky from a security and modularity perspective as it requires running inside a privileged Docker daemon. There is no way that I'm aware of to do a build without providing root or root-like capabilities. If it was as simple as importing a package and using it in an unprivileged container to perform the build, we'd definitely evaluate adding support carefully.
Funny how much things change and how much they stay the same.
Would it be easier with rkt?
I looked at Deis recently as a future migration option once I outgrow Dokku but the database layer is not really documented or talked about. The blog posts are very hand-wavy when discussing persistent storage.
> You let people deploy and manage lots of applications, whether they’re microservices or monoliths, written in any combination of languages.
> You make running software faster and easier so developers can ship their code with less friction and spend more time creating applications and products.
> You bring resilient, scalable, and efficient infrastructure to everyone. You are a single, unified, easy-to-use platform.
> Developers and companies around the world are using you to power everything from their latest side project to their startup’s most important products in production.
> This is just the beginning of your development, and we’ll have many more features to announce in the coming months. For now, you are solid, stable, and ready to use.
> You are fast and easy to install on popular clouds with our graphical installer or on your local machine with Vagrant. Try it today and see how far we’ve come.
Unfortunately we're a small team and frequently travel to events, etc. So it's expensive for us to guarantee that someone will be around. Obviously we'd like to provide support to as many people as possible at the lowest possible rate, so as we have more people paying for support and economies of scale kick in we hope to be able to drop those prices. In the meantime we need to cover our costs or development will stall
edit: our current prices are also based on the level of support that our most active beta users needed. Now that we're past 1.0 hopefully users will need less help which will also help lower prices. We have a very high bar for support quality and don't want to overextend ourselves to the point where we can't deliver
I feel like our current deploy infrastructure doesn't need to be replaced if it means forking over $1500+ a month.
Most current users (from individual developers to large organizations) haven't needed or wanted commercial support contracts. The offering is there for organizations who need significant help and/or an absolute guarantee that they'll be able to reach us at any hour of the day, every day of the year.
To compare with Flynn, their current pricing is $74-75/node, which is quite a bit more. However, Flynn appears to offer more 1 on 1 support whereas Cloud66's is extra.
Nonetheless, there's quite a bit of difference. I think the range of $20/node may be reasonable. Anything less, the company would be unable to grow. In fact, especially for early stage startups, I'd probably err on the side of a higher pricing (eg. $30-40).
The paid plan is not for the side project but for funded projects or ones that already have money coming in.
Flynn is also a whole lot easier to get set up. Again, just what I've observed based on an earlier release.
Instead of relying on a lower layer like BOSH, Flynn is self-bootstrapping and self-hosting. It runs everything except the container runner in containers managed by the platform. The same APIs and tools are used to manage user applications and Flynn components.
For more information, check out our Architecture page: https://flynn.io/docs/architecture
You can bring your own lower level infrastructure, like IaaS or bare metal. There is a cloud installer that can spin up a cluster to try out on EC2, Azure, or Digital Ocean, but most production users are using whatever management tools they are comfortable with to deploy and scale Flynn hosts out.
Dokku is explicitly single-host. Flynn can run in a single-host configuration but typically deployed in a highly available configuration with three or more hosts.
Flynn is designed to tackle some much bigger problems and supports running and managing highly available databases inside the platform out of the box in addition to stateless web apps.
At Pivotal we're seeing multi-thousand VM instances of Cloud Foundry that BOSH deploys and updates gracefully.
We're watching Kubernetes, it's possible that doing that change will make sense at some point in the future.
The front that flynn exposes is pleasently simple, but I also want to know what implies every command and how it affect the running environment.
There is an architecture page: https://flynn.io/docs/architecture
Please let me know if anything specific is missing so that we can add it.
> Can I choose to dedicate a host to run a db, and at the same time run serveral mini-processes without launching every one in a container?
You can dedicate specific hosts to specific apps and process types using node tagging, though it looks like we are missing documentation for that. I'll make sure it gets added soon.
You are free to fork multiple processes inside of containers you deploy, there doesn't need to be a 1:1 mapping of container to process.
Let me know if there is something else specific that you are wondering about and I can answer here or get some more docs up.
It has allowed the rest of the team to focus on the apps themselves without worrying about how to deploy them, how to provision more capacity, how to rollback in case of failure, etc.
Using the builtin affinity and priority system, we were able to make sure that production apps would always run smoothly without being affected by our other processes.
We host about 10 small apps/services in it. They vary from things that do (basically) a single simple API call to full Rails apps.
Experience has been very positive. We had our share of "pre 1.0" issues, to be sure. But, the team in #flynn (IRC) is incredibly responsive. It's been a pleasure watching the issues get resolved, merged, and deployed very rapidly.
Digging into the code too, it's easy to follow and feels quite nicely architected.
Aside from all of that, my team is thrilled to have its own little PaaS.
"If you can explain the problem better than the customer, they'll believe you also have the solution."
There was a Github issue before about, but I don't have that link around.
Could someone from the dev team at flynn comment about how flynn self heals currently if there's a server issue? eg. especially the one where the DB is hosted
Thanks and congrats!
We use a combination of Raft for service discovery and leader election, along with multiple instances of all core services so host failures within the quorum tolerance should not impact availability. The design of the data appliances is carefully considered, you can read an overview here: https://flynn.io/docs/databases
If something catastrophic does go wrong, like the power going off in the datacenter, there is code that can resurrect the cluster when enough hosts come back online.
We did have some issues with recovery that have been fixed over the past few months, I'm almost certain the issue that you ran into has been fixed. Data is never destroyed by Flynn, so it's possible to recover the database from disk even if Flynn isn't running.
The system is also designed to tolerate partial failures gracefully, so if for example service discovery fails, the router will fall back to a cache and HTTP clients should not notice that anything is wrong.
Flynn has a larger technical scope, covering everything from the details of how container are run all the way up to the user interface used to deploy applications. We also run highly available databases within the platform, in addition to stateless webapps. As a result of working to build an easy to use unified solution, we've ended up building many components from scratch specifically for Flynn and have very few dependencies.
Deis is designed to use commonly used off the shelf components, and has a focus on stateless web apps. Currently Deis is built around the Kubernetes and Docker ecosystems.
Flynn's approach has given us more flexibility, but it has taken longer, so Deis has often reached various milestones faster.
It's a frequently asked question so hopefully in the future a well-informed user with experience on both platforms can write a detailed teardown/comparison.