3 ms·

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 ye

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.
danielsiders 10y ago
Thanks for the great question. I'm the CEO & co-founder of Flynn. tldr: we're open to making Flynn a foundation/community project if we could find the right kinds of partners and once the core innovation is complete. This is something we've thought a lot about over the past few years. Everyone on our team is a hardcore open source believer and contributor and the long term success and sustainability of open source projects and Flynn in particular are something we care deeply about. When we started working on Flynn (with just a crowdfunding page posted to HN) we had no intentions of commercializing it. Before asking HN to fund the project we reached out the founders of many growing startups (many of which are now unicorns) who we saw as the core users. Our goal was to agree on an architecture and set of APIs, then have each company "own" one component of Flynn, with one engineer at each working on their component full time. Everyone we talked to said they loved the idea of an open source Heroku that could run anything (not just 12 factor apps) and run anywhere from AWS to their own colos and datacenters, but none had the staff to spare on infrastructure engineering (which is why everyone wanted a PaaS in the first place). Several, like Shopify, contributed to Flynn financially so we could hire a dedicated team to build Flynn for everyone. So a community/industry collaboration was absolutely our goal from the start, but several things made us question that route. Not only were our first choices for collaborators and partners unable to participate directly, but we spent a lot of time talking to companies in the then-thriving OpenStack community as well as other foundation/industry run infrastructure projects. They shared a number of horror stories of how the most promising new features and capabilities were killed by cross-vendor compatibility concerns and how specs were limited by legacy vendors on committees. Committees and bureaucracies are great at keeping something alive and maintaining the status quo, but not at innovation. We also met executives from very large companies in regulated sectors like banking and telecommunications. They were extremely excited about Flynn but had a completely different set of requirements than the younger companies like startups whose needs we knew best, and had experienced ourselves. It was clear that we would have to build a very different project to serve the largest of enterprise customers. Crucially, foundations/industry collaborations on infrastructure attract the largest of vendors who have these mega-companies in their sights as the real customers. If you want to see what a PaaS built to their (imagined) needs are, look at CloudFoundry built by Pivotal, which is currently owned in part by Dell/EMC, VMWare, GE, Microsoft, Ford or at OpenShift, which was built as a startup but acquired and retooled by RedHat. While we think Flynn has a lot to offer today and in the future to these large institutional users, they have not been our focus. Flynn today has the minimum feature set we consider necessary to be useful. Looking towards the future we want it to encompass a lot more. We'll be publishing a comprehensive roadmap/master plan soon, but most of that innovation would be harder or impossible to accomplish if we were locked into a foundation today. Development would be slower, changes would have to work their way through approval to consensus, and many partners would object to new features competing with their own established products. We've been very careful both to limit external dependencies and to provide end-to-end integration between all our components. As a result we're able to move very quickly when changing APIs, implementation details, even major pieces of architecture, all without impacting customers. This gives us the freedom to stay nimble in a changing landscape, but partners might be more attached to technologies in which they already had a large institutional investment. Infrastructure companies today are already a world apart from where things were in 2008 when Heroku upended PaaS. The default is now open source, making lock-in (historically the bigger concern) far rarer. There are few companies among our peers battling to become the next Oracle. Additionally there's a tremendous amount of portability both among unified PaaS's and build-your-own infrastructure because of technologies like buildpacks and containers. As a result most apps that run well on one platform can be moved to another. There are of course features, like Flynn's database appliances, that are not available on most others. We've made other choices like a small codebase with few external dependencies that make managing Flynn's development and maintenance easier, whether it's our team or yours doing that maintenance. That being said, we're entirely committed to Flynn's future personally. While we'd love to see it become a huge company, that's not necessary for us personally. We're a team of five, and speaking for at least my cofounder any myself, we're not going anywhere, regardless of the VC market. We work on Flynn (for several years and many long hours now) because we believe it needs to exist in the world, not because we think it'll make us rich. We're committed to keeping Flynn alive as long as that stays true (basically until it becomes unnecessary or there's something else that does everything we want but better). Since our 1.0 launch we've had huge growth and adoption and are currently fundraising. We're single digit new customers away from default alive with the current team. Whether we become a small, sustainable company to selling to/partnering with a large enterprise vendor, to creating a foundation, everyone on the team is 100% committed to a permanent, sustainable future for the product, with or without venture capital, unicorns, or IPOs.

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.

danielsiders 10y ago

Thanks for the great question. I'm the CEO & co-founder of Flynn. tldr: we're open to making Flynn a foundation/community project if we could find the right kinds of partners and once the core innovation is complete. This is something we've thought a lot about over the past few years. Everyone on our team is a hardcore open source believer and contributor and the long term success and sustainability of open source projects and Flynn in particular are something we care deeply about. When we started working on Flynn (with just a crowdfunding page posted to HN) we had no intentions of commercializing it. Before asking HN to fund the project we reached out the founders of many growing startups (many of which are now unicorns) who we saw as the core users. Our goal was to agree on an architecture and set of APIs, then have each company "own" one component of Flynn, with one engineer at each working on their component full time. Everyone we talked to said they loved the idea of an open source Heroku that could run anything (not just 12 factor apps) and run anywhere from AWS to their own colos and datacenters, but none had the staff to spare on infrastructure engineering (which is why everyone wanted a PaaS in the first place). Several, like Shopify, contributed to Flynn financially so we could hire a dedicated team to build Flynn for everyone. So a community/industry collaboration was absolutely our goal from the start, but several things made us question that route. Not only were our first choices for collaborators and partners unable to participate directly, but we spent a lot of time talking to companies in the then-thriving OpenStack community as well as other foundation/industry run infrastructure projects. They shared a number of horror stories of how the most promising new features and capabilities were killed by cross-vendor compatibility concerns and how specs were limited by legacy vendors on committees. Committees and bureaucracies are great at keeping something alive and maintaining the status quo, but not at innovation. We also met executives from very large companies in regulated sectors like banking and telecommunications. They were extremely excited about Flynn but had a completely different set of requirements than the younger companies like startups whose needs we knew best, and had experienced ourselves. It was clear that we would have to build a very different project to serve the largest of enterprise customers. Crucially, foundations/industry collaborations on infrastructure attract the largest of vendors who have these mega-companies in their sights as the real customers. If you want to see what a PaaS built to their (imagined) needs are, look at CloudFoundry built by Pivotal, which is currently owned in part by Dell/EMC, VMWare, GE, Microsoft, Ford or at OpenShift, which was built as a startup but acquired and retooled by RedHat. While we think Flynn has a lot to offer today and in the future to these large institutional users, they have not been our focus. Flynn today has the minimum feature set we consider necessary to be useful. Looking towards the future we want it to encompass a lot more. We'll be publishing a comprehensive roadmap/master plan soon, but most of that innovation would be harder or impossible to accomplish if we were locked into a foundation today. Development would be slower, changes would have to work their way through approval to consensus, and many partners would object to new features competing with their own established products. We've been very careful both to limit external dependencies and to provide end-to-end integration between all our components. As a result we're able to move very quickly when changing APIs, implementation details, even major pieces of architecture, all without impacting customers. This gives us the freedom to stay nimble in a changing landscape, but partners might be more attached to technologies in which they already had a large institutional investment. Infrastructure companies today are already a world apart from where things were in 2008 when Heroku upended PaaS. The default is now open source, making lock-in (historically the bigger concern) far rarer. There are few companies among our peers battling to become the next Oracle. Additionally there's a tremendous amount of portability both among unified PaaS's and build-your-own infrastructure because of technologies like buildpacks and containers. As a result most apps that run well on one platform can be moved to another. There are of course features, like Flynn's database appliances, that are not available on most others. We've made other choices like a small codebase with few external dependencies that make managing Flynn's development and maintenance easier, whether it's our team or yours doing that maintenance. That being said, we're entirely committed to Flynn's future personally. While we'd love to see it become a huge company, that's not necessary for us personally. We're a team of five, and speaking for at least my cofounder any myself, we're not going anywhere, regardless of the VC market. We work on Flynn (for several years and many long hours now) because we believe it needs to exist in the world, not because we think it'll make us rich. We're committed to keeping Flynn alive as long as that stays true (basically until it becomes unnecessary or there's something else that does everything we want but better). Since our 1.0 launch we've had huge growth and adoption and are currently fundraising. We're single digit new customers away from default alive with the current team. Whether we become a small, sustainable company to selling to/partnering with a large enterprise vendor, to creating a foundation, everyone on the team is 100% committed to a permanent, sustainable future for the product, with or without venture capital, unicorns, or IPOs.