I wanted to contribute but I am a single freelance developer, I don't have the amount of money shown on the sponsorship options. I would be great to have a USD 50 option there.
I upvoted this, but want to also add my opinion in writing that I strongly second this opinion. The company I work at is definitely interested and might be able to contribute, but I'm also strongly interested as an individual. I have a lot of projects that would greatly benefit from having a tool like this available -- especially one that's open source -- and I would be more than happy to donate, but the sponsorship options are super high as previously noted.
I think I know a company that would be interested, but I noticed something on the page: "Please consider giving a little extra if you are also requesting additional features." -> Does this mean you get to be a part of deciding features if you donate?
We'll definitely take feature requests from sponsors seriously. The biggest limiting factor is how much time we can afford to spend on development. Anyone who substantially helps out with that gets a bigger voice in prioritizing the order we develop the reach features.
Seriously. When I first went to the website and read the description, I was like, "why isn't this already funded? They're only asking for $75K." Now I know why.
Thanks--We'll definitely accept individual contributions before the fundraising period ends. We wanted to avoid staff at companies contributing individually instead of bringing institutional support. Flynn's long term success will depend on institutional adoption (not contributions), so forging strong relationships in that area now is important.
We're also considering different options e.g. Gittip vs traditional kickstarter-esque funding options with stickers and t-shirts. Currently there are 13 days on the clock, we'll post again when we're nearing deadline.
We'd be excited to hear any suggestions you have on how to balance individual and organization contributions and participation before then.
I don't think the point is to "profit" as much as it is to fund the project. Notice these aren't "customers" but sponsors. Maybe the mindset of "money is being left on the table" isn't quiet the right one for this sort of project ...
If open source projects had always required $50,000+ to get started, we might not have GNU/Linux today.
Why can't you start the project first and then ask for donations later? Are you saying that unless you guys get paid you're not going to work on the project?
You will not nearly get as much money if you ask for donations later. Certainly not enough to pay for your cost of living. People have the tendency of thinking
"hey I can get this for free, and I can get this TODAY. hm those developers are cool. maybe I'll donate some day"
Then they download and use the thing. 97% forget about donating and never return. Of the remaining people, they donate maybe $100 or something.
FooBarWidget (who you replied to) is actually Phusion, the maker of Passenger (the very popular Rails app server). I think they have some very strong anecdotal evidence.
Up until recently Passenger was completely free, with donation options. Now they have an Enterprise offering - which we are happily paying for. I suspect the Enterprise licenses are orders of magnitude more than the donations ever were.
This is great guys, good to see more people bringing PaaS-like workflow without the baggage. We've been working in this space with Juju (http://juju.ubuntu.com) but we're using standard LXC for containers.
Using LXC allows us to support applications that run on multiple processes, and since Juju is also written in Go, It seems like it might be possible for us to work together in some interesting ways.
We already have charms for Rack, node.js, Django, etc. already working and we can replicate the example in the video, just on raw LXC, EC2, and OpenStack. And we’ve put a lot of time and energy into managing the relationships between services, which is the big complicated part of a PaaS So, there seems to be pretty good overlap.
Have you looked at Juju? Perhaps there are places where you can leverage the heavy lifting that the juju team has already done in creating a “bring your own” kind of PaaS.
Do you mind explaining that? Would the fact that they use AGPL for Juju matter if you're not hacking on Juju itself? I don't see how it would be an issue, it wouldn't extend to the proprietary software you run on a Juju-setup service, would it?
Yea, it's exactly like MongoDB which is also AGPL.
Using the database doesn't impose any restrictions on your software.
Even hacking on juju to add API'S you for your client software doesn't impose restrictions on the client -- it just means you are subject to the AGPL licence source distribution rules on the patched version of Juju.
Mongo is a different beast, because the mongo client has a GPL exception which allows your code, that is linked to the mongo client, to use a different license. This is a friendly exception, that the mongo developers allowed. Without that exception everything using mongo even over the Internet would automatically also be AGPL licensed.
IADNAL, but its a matter of risk. If one uses juju in operations scripts to implement proprietary services, do you have to make those scripts available to end users? At what point does your software become "derivative" of juju? This interpretation definitely borders on FUD, buts its easier not to take the risk when other options are available.
GPL is viral and imposes restriction which you can't foresee. A recent example is the AppStore fiasco VLC had. It required a complete rewrite and additional development years to get it in the store just because the original code was GPL. Please think twice before using (A)GPL and make sure you have checked all consequences.
I agree, we have very much approached the problem from that of service administration/management rather than the "build a PaaS"approach. But, I think the "big problem" behind building a heroku style PaaS, is not getting simple scripted deployment to a container -- it is managing relationships between applications, databases, message queues, and other connected services, and I think that is where Juju could be useful to your project.
I'd also be happy to talk more about this any time.
OK, thanks. This was a deal break for us a year ago. The issue was even partly solved and with a few hacks juju did survive reboots, but it was later on removed.
We at OpDemand wish the Flynn crew the best of luck. I expect more Docker-powered PaaS's to sprout up, so I'm glad Solomon and the dotCloud crew are focused so heavily on interoperability.
OpDemand will be releasing a very similar open-source project called Deis in the next few weeks. It's an open-source PaaS powered by Docker & Chef, with a Heroku-inspired workflow.
We're busy ironing out a few final issues, putting together documentation, quick-start guides, tutorials, etc.. but we are very close to launching our public 0.1.0, which will allow you to deploy your own private PaaS providing you complete control over hosting, backends, proxies and more.
Thanks. We're excited to share our take on private PaaS with the open source community.
Re: Puppet -- A good chunk of the "orchestration" is done by updating data bags on a Chef Server, and force-converging Chef nodes over SSH. However I know Puppet has similar constructs, so it's definitely possible to fork the Deis controller and Puppetize it. We'd encourage that sort of contribution.
My main problem with Docker is that container IP addresses and MACs are changed after every container reboot. This means I can't have a database in one container and a web app in another because I have no way for the web app to discover the address of the database server.
Seems like this would be an issue for the host-only (private) network?
Docker is in very active development and issues like this get resolved every week. That said, it's not a problem because of the service discovery and routing that would be involved in the Flynn system.
Yes, Docker is moving quickly but one barrier to resolving this is philosophical: static IPs and private networks are un-Dockerish. Right now it's not obvious what a clean solution would look like. I'd be keen to see how Flynn's discovery and routing develops, it sounds very promising.
Static IPs and private networks are not particularly un-Dockerish. They are just not the default implemented by Docker :)
Docker 1.0 will include an API which will make it much easier to customize how you want networking to happen. That includes static IPs and private networks.
Note that the 1.0 API will also include hooks for service discovery - specifically to facilitate the development of projects like Flynn.
Are these feature plans documented somewhere? Private networks, in the spirit of EC2 security groups or VPCs, would help simplify many distributed computing scenarios where securing services with passwords isn't an option.
In dynamic clusters like Flynn this could be solved with a naming service. Typically this will be implemented on top of something like Zookeeper or Doozer.
Another option could be to use Go DNS [1] to integrate a DNS server directly into the cluster. This would allow the DNS records to immediately reflect the state of the cluster, using SRV records to map directly to the dynamically allocated hosts + ports. DNS resolver caching would have to be carefully managed though.
I have no idea whether there any plans to implement a naming service on top of Flynn.
Without knowing too much about docker, service discovery over dns-sd and potentially mdns (aka bonjour/zeroconf) generally works quite well in a contained private network. And I would love to see a platform that supports it.
And this is why you shouldn't open source the core part of your business (looking at you DotCloud). Sure, Docker is good for the community. But it's also a key competitive advantage for DotCloud. By giving away that advantage, they create opportunities for viable competitors.
Hi, I'm the founder of dotCloud and author of Docker. Projects like Flynn are the reason we opened Docker in the first place. They are a good thing for the docker ecosystem, and they are definitely good for dotCloud.
The dirty little secret of PaaS is that there is not, and will never be a single PaaS that fits everyone's needs. With docker we offer a foundation for many PaaSes to engage in a healthy competition while preserving interoperability.
So Shopify will always be free to mix and match Flynn's lego bricks with the bricks of other offerings - because they are all Docker-compatible. The authors of Flynn get that, which is why I believe their product will be good and I will be personally sponsoring it :)
I got a very good vibe from you guys after watching the pycon 2013 presentation and have tracked docker development since then. Considering your comment, I have to say that not only will I support dotcloud etc., but I will also look to give back in whatever way I can to boost the ecosystem.
So what is the strategic business advantage? Is it that Docker (presumably, your core piece of infrastructure) improves as a product as more PaaS's adopt it? So essentially your competition will improve your own infrastructure.
Not from dotCloud but I've noticed that there is a focus for a central index. It might be possible for them to get revenue from an app-store. There is also the usual consulting that can be derived from expertise.
Are you not concerned that once Flynn gets good enough, lots of companies will take a little time to get Flynn set up on VPSes or dedicated servers, rather than pay the high premium for dotCloud?
Flynn is particularly appealing to companies that need to completely control their own infrastructure. In the same sense that git being open source helps, not hurts github, I think there's limited crossover between the users of Flynn and DotCloud customers.
Who in their right mind would pay $0.288 per hour (a little over $200 per month) to dotCloud for roughly the equivalent of an EC2 small instance, when with just a little extra time spent up front, they'll be able to fire up an AMI of Flynn and pay less than a quarter as much per month?
> Who in their right mind would pay $0.288 per hour (a little over $200 per month) to dotCloud for roughly the equivalent of an EC2 small instance, when with just a little extra time spent up front, they'll be able to fire up an AMI of Flynn and pay less than a quarter as much per month?
People who value a little extra effort at startup as being a cost that is more than $200/month over the life of their use of dotCloud.
There's a lot of cases where that could be true, especially if the extra effort and moving to a different platform is deferred, rather than permanent. There are many times where doing something now (that isn't necessary for immediate goals, but is useful for long-term savings) has greater opportunity costs than doing it later. (Lots of times when the reverse is true, as well.)
Yep. You are truly underestimating how lazy I (and others) can be. And besides, being able to have support to turn to is quite a bonus: I don't want to be the support guy for this sort of stuff.
Who in their right mind would pay for a dedicated server monthly when with just a little extra time spent up front, they'll be able to buy an inhouse server and pay less than a quarter as much in the long run?
Not quite. Buying server hardware requires a substantial up-front monetary commitment. Once we have a good self-hosted PaaS package like Flynn, setting up an instance on an IaaS provider should (in theory) require a very small amount of time.
It seems to be working well for people paying for EC2 instances when they could be racking the hardware themselves. Having APIs, support, and a dedicated team handling the infrastructure is worth paying for to plenty of people.
Not sure I completely agree with this. I don't know what your internal discussions were, but at least one of your competitors has an 'enterprise' option in which they give you your own version of the toolkit. Sadly among this was that they stopped with their open-source contributions to the Cloud Foundry community (Their last update appears to have been over two years ago https://github.com/cloudfoundry/vcap/pull/105).
I'm not complaining that an alternative to Cloud Foundry is going to exist, but I'm still a bit surprised.
Indeed and Cloud Foundry has 'enterprise' forks as well (Stackato: http://www.activestate.com/stackato/compare-with-cloud-found...). Essentially I think there's a huge market here and all I see for DotCloud from this announcement is at least some potential scavenging of their core users.
Because it's better to have a small slice of a market that you can compete on than nothing on a market that is dominated by other players.
This supposed competitive advantage that they would have would mean nothing if they still had to work on top of other IaaS-providers. They would be undercut by the IaaS themselves. By changing the game, they get another angle to work from.
Indeed. I'm a bit curious as to why DotCloud released Docker? I mean, sure, someone was going to have an easy-to-use container system sooner or later, but for now that is one of the few defining features that DotCloud has going for them... although one of their competitors is successfully using a modified version of Cloud Foundry (AppFog).
We're been working with the DotCloud folks on the container problem since long before Docker was public. They've been very supportive of our efforts to build a full featured PaaS based on Docker and knew about it long before they released Docker publicly. They have their own strategy for their company and product, releasing Docker was a very intentional part of that.
Very cool! Been looking for something like this since Docker was announced. Basically Cloud Foundry is far too complex for what I/we need but this would fit the bill nicely.
One question though, what is going to be 'the cluster' (The site says it distributes work across 'the cluster')? Basically, will it be capable of interfacing with cloud API's or will it just be you manually setting up a group of instances to host the machines to run Docker on top of?
The 'cluster' is a group of nodes running the Docker + Flynn software. It can be anything from a single server to a fleet of EC2 instances to a rack of servers. It would be easy to make a tool that spawns instances running Flynn on your choice of public/private cloud.
So integrating with VPS providers such as Linode and Digital Ocean will be possible? If so, would this be easy to do for end-users?
Never got in to Cloud Foundry because it's overly complex and very limiting. Always went with Heroku, but wished I could have a Heroku-style infrastructure on the above mentioned VPS providers for the benefits of running better hardware, being more affordable, being multi-region, etc, etc.
Docker runs on linode and digital ocean (https://github.com/dotcloud/docker/issues/469, https://github.com/dotcloud/docker/issues/424) by loading a custom kernel. Assuming the requirements for Flynn aren't much more than Docker, the whole stack should run there as well. Easy for end-users is probably a matter of opinion, especially until Flynn releases some code.
Don't see Linode listed there, but between that or Jclouds (http://jclouds.incubator.apache.org/documentation/reference/...) you have like a billion cloud API's available to you. I imagine teaming one/both would make Flynn a very interesting alternative to Cloud Foundry/etc.
Yes, there's no reason this can't run on VPS providers. Some have APIs for provisioning, so hooking them up for automated deployment is not complex either.
Okay, thanks for clarifying. The next question then would be, if you do reach your stretch goals and implement auto-scaling, would you at that point have cloud/MaaS API integration?
"Unlike existing open source PaaS products, Flynn focuses on providing a set of modular components that can be replaced and reused."
I wonder if there is anyone here who works on CloudFoundry or OpenShift and could comment on this, or comment on the proposed capabilities of Flynn (https://github.com/flynn/flynn-spec) compared to the capabilities of their systems.
They actually don't use LXC though and implement resource control with Cgroups. That said, Cloud Foundry is extremely difficult to get setup and running in my experience (even with the v2.0 recently released). It sounds like one big differentiating factor is that Flynn would have fewer moving pieces (Cloud Foundry is at least: BOSH, Warden, VCAP?, CF itself, etc.).
+1 on the fact CF installation is tough! They recently releases a suite of scripts to help installing it on AWS. Forget about installing it manually on Open Stack (talking from experience). I can only hope Flynn gets the easy install right, so people will be able to try it out.
CF is actually very plugable as well - there is a well defined internal API, which you could just add components that listens/publishes to - however, I don't think its encouraged, neither have I seen a single example of it.
Yeah, CF is a very powerful toolkit (as you mention with the API), but part of the power seems to come coupled with the complexity. I've seen some scripts/documentation to install on Openstack (this is the best so far http://www.pistoncloud.com/2013/06/deploying-bosh-cloud-foun...), but still, it's a huge, huge pain.
I'm a user of OpenShift, and to be honest, it sounds like they are doing exactly what Flynn wants to do (but without Docker). They have cartridges, both official and community made, but they can also be bypassed and customized, as far as I can tell.
Dokku is sort of a proto-Flynn. It has different, more reachable goals because it's intended for a single host. It solves some of the same problems, just in a non-distributed way. Breaking Dokku down into its components starts providing part of the plan for Flynn.
They may even share code in the end, but Dokku will remain focused on simple, single host deployments. Flynn is about a real, distributed system that could be used in production.
Since Flynn is really just a packaged collection of components (similar to Dokku), Dokku may just end up being a single host version of Flynn someday.
Heroku has been able to charge a premium for ease of use. It's hard to imagine, though, that ease of use will be a competitive advantage much longer. Much of their creativity (and it's substantial) has been in showing the way and it's only a matter of time, it seems to me, before that will be imitated (in a flattering way) by open source projects.
Ultimately, it seems, heroku will need to find an additional axis (besides ease of use) to differentiate on. Maybe I'm wrong, though. Apple sure has been able to turn ease of use into a sustainable competitive advantage. In heroku's case, though, there are fewer UI decisions and its audience is super-technical, so I'd be surprised if ease of use alone is sustainable in this domain.
We'll see. I want to see them win, to be honest, because I feel like they've done so much good in a providing such an accessible and (at first at least) cheap way for a developer to get his or her stuff out there.
Yeah. And by the way, I love Heroku, if it's not obvious. I'm friends with their engineers and visit their offices occasionally. It's been one of the most inspiring platforms I've seen.
Think of a Platform-as-a-service like a web server that is already configured for multiple languages and all you have to do is install your web application and start/restart it.
The idea is that you can turn on and off web servers really quickly to do tests and also that it should scale as the amount of work that your web application needs scales.
Thanks for your interest. Of course we're happy to accept small contributions from companies. I just sent you an email with details. for anyone else who's interested in contributing on behalf of an organization, please email: contact@flynn.io and we'll set you up at whatever amount you feel comfortable with.
We'll start accepting personal contributions next week as well.
I like the fact that Flynn will be written primarily in Go. That should mean very little overhead for this PaaS.
I wonder if using Heroku buildpacks is a good idea, though. Something that can more fully take advantage of Docker layers, and in some cases APT packages for language runtimes, would be better IMO.
They are not mutually exclusive. An ideal system would honor the Dockerfile when it is present, and attempt to auto-detect the build method when it is not. Buildpacks are great defaults when auto-detecting.
That way, you get a nice out-of-box experience (push your code, something magic happens), and when you need more control over your build and dependencies, you can add a Dockerfile.
I got interested in building something like this when I saw Docker issue 410[1]. If my understanding is correct Mesos uses Zookeeper to keep a Mesos master available. Zab, Zookeeper's distributed consensus algorithm, is similar to Raft which has a popular Go implementation[2] written by Ben Johnson. Perhaps Flynn agents can use this implementation.
I was trying to built something similar, already had a proof of concept ready built on top of components from Dokku. I can't wait to follow this project - I might even pull myself together and learn go!
Puppet-lint ;). But seriously, cool to see a puppet module for dokku as I imagine the author will continue to work on it even with this new project. I'd say keep working on it if you have time!
I'd love to know more about how the cluster will organized. Is there going to be some kind of master controller node, or will it be distributed and self organizing somehow?
It almost feels as tho Flynn (or maybe something build on top of Flynn) could/should be a whole minimal linux distribution (SmartOS-ish) that could just boot up into RAM, be told to read a cluster config from somewhere and then start working for the cluster accepting Docker services.
I'm curious what type of deployment APIs people want. It is the docker rest API + git push for your own code? Should we be using heroku APIs? Are we going to invent something new like OpenStack did?
I feel like we are early enough into all of this that we might have a chance at standardization... vs the IaaS APIs which have all diverged at this point.
That's a good option. Thank you for your insight there.
I can't help but think that this won't really work for many Microsoft shops because the Microsoft CLI is very different from the Mono CLI.
The reason I ask is that there's a number of providers of private PaaS solutions that are willing to install their stuff in your organization for Microsoft stack(HP Matrix, I'm looking at you), but they are full of holes and aren't nearly as robust as what Docker/Dokku/Flynn can offer in terms of plugability and modularity.
Thanks! We're experimenting with a new funding model for open source: publish a spec for a project that's useful to (and can save lots of money for) companies and see who will chip in. We don't think there are enough personal donors for a project like this to raise significant cash (and the sponsorship levels are affordable for most companies) so we want to try sponsorship first. Once that market is saturated, we'll experiment with individual donation options, maybe after the MVP ships
It's still in the early stages of development. We're currently fundraising so that we can work on it full time. All code will be pushed to GitHub as we write it.
I don't see this in the FAQ: the magic that makes all of this happen (which you're integrating) is technology built by other developers. Why should we be supporting you to do this work rather than the other developers who broke ground and already did a majority of the heavy lifting?
Docker was a big piece of the puzzle. I worked with DotCloud to make Docker happen and we're involved in that community quite heavily. There's still a lot more work to do, otherwise we would not be bothering with a campaign like this.
Not to discount your work, but the way I see it: the kernel (e.g. cgroups, namespaces) and the corresponding lxc work dwarfs anything docker brought to the table. This project smells like a campaign to get a product funded.
Considering LXC support will soon be a module to Docker and not core, I'm not sure you understand what value Docker adds. Just as there is value added all the way up the stack.
Regarding the product funding remark, that's not the intention, though with the license anybody could build a product with this project. I'm not convinced that's a bad thing.
@titanous Jonathan Rudenberg Are you the only developer on this project currently? Sorry, just found your FAQ is at the bottom of the page and the question I had was on the bottom right corner ;)
Just in case someone is too lazy to look it up himself: He's not alone and teamed up with Jeff Lindsay.
