Awesome to see this project -- this is one of the use cases that really emphasizes/shows off the benefits of choosing Kubernetes as an ecosystem -- it's possible to build things like this on k8s because it has concerned itself with a nauseating amount of the mechanics (and abstractions thereon) of application development and delivery.
If I didn't know any better I'd expect both fly.io and Render to be build on Kubernetes, and I feel like I could build Cloud Run in a weekend with Kubernetes (with decent isolation and actual global reach as well) -- there is a tremendous amount of value in the ecosystem just waiting to be used for projects like this.
> and I feel like I could build Cloud Run in a weekend with Kubernetes (with decent isolation and actual global reach as well) -- there is a tremendous amount of value in the ecosystem just waiting to be used for projects like this.
Well you can, because Cloud Run is using Knative behind the scenes, so you only need a web UI
I'm sure an actually robust Cloud Run look-alike is a lot more work than just adding a web UI but yes, I agree. Details like isolation, storage, security, addon-services, etc take a lot more time to work out (and some lessons you only learn by doing it wrong once or twice) but simply running KNative does get you ~80% of the way there.
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.
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
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.
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.
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!
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.
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.
Heroku and Porter are more like a PaaS (Platform as a Service). Not sure FaaS can compare here. A PaaS could include a FaaS offering, but not the other way around.
Unless you can deploy something like Postgresql to a FaaS. If that's doable, I'd like to read more about it.
I have long pondered an answer to this question. There are some hacks for various DB mechanisms. But nothing truly on par. It's a business opportunity if anybody crack this!
CapRover is cool, although at least last time I looked at it, it felt more suitable for personal hosting. In a way it promoted point-and-click interactions over scriptable, CD-type deployments.
It actually offers both point-and-click and CD-type deployments (through webhooks). But yeah, not the most powerful piece if you are looking for CD/CI. Still more than good-enough IMHO.
Looks really neat. We have a not-super-trivial rails app that I want to move to docker one day, but kinda scared to make the jump. We're already using docker for development, plus even have a home-grown docker-compose setup for ephemeral labs, but it's clunky at best.
This seems like something that might provide a simple jumping board hopefully... Also bumped into fluxCD[0] recently which also looks interesting.
It's not necessary for you to dockerize your app to use Porter. Porter uses buildpacks to automatically build your apps if it can't detect a Dockerfile.
Thank you. The docker part isn’t the barrier for us, but rather all the other moving parts that glue stuff together, eg load balancing, custom nginx directives we have, static file serving/caching, deployments, datadog integration etc ... not to mention just the paralisys of choosing something amongst the sea of options out there :)
Apologies for the super vague error message here: this happens when the CLI is unable to read some required data from your kubeconfig or the kubeconfig contains an integration that we don't support. Mind if I ask which Kubernetes provider you use? (This comes up most often when the Kubernetes provider uses an exec-based auth mechanism).
It'd also be easier to debug in our Discord if you post to the #help channel there!
I investigated a little bit and it was a problem with certificates, the internal error message was "could not resolve kube integration (x509)". I was using a single-node k8s cluster hosted on Digital Ocean that I created myself.
I'm a beginner when it comes to k8s so I ended up just provisioning from the dashboard, everything's working now :)
I am with Team Hephy, and for the record I think this is super cool what you've done. I just think it's an awfully great coincidence that the name is so close to something else so nearby in the same space!
I was unaware of the Hephy Workflow/Deis Labs background, but yes, porter.sh has come up recently and we are aware of this.
For some clarification, Porter was initially started as a remote dev solution (similar to Github Codespaces) as part of the S20 YC batch, which operated in a very different space. When we pivoted to the current PaaS solution, we kept the same company name/domain, but didn't think to check on the name collision after we pivoted.
We're going to address this at some level, whether it be a name change or much more explicit clarification in our Github repo, since we're also unhappy about the name collision. Sorry for any confusion this may have caused.
I stopped reading the docs almost immediately when right away they indicated I had to paste (and more importantly understand) a massive piece of text for AWS IAM. If that's the starting point, it's a poor introduction. I'm still interested, but dokku is still the gold standard for a Heroku replacement for me.
40 comments
[ 3.0 ms ] story [ 84.8 ms ] threadIf I didn't know any better I'd expect both fly.io and Render to be build on Kubernetes, and I feel like I could build Cloud Run in a weekend with Kubernetes (with decent isolation and actual global reach as well) -- there is a tremendous amount of value in the ecosystem just waiting to be used for projects like this.
Well you can, because Cloud Run is using Knative behind the scenes, so you only need a web UI
That said, we do support running a basic instance of Postgres, Redis, or Mongo: https://docs.getporter.dev/docs/add-ons-1.
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.
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
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.
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/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!
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!
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 yo...
https://github.com/openfaas/faas
Unless you can deploy something like Postgresql to a FaaS. If that's doable, I'd like to read more about it.
I do wonder if hosting dqlite inside of OpenFaaS would be possible as it's just distributed sqlite which is just a file...
Login -> GCP -> back button -> page crashes
I'm leaning towards just paying for heroku, because it's managed.
This seems like something that might provide a simple jumping board hopefully... Also bumped into fluxCD[0] recently which also looks interesting.
[0] https://github.com/fluxcd/flux
It'd also be easier to debug in our Discord if you post to the #help channel there!
I'm a beginner when it comes to k8s so I ended up just provisioning from the dashboard, everything's working now :)
If so, are you aware of the Porter project which is built on CNAB, (by I believe many of the same folks?)
https://deislabs.io/
I am with Team Hephy, and for the record I think this is super cool what you've done. I just think it's an awfully great coincidence that the name is so close to something else so nearby in the same space!
For some clarification, Porter was initially started as a remote dev solution (similar to Github Codespaces) as part of the S20 YC batch, which operated in a very different space. When we pivoted to the current PaaS solution, we kept the same company name/domain, but didn't think to check on the name collision after we pivoted.
We're going to address this at some level, whether it be a name change or much more explicit clarification in our Github repo, since we're also unhappy about the name collision. Sorry for any confusion this may have caused.