2 ms·

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

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!

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!