5 ms·

This looks really cool. I see from your website that you're a YC company. Do you mind if I ask what your business plan is? I feel like I'm always cautious arou

by mdasen 6y ago

This looks really cool. I see from your website that you're a YC company. Do you mind if I ask what your business plan is? I feel like I'm always cautious around stuff like this because it seems to be an area where a lot of people have a tough time of making a business out of it and a lot of tools somewhat get abandoned in the space. Flynn has been discontinued recently. Deis has been gone for a while. Dokku still hasn't moved past single-machine, though it does seem to be seeing more life. Eldarion's Kel is gone. Rancher's Rio looked cool, but it seems to have been abandoned quite quickly with most work seeming to drop off a little over a year after it was created (and zero commits in their repo in almost 5 months). It feels like the open-source PaaS space is littered with attempts that then went away as fast as they came. I think part of the issue is that if one actually makes a good open-source PaaS, there's little pain to solve via value-added services. If one creates something that is hard to understand, then there's lots of consulting/support/etc. money one can grab. I guess I'm just left wondering: will this become another Rio or Kel or Flynn or Deis? If it doesn't, does that mean that some large restrictions will happen like a limit of 10 machines? I really want an open-source PaaS to succeed. I've just seen so many struggle to figure out how to achieve that. This might be sounding more negative than it's meant, but how would you quell my doubts? There's no "pricing" page or something that would tell me what you're expecting people to pay and for what - and without pricing, I don't know how you'll stick around. Again, it looks super cool, but I do worry about open-source PaaS systems.

yebyen 6y ago
Deis Workflow is not abandoned! Just changed names, and teams, (but it's still my grandfather's axe!) https://web.teamhephy.com https://web.teamhephy.com If porter-dev is selling managed hosting platform services, they already have a stronger business model than Deis did (which was, I guess, to get acquired by Microsoft and subsequently never provide any form of managed version of Workflow) I don't know what Deis Labs business model is/was to be honest but it seems to have been a success, :-) there are worse footsteps to follow in
- mdasen 6y ago
  Cool, it's great to know that it isn't abandoned. I'm not sure why you'd say that their business model was a success. They were bought by Microsoft for Azure. I guess I wonder if a PaaS company can survive without getting the profits off renting the machines to people. Amazon, Google, and Microsoft all have PaaS options based around the idea that it comes bundled with the compute, not as a standalone open-source thing for you to use on any platform. I guess the question is whether Porter's business plan is "make enough that a company that owns a cloud wants to buy us". Oracle could probably use a nice PaaS platform and team. Maybe DigitalOcean would like to beef up their PaaS offering by acqui-hiring a team with proven knowledge.
  - yebyen 6y ago
    Well, they built Helm which is reasonably successful and carries on their legacy with a large community following. They proved themselves to be among the top experts in the space and got some of the most solid financial backing you can imagine as a result of their efforts; the remaining Deis / Azure folks moved up the value chain, to build AKS, which is also pretty successful and has a large client base. They built Workflow which was IMHO incredibly popular with those that used it, but, from discussion I had with the folks that moved on leaving Workflow behind, it wasn't "pressure from above," or anything like that; they simply went where the market forces were pulling, and opted to work on what they thought would have the most impact. Team Hephy has never really had the aspirations to be a business, just to preserve the capability to go on using Workflow on newer generations of K8s. We develop and maintain it because we like using it, we don't need it to change in major ways, and so we aren't really concerned about its commercial viability (which Deis certainly was.) So, without the SaaS offering, what is the best outcome for a company that develops Workflow? You build up a base of customers who were all too cheap to use Heroku, and once in a while a breaking change from K8s upstream means they depend on your support, but only if they are conscientious about upgrading... I don't think that means there isn't or wouldn't be any market for Heroku-compatible competitors, not by a longshot. I have no idea if it's a viable market, but I still hear a lot of groaning about how hard it is to use Kubernetes often, and at least twice a year I see someone trying to invent Deis PaaS again. The "Kubernetes On-Ramping" market is still very ripe. How does it go? "I'm convinced the majority of people managing infrastructure just want a PaaS. The only requirement: it has to be built by them." https://twitter.com/kelseyhightower/status/851935087532945409 https://twitter.com/kelseyhightower/status/85193508753294540... I haven't tried this new one out yet, but I definitely will. Have to scope out the "competition" and see what the grass is like on the other side. I hope it is greener there!
sungrokshim 6y ago
Hi, I'm one of the co-founders of Porter. First I wanted to clarify that the OP is not affiliated with Porter - but thank you OP for putting us on HN! This was a pleasant surprise. As for the business plan, the honest answer is that we are still figuring out the specifics. That said, the goal is not to charge indie devs/small teams but charge for features that are geared towards collaboration/useful for larger teams. You raise an excellent point about how a truly good open-source PaaS shouldn't have a lot to charge for support. We completely agree with this, and we don't intend to draw revenue from support (as you flag, this model has a bit of tension with building an easy to use, automated platform). We believe that there are a ton of things that can be done that is useful for teams, and there's solid evidence for this on existing hosted PaaS's like Heroku, Netlify, etc. Review apps, pipelines, RBAC are few examples of these paid features on hosted PaaS's that we also consider to be potential premium features on Porter. As for the comparison with other PaaS's that came before us - Flynn, Dokku, Deis and Tsuru were built prior to the advent of k8s. Afaik, a lot of their effort was spent on building the system layer. This has obviously changed with k8s, so we have the luxury to focus on the platform layer and make innovations there, instead of using our resources on building the system layer. I do not have insight into why other k8s based PaaS (like Rio, Kel, and Hephy workflow) have been discontinued, but one notable difference is that we intend to make Porter a true Heroku-level PaaS that doesn't require familiarity with k8s, rather than becoming a PaaS that saves time and overhead for those who already use k8s. Hope this answered your question!
- mdasen 6y ago
  Yea, I think it does. I'm glad that you're not looking at support as a primary revenue source since that seems to be the kind of thing that leads to companies not wanting to fix pain points because those pain points are what people pay support contracts to handle. That's just a horrible tension because there's no reason to eliminate complexity. An enterprise company with a giant support contract just gets a support engineer to solve that complexity for them and it pushes everyone else to buy a support contract to get you to solve things. As someone working on a small team and trying not to burn cash, it feels like so much has become expensive since the "old" days of VPSs. Part of that is that people are accustomed to CI/CD, zero-downtime deploys, etc. Those are kinda table-stakes in a sense now. Many things are "solved" if you're willing to pay Amazon or Google higher margins, but it's tough if you're trying to build something user-friendly and lower-margin on your end (I mean, ultimately, it probably means that we should be pivoting toward something higher margin, but we love what we're working on). I definitely think RBAC can be a great differentiator between "small team" and "people who should pay us". At some point, you go from startup where people trust each other to "we need to be responsible and only some people get access to some parts". At the point that you're paying dozens of engineers, it seems reasonable to send some money to your PaaS provider that helped you get there and keeps you humming. I think mentioning RBAC really gets me on the "oh, yea...that makes sense. It's great and happy for a team of 3 looking for that awesome Heroku experience and fighting cash burn and when they hit a dozen or so engineers and are getting revenue and scaling up, $5,000/mo probably seems like nothing to pay for RBAC". I really hadn't thought much about "what" might be a good up-charge without either making the platform crappy for free users or something people wouldn't pay for. Heck, make SSO a paid add-on. Companies will pay so much for SSO while a small team of a few people can easily be like "yea, you just have a different password in the PaaS". I mean, Okta is worth billions just trying to solve SSO. Those both feel like features that companies making real money wouldn't hesitate to fork over cash for while someone working on a side project or a startup trying to become ramen-profitable can avoid. It definitely quells my worries of "will they decide that it's limited to 3 machines" or "will they decide that high-availability is just an enterprise feature" or "will they disable Let's Encrypt for free users". I mean, there are so many ways that a product can go into the "this is basically just trial software unless I pay" bin. I think pointing out that you're post-dating k8s by a decent amount is a great point too. A lot of things like Portainer pre-date k8s (and lots of things we take for granted now-a-days like Let's Encrypt) and now have Docker, Docker Swarm, and k8s modes that they're looking to support. Building as the ground is shifting underneath you isn't easy - you're building when k8s is pretty well-established, Helm seems established, etc. You're not trying to figure out where containers are going. You're not worried about Docker Swarm, Mesos, etc. You're just trying to make it fun and pleasant for people. Since you're here, one thing that I would say is that it would be nice if there was an easy "get a basic k8s setup on these servers I have" automated into your thing or a small doc of how you think it should be setup to start. I see that one can choose between AWS, GCP, DO, or "I already have k8s", but it would be nice to see something to get over that hurdle outside the three blessed platforms. Best of luck to you over the coming months!

by mdasen 6y ago

yebyen 6y ago

Deis Workflow is not abandoned! Just changed names, and teams, (but it's still my grandfather's axe!) https://web.teamhephy.com https://web.teamhephy.com If porter-dev is selling managed hosting platform services, they already have a stronger business model than Deis did (which was, I guess, to get acquired by Microsoft and subsequently never provide any form of managed version of Workflow) I don't know what Deis Labs business model is/was to be honest but it seems to have been a success, :-) there are worse footsteps to follow in

mdasen 6y ago
Cool, it's great to know that it isn't abandoned. I'm not sure why you'd say that their business model was a success. They were bought by Microsoft for Azure. I guess I wonder if a PaaS company can survive without getting the profits off renting the machines to people. Amazon, Google, and Microsoft all have PaaS options based around the idea that it comes bundled with the compute, not as a standalone open-source thing for you to use on any platform. I guess the question is whether Porter's business plan is "make enough that a company that owns a cloud wants to buy us". Oracle could probably use a nice PaaS platform and team. Maybe DigitalOcean would like to beef up their PaaS offering by acqui-hiring a team with proven knowledge.
- yebyen 6y ago
  Well, they built Helm which is reasonably successful and carries on their legacy with a large community following. They proved themselves to be among the top experts in the space and got some of the most solid financial backing you can imagine as a result of their efforts; the remaining Deis / Azure folks moved up the value chain, to build AKS, which is also pretty successful and has a large client base. They built Workflow which was IMHO incredibly popular with those that used it, but, from discussion I had with the folks that moved on leaving Workflow behind, it wasn't "pressure from above," or anything like that; they simply went where the market forces were pulling, and opted to work on what they thought would have the most impact. Team Hephy has never really had the aspirations to be a business, just to preserve the capability to go on using Workflow on newer generations of K8s. We develop and maintain it because we like using it, we don't need it to change in major ways, and so we aren't really concerned about its commercial viability (which Deis certainly was.) So, without the SaaS offering, what is the best outcome for a company that develops Workflow? You build up a base of customers who were all too cheap to use Heroku, and once in a while a breaking change from K8s upstream means they depend on your support, but only if they are conscientious about upgrading... I don't think that means there isn't or wouldn't be any market for Heroku-compatible competitors, not by a longshot. I have no idea if it's a viable market, but I still hear a lot of groaning about how hard it is to use Kubernetes often, and at least twice a year I see someone trying to invent Deis PaaS again. The "Kubernetes On-Ramping" market is still very ripe. How does it go? "I'm convinced the majority of people managing infrastructure just want a PaaS. The only requirement: it has to be built by them." https://twitter.com/kelseyhightower/status/851935087532945409 https://twitter.com/kelseyhightower/status/85193508753294540... I haven't tried this new one out yet, but I definitely will. Have to scope out the "competition" and see what the grass is like on the other side. I hope it is greener there!

sungrokshim 6y ago

Hi, I'm one of the co-founders of Porter. First I wanted to clarify that the OP is not affiliated with Porter - but thank you OP for putting us on HN! This was a pleasant surprise. As for the business plan, the honest answer is that we are still figuring out the specifics. That said, the goal is not to charge indie devs/small teams but charge for features that are geared towards collaboration/useful for larger teams. You raise an excellent point about how a truly good open-source PaaS shouldn't have a lot to charge for support. We completely agree with this, and we don't intend to draw revenue from support (as you flag, this model has a bit of tension with building an easy to use, automated platform). We believe that there are a ton of things that can be done that is useful for teams, and there's solid evidence for this on existing hosted PaaS's like Heroku, Netlify, etc. Review apps, pipelines, RBAC are few examples of these paid features on hosted PaaS's that we also consider to be potential premium features on Porter. As for the comparison with other PaaS's that came before us - Flynn, Dokku, Deis and Tsuru were built prior to the advent of k8s. Afaik, a lot of their effort was spent on building the system layer. This has obviously changed with k8s, so we have the luxury to focus on the platform layer and make innovations there, instead of using our resources on building the system layer. I do not have insight into why other k8s based PaaS (like Rio, Kel, and Hephy workflow) have been discontinued, but one notable difference is that we intend to make Porter a true Heroku-level PaaS that doesn't require familiarity with k8s, rather than becoming a PaaS that saves time and overhead for those who already use k8s. Hope this answered your question!

mdasen 6y ago
Yea, I think it does. I'm glad that you're not looking at support as a primary revenue source since that seems to be the kind of thing that leads to companies not wanting to fix pain points because those pain points are what people pay support contracts to handle. That's just a horrible tension because there's no reason to eliminate complexity. An enterprise company with a giant support contract just gets a support engineer to solve that complexity for them and it pushes everyone else to buy a support contract to get you to solve things. As someone working on a small team and trying not to burn cash, it feels like so much has become expensive since the "old" days of VPSs. Part of that is that people are accustomed to CI/CD, zero-downtime deploys, etc. Those are kinda table-stakes in a sense now. Many things are "solved" if you're willing to pay Amazon or Google higher margins, but it's tough if you're trying to build something user-friendly and lower-margin on your end (I mean, ultimately, it probably means that we should be pivoting toward something higher margin, but we love what we're working on). I definitely think RBAC can be a great differentiator between "small team" and "people who should pay us". At some point, you go from startup where people trust each other to "we need to be responsible and only some people get access to some parts". At the point that you're paying dozens of engineers, it seems reasonable to send some money to your PaaS provider that helped you get there and keeps you humming. I think mentioning RBAC really gets me on the "oh, yea...that makes sense. It's great and happy for a team of 3 looking for that awesome Heroku experience and fighting cash burn and when they hit a dozen or so engineers and are getting revenue and scaling up, $5,000/mo probably seems like nothing to pay for RBAC". I really hadn't thought much about "what" might be a good up-charge without either making the platform crappy for free users or something people wouldn't pay for. Heck, make SSO a paid add-on. Companies will pay so much for SSO while a small team of a few people can easily be like "yea, you just have a different password in the PaaS". I mean, Okta is worth billions just trying to solve SSO. Those both feel like features that companies making real money wouldn't hesitate to fork over cash for while someone working on a side project or a startup trying to become ramen-profitable can avoid. It definitely quells my worries of "will they decide that it's limited to 3 machines" or "will they decide that high-availability is just an enterprise feature" or "will they disable Let's Encrypt for free users". I mean, there are so many ways that a product can go into the "this is basically just trial software unless I pay" bin. I think pointing out that you're post-dating k8s by a decent amount is a great point too. A lot of things like Portainer pre-date k8s (and lots of things we take for granted now-a-days like Let's Encrypt) and now have Docker, Docker Swarm, and k8s modes that they're looking to support. Building as the ground is shifting underneath you isn't easy - you're building when k8s is pretty well-established, Helm seems established, etc. You're not trying to figure out where containers are going. You're not worried about Docker Swarm, Mesos, etc. You're just trying to make it fun and pleasant for people. Since you're here, one thing that I would say is that it would be nice if there was an easy "get a basic k8s setup on these servers I have" automated into your thing or a small doc of how you think it should be setup to start. I see that one can choose between AWS, GCP, DO, or "I already have k8s", but it would be nice to see something to get over that hurdle outside the three blessed platforms. Best of luck to you over the coming months!