9 ms·

Flynn: open source PaaS

253 points by cheiVia0 10y ago

harigov 10y ago
This is really cool. I am not sure if there is a way to deploy this on public cloud like AWS/Azure. If this were cloud agnostic way of building software, I would be totally into it.
- joshmn 10y ago
  That's kind of the whole purpose of it. > The CLI includes a local browser-based installer that can boot and configure a Flynn cluster on Amazon Web Services, Digital Ocean, Azure, and your own servers via SSH. It automatically performs all of the steps required to install Flynn. https://flynn.io/docs/installation/cloud https://flynn.io/docs/installation/cloud
  - harigov 10y ago
    Thanks! I know this is slightly different from what Flynn is trying to do, but what I was looking out was a way to use standard cloud provided PaaS rather than using cloud as IaaS. This approach may work fine in the short-term but cloud native services provide a lot of extra functionality (monitoring, security, sandboxing, eventing, logging, encryption, etc.,) that would be hard to replicate for something like this. An abstraction to those cloud native service, OTOH, may be useful against lock in. I believe it should be possible given that most of the cloud native services across different clouds provide similar set of features.
- EngineerBetter 10y ago
  You should take a look at BOSH. http://bosh.io http://bosh.io It allows the same distributed system to be defined and run on AWS, GCP, Azure, vSphere, OpenStack, tin, and more.
- danielsiders 10y ago
  Thanks! Flynn is designed to be cloud-independent so you're not locked in to any cloud, or even cloud in general. You can also run Flynn on your own servers. Flynn also allows portability between clouds. Since we don't use any cloud-specific features (like, say RDS) you can backup a Flynn cluster (including database appliances) from one cloud and deploy onto a new cluster on an entirely different cloud.
deleted 10y ago
[deleted]
corobo 10y ago
I've been using Flynn for a while now. Unfortunately there's always something that entirely bricks the cluster eventually. Sometimes a node will reboot unexpectedly (as happens with servers) and the cluster slowly implodes from there, sometimes I'll just get a monitoring alert that all the sites hosted on it have gone down for no apparent reason. They announced during their 1.0 release that Flynn is now production ready but I have to disagree at this time. I do honestly love the idea of running my own Heroku but it's just not stable enough and doesn't recover well if a node goes offline without manual intervention using the flynn-host fix command (and sometimes that command just chokes up completely). Next time it happens (when, not if, at this rate) I'll try to set aside some time to gather up the logs to help debug the problem but I'm using Flynn to avoid the sysadmin side of things and just build my product. In my opinion Flynn is tinker-ready, not production-ready. It's infuriating that it has these random problems because like I say I really _really_ love the product and desperately want to be able to use it reliably.
- merb 10y ago
  > Sometimes a node will reboot unexpectedly (as happens with servers) if it's coreos it's probably the auto update mechanism.
  - corobo 10y ago
    Not in this case, Flynn runs on Ubuntu 14.04. I think the reboot was a DigitalOcean droplet's host being restarted at the time though I can't be sure.
  - nathancahill 10y ago
    Unbelievable that auto update is the default. Got bit by that.
- _lmars 10y ago
  Really sorry to hear you have had issues with your Flynn cluster. Stability is our number one concern and we are pushing stability fixes all the time. Flynn does self-heal after node reboots, so if that is not working for you then it is a bug we need to fix. When you do have issues it would be really helpful to us and other users if you could open a GitHub issue or come and chat to us in IRC (#flynn on Freenode) so we can fix any bugs you are encountering. I fully understand you just want to be concentrating on building your product, this is why we are building Flynn!
ngrilly 10y ago
Is it possible to store file in some kind of NFS volume? Is it possible to store objects in something similar to S3 (for example using Minio)?
- _lmars 10y ago
  > Is it possible to store file in some kind of NFS volume? NFS support is not currently implemented, but we have a clear plan and it is on our upcoming roadmap: https://github.com/flynn/flynn/issues/1521 https://github.com/flynn/flynn/issues/1521 > Is it possible to store objects in something similar to S3 (for example using Minio)? Flynn has a built-in blobstore for storing files and supports multiple storage backends: PostgreSQL Large Objects (default), Amazon S3, Google Cloud Storage and Azure Storage (to be released into stable next week), see https://flynn.io/docs/production#blobstore-backend https://flynn.io/docs/production#blobstore-backend.
  - ngrilly 10y ago
    The documentation about the blobstore says PostgreSQL should be used only for small deployments. What if you deploy Flynn to DigitalOcean, which has no S3-equivalent?
    - Titanous 10y ago
      You can use S3, Google Cloud Storage, or Azure Storage even if you're running on DigitalOcean.
      - ngrilly 10y ago
        Yes, but at the cost of increased latency, and paying the bandwidth?
        DeadBabyOrgasm 10y ago
        There's also expandable block storage (https://www.digitalocean.com/products/storage/ https://www.digitalocean.com/products/storage/), though I'm not sure if it fits these circumstances.
Mojah 10y ago
Happy to see Flynn get more adoption, it got featured in the cron.weekly newsletter a few months back, when it was in the earlier stages; https://www.cronweekly.com/issue-39/ https://www.cronweekly.com/issue-39/
spamlord 10y ago
How does this compare to Cloud Foundry?
- EngineerBetter 10y ago
  Good question - I dare say it is nowhere near as battle-tested in production.
  - EngineerBetter 10y ago
    Caveat: I run a Cloud Foundry consultancy. A quick glance shows a couple of things: * Automatic cluster scaling, so your PaaS deployment is as small as possible. Cloud Foundry doesn't have this, and I wish it did * Flynn has built-in service discovery, in Cloud Foundry you bring your own (if you want) * Flynn comes bundled with some data services * Flynn has no BOSH equivalent, so there's nothing there to bring back VMs when they fail, perform rolling upgrades or manage the IaaS * Flynn doesn't seem to offer a metrics stream, only logs * Flynn builds apps from source, so not sure how that works for compiled Java/Go, or anything you'd run with a binary buildpack * I couldn't find anything about role-based access control in Flynn, something Cloud Foundry has (which can be backed by LDAP for enterprises) * Flynn only appears to route HTTP traffic, so no TCP routing for IoT workloads * Cloud Foundry is run at massive scale in production for mission-critical workloads by banks, payment processors, IoT data ingesters, manufacturing companies, research companies, governments and everything inbetween. I can't see any evidence of the same being said for Flynn. * Flynn is owned by one company, Cloud Foundry is owned by a non-profit organisation affiliated with the Linux Foundation and can never be transferred back to a regular company. This prevents the sort of nonsense you've seen in the Docker community recently.
    - _lmars 10y ago
      > Flynn has no BOSH equivalent, so there's nothing there to bring back VMs when they fail, perform rolling upgrades or manage the IaaS Flynn auto-heals after node restarts (and if it doesn't that is first and foremost a bug we need to fix), but also has a cluster monitor service which brings services back online automatically, and as a last gasp there is `flynn-host fix` for manual intervention. Flynn has node promotion / demotion so you can totally do rolling upgrades (users have reported they do this with a modified CloudFormation stack for example). There is also a built-in updater to update to a more recent version of Flynn. > Flynn doesn't seem to offer a metrics stream, only logs Something I think should be built-in, but there are many off the shelf solutions which can be deployed to Flynn as apps. > Flynn builds apps from source, so not sure how that works for compiled Java/Go, or anything you'd run with a binary buildpack Flynn has built-in buildpacks but also supports running custom buildpacks (see https://flynn.io/docs/apps#buildpacks https://flynn.io/docs/apps#buildpacks). If you just want to deploy binaries, you can either: - use the inline buildpack: https://github.com/kr/heroku-buildpack-inline https://github.com/kr/heroku-buildpack-inline - deploy a tarball: https://github.com/flynn/flynn/issues/306#issuecomment-233211243 https://github.com/flynn/flynn/issues/306#issuecomment-23321... - deploy a Docker image: https://flynn.io/docs/docker https://flynn.io/docs/docker > I couldn't find anything about role-based access control in Flynn, something Cloud Foundry has (which can be backed by LDAP for enterprises) Flynn does not currently have strict access control, but work is very much on the way, see our security improvements project: https://github.com/flynn/flynn/projects/1 https://github.com/flynn/flynn/projects/1. > Flynn only appears to route HTTP traffic, so no TCP routing for IoT workloads Flynn supports TCP routes, although it does not seem to be documented very well: https://flynn.io/docs/cli#route https://flynn.io/docs/cli#route
sztwiorok 10y ago
what gives you more than docker-compose itself? with docker-compose and docker swarm I can easily add services there, configure the application environment and scale it. seems interesting but please enumerate things I can do that are not delivered by docker compose and docker swarm.
- _lmars 10y ago
  A main advantage of Flynn over using docker-compose is that Flynn is more aware of how to run applications out-of-the-box, rather than just running containers which the user has to fully configure. For example, Flynn comes with PostgreSQL, MariaDB and MongoDB appliances which are deployed in a highly available, fault tolerant configuration with sane defaults: https://flynn.io/docs/databases https://flynn.io/docs/databases. Through the use of buildpacks, it is also straight forward to deploy applications written in many popular languages and frameworks without being intimately acquainted with how to containerise those types of applications (e.g deploying a Ruby on Rails app on JRuby: https://flynn.io/docs/languages/ruby https://flynn.io/docs/languages/ruby). You also get things like full cluster backups (including all your data), simple git / docker / tarball based deployments, log aggregation, release rollbacks, domain / path based routing, service discovery, and many more!
- EngineerBetter 10y ago
  Both this and other PaaSes remove a lot of the plumbing. Also, the target audience is different. PaaSes offer self-servixe for end users: for instance starting a new database on demand through the user interface. You can achieve much of this with Docker Compose, but your users can't. The Docker-PaaS movement reminds me of content-management systems in the early 2000s. Everyone (myself included) thought it'd be great to spend loads of engineering effort reinventing the wheel, instead of delivering business value.
Kiro 10y ago
Completely OT but was this posted because of the "Remediation Plan for WoSign and StartCom" thread from yesterday?
- cheiVia0 10y ago
  No, because of https://news.ycombinator.com/item?id=12703121 https://news.ycombinator.com/item?id=12703121
weitzj 10y ago
Does anybody have experience with Cisco Mantl (Mantl.io) ? It looks like CloudFoundry or Flynn, but I never saw it mentioned on HN.
- mongrelion 10y ago
  I worked on Mantl for a while last year. To understand the difference you can see Mantl just as an opinionated coalition of tools for running microservices. So, Mantl is not a thing but a collection of things (Mesos, Marathon, Consul, ELK stack, etc) put together using Ansible playbooks. Flynn is an actual product which, from what I can see, is also a collection of tools but these are written by the Flynn team themselves. I'm happy to answer any other question you might have about it.
  - smartbit 10y ago
    Thank, makes sense. Feels like Mantl can go with the flow, add products when they become trendy. And from the perspective of the developer, does Mantl offer a similar PaaS experience as Heroku or Flynn?
- sargun 10y ago
  If you're interested in Mantl, I'd look at Mesosphere's DC/OS. It's very similar. Disclaimer: Work for Mesosphere
  - smartbit 10y ago
    Does DC/OS out-of-the-box support 'git push' for deployment? See https://flynn.io/docs/basics#deploy https://flynn.io/docs/basics#deploy
- stonith 10y ago
  I worked on it for a few weeks while contracting at Cisco. At the time it was a set of tools for deploying a Mesos + Marathon cluster, and K8s was being looked at as a sub-in replacement for Marathon. I think that's now been done + much more. There wasn't any particular magic in it, more that it was a neat package of terraform+ansible tooling for getting mesos and the surrounding ecosystem going. This was about a year ago, so things may have changed since then. I do like the idea of not inventing your own paas, but rather having a consistent framework for deploying whatever kind of paas you need on whatever cloud is available.
duncanawoods 10y ago
Question for the Flynn team: For us to invest time/effort adopting a PAAS solution requires an amazing amount of trust in your ability to execute now and in years down the line. Unlike alternatives, you are a company and not an industry collaboration / foundation, how open can you be to make us believe you are not the next RethinkDb-like shutdown? e.g. How many in your team, why can they do this, how much funding do you have, what is your burn, when do you become default-alive?
- arekkas 10y ago
  that's the whole point, you don't need a lot of time to adopt flynn. it's not that "getting BOSH to work was my life for the last 3 weeks" kind of experience.
  - dahdum 10y ago
    Not the whole point, for all we know Flynn could be out of business in 6 months and they'll be stuck on a platform with no future and saddled with switching costs. Not saying it's likely, but it's a risk worth considering.
    - arekkas 10y ago
      i should have said: that's the whole point for using a buildpack/docker paas in the first place. a) it's not hard to set up flynn b) migrating to another buildpack system is not a lot of work, except setting up some environment variables and installing a cli
- MattRogish 10y ago
  Disclaimer: I founded a DevOps (now Kubernetes) consulting company. We, up until recently, had our own (closed source) ansible/terraform/packer immutable AWS-based PaaS sort of thing. We abandoned it in July when Kubernetes hit 1.0. It's not just if Flynn and Convox and other VC-powered startups whomever can even exist another couple of years - but whether they exist and if they can out-compete Docker and CoreOS and Kubernetes and... etc. My feeling is that a lot of infrastructure companies died in July. Just like Blackberry after the iPhone - gradually, and sometime in the future, suddenly. What's the future for these PaaS companies? I dunno. Consulting services? Managed PaaS? These are fine, but... have a finite growth curve. Not everyone wants or needs to be a unicorn - for sure - but if you're tying your SaaS or web business to someone's infrastructure code, you kinda want: a) the thing everyone else is doing (so you can grow your own team eventually - it's easier to hire a kube developer than a eg. flynn dev) b) something that will be around for a long time and c) something that has the best blend of features/power/ergonomics (Kubernetes has almost 1,000 contributors. Flynn: 98. Convox: 52. Bigger isn't always better, but...) For us, that's kube. We're still iterating on our our business model - perhaps we just stay as a kube consulting shop for a good while - but running an Open Source PaaS business is not where we think the puck is heading.
rcarmo 10y ago
I love this kind of thing so much that I built my own: https://github.com/rcarmo/piku https://github.com/rcarmo/piku (Originally coded to deploy services on the Raspberry Pi, but now used on "real" machines too)
erowtom 10y ago
Experienced Flynn last year, we spent about 2 weeks making it work properly with our solution (We had a complex SaaS solution hosted on Heroku, with tons of addons). We had some very bad bug that happened at the time (like deploying a new version made the dyno crash and we had to deploy a completly new environment). Other than pretty bad bug, it was working properly, and did what they sell. Good point is that the dev team is very responsive and we reported a bunch of bug that got fixed in no time. They also have a smooth updater when a new Flynn release came out, side bad note is at this time, it was kinda bugged (because of our specific setup). For all those reasons, we choose to stick with Heroku at that time (we also tried Doku https://github.com/dokku/dokku https://github.com/dokku/dokku, various AWS services such as BeanStalk, and DEIS http://deis.io/ http://deis.io/), but for sure it was the best candidate out there and I would love to give it a try again.
- _lmars 10y ago
  We have pushed a ton of stability fixes recently, and we now have a stable release channel which we release to monthly (see https://flynn.io/docs/stability https://flynn.io/docs/stability). I highly suspect many of the bugs you encountered have been fixed, and we make it a priority to investigate and fix reported bugs as quickly as possible, so if you end up giving Flynn a try again let us know if you have issues and we'll fix them. As for updating, the in-place updater still has some kinks but the backup / restore route is fully tested and is reliable (see https://flynn.io/docs/production#updating https://flynn.io/docs/production#updating).
stanislavb 10y ago
Note: Flynn seems to be the most popular package on "Awesome SysAdmin" under the category "Cloud Computing" https://sysadmin.libhunt.com/categories/1727-cloud-computing https://sysadmin.libhunt.com/categories/1727-cloud-computing
softwarelimits 10y ago
no autoscaling.
stemuk 10y ago
Looks pretty cool, do you have any plans to add RethinkDB support?
- Titanous 10y ago
  No current plans, but feel free to request it in a GitHub issue. We consider the number of votes on GitHub when adding to the roadmap.
exratione 10y ago
I've worked with a group using Flynn to host a score of internal apps. It required one full time developer to keep it running, and saved a bunch of time and effort for the people maintaining those apps - no need for devops, pretty much, as deployment boils down to a ten line bash script. So if that tradeoff works for you, you should consider using Flynn. In this age of it being next to impossible to hire devops folk, the idea that you can have one of them servicing the devops requirements for a sizable fraction of developed applications is somewhat attractive. I wouldn't put Flynn in place for external-facing and high-traffic applications at the present time based on the experience I've had with it, however. Not ready for that, I think. You have to have a fair tolerance for short outages.
omouse 10y ago
How does this compare to OpenShift?
epynonymous 10y ago
having worked on cloud foundry platform in the past, paas was extremely exciting at the time (2012), we even came up with something called warden which was way before docker. but since then, i have to ask, is there really that much benefit to having a paas? i understand the arguments about not needing to have devops/sre's, etc, but i think iaas works just fine, sure there's the initial plumbing for things like load balancers, installing an operating system, upgrading/patching that operating system, securing all the network connections, but it's not an everyday task. cloud foundry at the time required a minimum of 20 vm's to get the environment running (cloud controller, bosh, service nodes, dea's, nats, etc), and these weren't your t1 micro aws machines, these were memory and processor hungry instances; to manage the entire environment required a team of sre's and devops. nice to see that flynn only requires 3 nodes minimally, but as the environment scales, you'll need more nodes and i wonder how the overhead scales with flynn. obviously for small environments (let's say 6 vm's, an additional 3 vm's to support flynn is not ideal). but if you get up into the 20+ vm arena, perhaps the overhead starts to pale in comparison? perhaps it's just me, but the devops part isn't that annoying, yet, but i've got an ultra small environment running nginx, golang binaries, and some services like rdb and k-v store.
- epynonymous 10y ago
  not sure why this was down voted, but whatever, my questions remain and if anyone is willing to answer, i'd appreciate that.
  - duncanawoods 10y ago
    Looks like a decent question, I upvoted. I think the main motivation compared to IAAS is to run on your own choice of machine e.g. on-premise or dedicated from OVH/Hetzner, or across different cloud providers while not incurring the full admin overhead of baremetal. The reasons can be portability, control, performance, privacy or the potential for 1-2 orders of magnitude cost-savings. And yes, scale, high availability, self-healing, auto-scaling & load balancing is where the admin pain comes in.
    - 10y ago
splitrocket 10y ago
The bit that made the decision for me is managing self healing, highly available postgres in the same infrastructure and tooling as the rest of my deployment. I have yet to see any other PAAS come close to offering HA postgres built in. The second bit was dead simple service discovery.
tomhallett 10y ago
Does anyone have any experience with Rancher? I feel like it would fill a comparable role as Flynn. But I might be off base here.
jondubois 10y ago
I'm working on a similar service, but focused around my own open source stack: https://baasil.io/ https://baasil.io/ The main issue with deployment/orchestration platforms is that they cannot handle ALL different kinds of stacks/apps (each one has unique scalability requirements). With Baasil.io, our strategy is to get it 100% working and auto-scalable; one stack at a time.

253 points by cheiVia0 10y ago

This is really cool. I am not sure if there is a way to deploy this on public cloud like AWS/Azure. If this were cloud agnostic way of building software, I would be totally into it.

joshmn 10y ago
That's kind of the whole purpose of it. > The CLI includes a local browser-based installer that can boot and configure a Flynn cluster on Amazon Web Services, Digital Ocean, Azure, and your own servers via SSH. It automatically performs all of the steps required to install Flynn. https://flynn.io/docs/installation/cloud https://flynn.io/docs/installation/cloud
- harigov 10y ago
  Thanks! I know this is slightly different from what Flynn is trying to do, but what I was looking out was a way to use standard cloud provided PaaS rather than using cloud as IaaS. This approach may work fine in the short-term but cloud native services provide a lot of extra functionality (monitoring, security, sandboxing, eventing, logging, encryption, etc.,) that would be hard to replicate for something like this. An abstraction to those cloud native service, OTOH, may be useful against lock in. I believe it should be possible given that most of the cloud native services across different clouds provide similar set of features.
EngineerBetter 10y ago
You should take a look at BOSH. http://bosh.io http://bosh.io It allows the same distributed system to be defined and run on AWS, GCP, Azure, vSphere, OpenStack, tin, and more.
danielsiders 10y ago
Thanks! Flynn is designed to be cloud-independent so you're not locked in to any cloud, or even cloud in general. You can also run Flynn on your own servers. Flynn also allows portability between clouds. Since we don't use any cloud-specific features (like, say RDS) you can backup a Flynn cluster (including database appliances) from one cloud and deploy onto a new cluster on an entirely different cloud.

deleted 10y ago

[deleted]

corobo 10y ago

I've been using Flynn for a while now. Unfortunately there's always something that entirely bricks the cluster eventually. Sometimes a node will reboot unexpectedly (as happens with servers) and the cluster slowly implodes from there, sometimes I'll just get a monitoring alert that all the sites hosted on it have gone down for no apparent reason. They announced during their 1.0 release that Flynn is now production ready but I have to disagree at this time. I do honestly love the idea of running my own Heroku but it's just not stable enough and doesn't recover well if a node goes offline without manual intervention using the flynn-host fix command (and sometimes that command just chokes up completely). Next time it happens (when, not if, at this rate) I'll try to set aside some time to gather up the logs to help debug the problem but I'm using Flynn to avoid the sysadmin side of things and just build my product. In my opinion Flynn is tinker-ready, not production-ready. It's infuriating that it has these random problems because like I say I really _really_ love the product and desperately want to be able to use it reliably.

merb 10y ago
> Sometimes a node will reboot unexpectedly (as happens with servers) if it's coreos it's probably the auto update mechanism.
- corobo 10y ago
  Not in this case, Flynn runs on Ubuntu 14.04. I think the reboot was a DigitalOcean droplet's host being restarted at the time though I can't be sure.
- nathancahill 10y ago
  Unbelievable that auto update is the default. Got bit by that.
_lmars 10y ago
Really sorry to hear you have had issues with your Flynn cluster. Stability is our number one concern and we are pushing stability fixes all the time. Flynn does self-heal after node reboots, so if that is not working for you then it is a bug we need to fix. When you do have issues it would be really helpful to us and other users if you could open a GitHub issue or come and chat to us in IRC (#flynn on Freenode) so we can fix any bugs you are encountering. I fully understand you just want to be concentrating on building your product, this is why we are building Flynn!

ngrilly 10y ago

Is it possible to store file in some kind of NFS volume? Is it possible to store objects in something similar to S3 (for example using Minio)?

_lmars 10y ago
> Is it possible to store file in some kind of NFS volume? NFS support is not currently implemented, but we have a clear plan and it is on our upcoming roadmap: https://github.com/flynn/flynn/issues/1521 https://github.com/flynn/flynn/issues/1521 > Is it possible to store objects in something similar to S3 (for example using Minio)? Flynn has a built-in blobstore for storing files and supports multiple storage backends: PostgreSQL Large Objects (default), Amazon S3, Google Cloud Storage and Azure Storage (to be released into stable next week), see https://flynn.io/docs/production#blobstore-backend https://flynn.io/docs/production#blobstore-backend.
- ngrilly 10y ago
  The documentation about the blobstore says PostgreSQL should be used only for small deployments. What if you deploy Flynn to DigitalOcean, which has no S3-equivalent?
  - Titanous 10y ago
    You can use S3, Google Cloud Storage, or Azure Storage even if you're running on DigitalOcean.
    - ngrilly 10y ago
      Yes, but at the cost of increased latency, and paying the bandwidth?
      - DeadBabyOrgasm 10y ago
        There's also expandable block storage (https://www.digitalocean.com/products/storage/ https://www.digitalocean.com/products/storage/), though I'm not sure if it fits these circumstances.

Mojah 10y ago

Happy to see Flynn get more adoption, it got featured in the cron.weekly newsletter a few months back, when it was in the earlier stages; https://www.cronweekly.com/issue-39/ https://www.cronweekly.com/issue-39/

spamlord 10y ago

How does this compare to Cloud Foundry?

EngineerBetter 10y ago
Good question - I dare say it is nowhere near as battle-tested in production.
- EngineerBetter 10y ago
  Caveat: I run a Cloud Foundry consultancy. A quick glance shows a couple of things: * Automatic cluster scaling, so your PaaS deployment is as small as possible. Cloud Foundry doesn't have this, and I wish it did * Flynn has built-in service discovery, in Cloud Foundry you bring your own (if you want) * Flynn comes bundled with some data services * Flynn has no BOSH equivalent, so there's nothing there to bring back VMs when they fail, perform rolling upgrades or manage the IaaS * Flynn doesn't seem to offer a metrics stream, only logs * Flynn builds apps from source, so not sure how that works for compiled Java/Go, or anything you'd run with a binary buildpack * I couldn't find anything about role-based access control in Flynn, something Cloud Foundry has (which can be backed by LDAP for enterprises) * Flynn only appears to route HTTP traffic, so no TCP routing for IoT workloads * Cloud Foundry is run at massive scale in production for mission-critical workloads by banks, payment processors, IoT data ingesters, manufacturing companies, research companies, governments and everything inbetween. I can't see any evidence of the same being said for Flynn. * Flynn is owned by one company, Cloud Foundry is owned by a non-profit organisation affiliated with the Linux Foundation and can never be transferred back to a regular company. This prevents the sort of nonsense you've seen in the Docker community recently.
  - _lmars 10y ago
    > Flynn has no BOSH equivalent, so there's nothing there to bring back VMs when they fail, perform rolling upgrades or manage the IaaS Flynn auto-heals after node restarts (and if it doesn't that is first and foremost a bug we need to fix), but also has a cluster monitor service which brings services back online automatically, and as a last gasp there is `flynn-host fix` for manual intervention. Flynn has node promotion / demotion so you can totally do rolling upgrades (users have reported they do this with a modified CloudFormation stack for example). There is also a built-in updater to update to a more recent version of Flynn. > Flynn doesn't seem to offer a metrics stream, only logs Something I think should be built-in, but there are many off the shelf solutions which can be deployed to Flynn as apps. > Flynn builds apps from source, so not sure how that works for compiled Java/Go, or anything you'd run with a binary buildpack Flynn has built-in buildpacks but also supports running custom buildpacks (see https://flynn.io/docs/apps#buildpacks https://flynn.io/docs/apps#buildpacks). If you just want to deploy binaries, you can either: - use the inline buildpack: https://github.com/kr/heroku-buildpack-inline https://github.com/kr/heroku-buildpack-inline - deploy a tarball: https://github.com/flynn/flynn/issues/306#issuecomment-233211243 https://github.com/flynn/flynn/issues/306#issuecomment-23321... - deploy a Docker image: https://flynn.io/docs/docker https://flynn.io/docs/docker > I couldn't find anything about role-based access control in Flynn, something Cloud Foundry has (which can be backed by LDAP for enterprises) Flynn does not currently have strict access control, but work is very much on the way, see our security improvements project: https://github.com/flynn/flynn/projects/1 https://github.com/flynn/flynn/projects/1. > Flynn only appears to route HTTP traffic, so no TCP routing for IoT workloads Flynn supports TCP routes, although it does not seem to be documented very well: https://flynn.io/docs/cli#route https://flynn.io/docs/cli#route

sztwiorok 10y ago

what gives you more than docker-compose itself? with docker-compose and docker swarm I can easily add services there, configure the application environment and scale it. seems interesting but please enumerate things I can do that are not delivered by docker compose and docker swarm.

_lmars 10y ago
A main advantage of Flynn over using docker-compose is that Flynn is more aware of how to run applications out-of-the-box, rather than just running containers which the user has to fully configure. For example, Flynn comes with PostgreSQL, MariaDB and MongoDB appliances which are deployed in a highly available, fault tolerant configuration with sane defaults: https://flynn.io/docs/databases https://flynn.io/docs/databases. Through the use of buildpacks, it is also straight forward to deploy applications written in many popular languages and frameworks without being intimately acquainted with how to containerise those types of applications (e.g deploying a Ruby on Rails app on JRuby: https://flynn.io/docs/languages/ruby https://flynn.io/docs/languages/ruby). You also get things like full cluster backups (including all your data), simple git / docker / tarball based deployments, log aggregation, release rollbacks, domain / path based routing, service discovery, and many more!
EngineerBetter 10y ago
Both this and other PaaSes remove a lot of the plumbing. Also, the target audience is different. PaaSes offer self-servixe for end users: for instance starting a new database on demand through the user interface. You can achieve much of this with Docker Compose, but your users can't. The Docker-PaaS movement reminds me of content-management systems in the early 2000s. Everyone (myself included) thought it'd be great to spend loads of engineering effort reinventing the wheel, instead of delivering business value.

Kiro 10y ago

Completely OT but was this posted because of the "Remediation Plan for WoSign and StartCom" thread from yesterday?

cheiVia0 10y ago
No, because of https://news.ycombinator.com/item?id=12703121 https://news.ycombinator.com/item?id=12703121

weitzj 10y ago

Does anybody have experience with Cisco Mantl (Mantl.io) ? It looks like CloudFoundry or Flynn, but I never saw it mentioned on HN.

mongrelion 10y ago
I worked on Mantl for a while last year. To understand the difference you can see Mantl just as an opinionated coalition of tools for running microservices. So, Mantl is not a thing but a collection of things (Mesos, Marathon, Consul, ELK stack, etc) put together using Ansible playbooks. Flynn is an actual product which, from what I can see, is also a collection of tools but these are written by the Flynn team themselves. I'm happy to answer any other question you might have about it.
- smartbit 10y ago
  Thank, makes sense. Feels like Mantl can go with the flow, add products when they become trendy. And from the perspective of the developer, does Mantl offer a similar PaaS experience as Heroku or Flynn?
sargun 10y ago
If you're interested in Mantl, I'd look at Mesosphere's DC/OS. It's very similar. Disclaimer: Work for Mesosphere
- smartbit 10y ago
  Does DC/OS out-of-the-box support 'git push' for deployment? See https://flynn.io/docs/basics#deploy https://flynn.io/docs/basics#deploy
stonith 10y ago
I worked on it for a few weeks while contracting at Cisco. At the time it was a set of tools for deploying a Mesos + Marathon cluster, and K8s was being looked at as a sub-in replacement for Marathon. I think that's now been done + much more. There wasn't any particular magic in it, more that it was a neat package of terraform+ansible tooling for getting mesos and the surrounding ecosystem going. This was about a year ago, so things may have changed since then. I do like the idea of not inventing your own paas, but rather having a consistent framework for deploying whatever kind of paas you need on whatever cloud is available.

duncanawoods 10y ago

Question for the Flynn team: For us to invest time/effort adopting a PAAS solution requires an amazing amount of trust in your ability to execute now and in years down the line. Unlike alternatives, you are a company and not an industry collaboration / foundation, how open can you be to make us believe you are not the next RethinkDb-like shutdown? e.g. How many in your team, why can they do this, how much funding do you have, what is your burn, when do you become default-alive?

arekkas 10y ago
that's the whole point, you don't need a lot of time to adopt flynn. it's not that "getting BOSH to work was my life for the last 3 weeks" kind of experience.
- dahdum 10y ago
  Not the whole point, for all we know Flynn could be out of business in 6 months and they'll be stuck on a platform with no future and saddled with switching costs. Not saying it's likely, but it's a risk worth considering.
  - arekkas 10y ago
    i should have said: that's the whole point for using a buildpack/docker paas in the first place. a) it's not hard to set up flynn b) migrating to another buildpack system is not a lot of work, except setting up some environment variables and installing a cli
MattRogish 10y ago
Disclaimer: I founded a DevOps (now Kubernetes) consulting company. We, up until recently, had our own (closed source) ansible/terraform/packer immutable AWS-based PaaS sort of thing. We abandoned it in July when Kubernetes hit 1.0. It's not just if Flynn and Convox and other VC-powered startups whomever can even exist another couple of years - but whether they exist and if they can out-compete Docker and CoreOS and Kubernetes and... etc. My feeling is that a lot of infrastructure companies died in July. Just like Blackberry after the iPhone - gradually, and sometime in the future, suddenly. What's the future for these PaaS companies? I dunno. Consulting services? Managed PaaS? These are fine, but... have a finite growth curve. Not everyone wants or needs to be a unicorn - for sure - but if you're tying your SaaS or web business to someone's infrastructure code, you kinda want: a) the thing everyone else is doing (so you can grow your own team eventually - it's easier to hire a kube developer than a eg. flynn dev) b) something that will be around for a long time and c) something that has the best blend of features/power/ergonomics (Kubernetes has almost 1,000 contributors. Flynn: 98. Convox: 52. Bigger isn't always better, but...) For us, that's kube. We're still iterating on our our business model - perhaps we just stay as a kube consulting shop for a good while - but running an Open Source PaaS business is not where we think the puck is heading.

rcarmo 10y ago

I love this kind of thing so much that I built my own: https://github.com/rcarmo/piku https://github.com/rcarmo/piku (Originally coded to deploy services on the Raspberry Pi, but now used on "real" machines too)

erowtom 10y ago

Experienced Flynn last year, we spent about 2 weeks making it work properly with our solution (We had a complex SaaS solution hosted on Heroku, with tons of addons). We had some very bad bug that happened at the time (like deploying a new version made the dyno crash and we had to deploy a completly new environment). Other than pretty bad bug, it was working properly, and did what they sell. Good point is that the dev team is very responsive and we reported a bunch of bug that got fixed in no time. They also have a smooth updater when a new Flynn release came out, side bad note is at this time, it was kinda bugged (because of our specific setup). For all those reasons, we choose to stick with Heroku at that time (we also tried Doku https://github.com/dokku/dokku https://github.com/dokku/dokku, various AWS services such as BeanStalk, and DEIS http://deis.io/ http://deis.io/), but for sure it was the best candidate out there and I would love to give it a try again.

_lmars 10y ago
We have pushed a ton of stability fixes recently, and we now have a stable release channel which we release to monthly (see https://flynn.io/docs/stability https://flynn.io/docs/stability). I highly suspect many of the bugs you encountered have been fixed, and we make it a priority to investigate and fix reported bugs as quickly as possible, so if you end up giving Flynn a try again let us know if you have issues and we'll fix them. As for updating, the in-place updater still has some kinks but the backup / restore route is fully tested and is reliable (see https://flynn.io/docs/production#updating https://flynn.io/docs/production#updating).

stanislavb 10y ago

Note: Flynn seems to be the most popular package on "Awesome SysAdmin" under the category "Cloud Computing" https://sysadmin.libhunt.com/categories/1727-cloud-computing https://sysadmin.libhunt.com/categories/1727-cloud-computing

softwarelimits 10y ago

no autoscaling.

stemuk 10y ago

Looks pretty cool, do you have any plans to add RethinkDB support?

Titanous 10y ago
No current plans, but feel free to request it in a GitHub issue. We consider the number of votes on GitHub when adding to the roadmap.

exratione 10y ago

I've worked with a group using Flynn to host a score of internal apps. It required one full time developer to keep it running, and saved a bunch of time and effort for the people maintaining those apps - no need for devops, pretty much, as deployment boils down to a ten line bash script. So if that tradeoff works for you, you should consider using Flynn. In this age of it being next to impossible to hire devops folk, the idea that you can have one of them servicing the devops requirements for a sizable fraction of developed applications is somewhat attractive. I wouldn't put Flynn in place for external-facing and high-traffic applications at the present time based on the experience I've had with it, however. Not ready for that, I think. You have to have a fair tolerance for short outages.

omouse 10y ago

How does this compare to OpenShift?

epynonymous 10y ago

having worked on cloud foundry platform in the past, paas was extremely exciting at the time (2012), we even came up with something called warden which was way before docker. but since then, i have to ask, is there really that much benefit to having a paas? i understand the arguments about not needing to have devops/sre's, etc, but i think iaas works just fine, sure there's the initial plumbing for things like load balancers, installing an operating system, upgrading/patching that operating system, securing all the network connections, but it's not an everyday task. cloud foundry at the time required a minimum of 20 vm's to get the environment running (cloud controller, bosh, service nodes, dea's, nats, etc), and these weren't your t1 micro aws machines, these were memory and processor hungry instances; to manage the entire environment required a team of sre's and devops. nice to see that flynn only requires 3 nodes minimally, but as the environment scales, you'll need more nodes and i wonder how the overhead scales with flynn. obviously for small environments (let's say 6 vm's, an additional 3 vm's to support flynn is not ideal). but if you get up into the 20+ vm arena, perhaps the overhead starts to pale in comparison? perhaps it's just me, but the devops part isn't that annoying, yet, but i've got an ultra small environment running nginx, golang binaries, and some services like rdb and k-v store.

epynonymous 10y ago
not sure why this was down voted, but whatever, my questions remain and if anyone is willing to answer, i'd appreciate that.
- duncanawoods 10y ago
  Looks like a decent question, I upvoted. I think the main motivation compared to IAAS is to run on your own choice of machine e.g. on-premise or dedicated from OVH/Hetzner, or across different cloud providers while not incurring the full admin overhead of baremetal. The reasons can be portability, control, performance, privacy or the potential for 1-2 orders of magnitude cost-savings. And yes, scale, high availability, self-healing, auto-scaling & load balancing is where the admin pain comes in.
  - 10y ago

splitrocket 10y ago

The bit that made the decision for me is managing self healing, highly available postgres in the same infrastructure and tooling as the rest of my deployment. I have yet to see any other PAAS come close to offering HA postgres built in. The second bit was dead simple service discovery.

tomhallett 10y ago

Does anyone have any experience with Rancher? I feel like it would fill a comparable role as Flynn. But I might be off base here.

jondubois 10y ago

I'm working on a similar service, but focused around my own open source stack: https://baasil.io/ https://baasil.io/ The main issue with deployment/orchestration platforms is that they cannot handle ALL different kinds of stacks/apps (each one has unique scalability requirements). With Baasil.io, our strategy is to get it 100% working and auto-scalable; one stack at a time.