Open source Heroku Like Platform on premises
github.com
github.com
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.
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 you over the coming months!
I'm leaning towards just paying for heroku, because it's managed.
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.
Well you can, because Cloud Run is using Knative behind the scenes, so you only need a web UI
If so, are you aware of the Porter project which is built on CNAB, (by I believe many of the same folks?)
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.
This seems like something that might provide a simple jumping board hopefully... Also bumped into fluxCD[0] recently which also looks interesting.
$ porter connect kubeconfig
Error: code 500, errors [could not write to database]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 :)
Login -> GCP -> back button -> page crashes
{"code":403,"errors":["Could not read cookie: are cookies enabled?"]}
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...
That said, we do support running a basic instance of Postgres, Redis, or Mongo: https://docs.getporter.dev/docs/add-ons-1.