No worries, this is a valid point and does not come off as a dismissal. As you said, there are many PaaS's built on Kubernetes. And they lie in a spectrum of abstraction: on one end, there are OpenShift and Rancher that requires knowledge of Kubernetes to some extent. On the other end of the spectrum, there are hosted PaaS's like Render that look more like Heroku, and the user does not even know that their applications are running on Kubernetes. In my opinion, at least as it currently stands, Cloud 66's Maestro and Convox fall somewhere in between.

Our goal with Porter is to create a platform that accommodates both ends of the spectrum. And this is motivated by seeing companies develop internal developer platform (IdP) that I mention in the post - we want to create a platform that abstracts k8s away to the extent of Heroku's DX while accommodating the DevOps engineers' need for flexibility/configurability on top of k8s. This is why we invested in features that optionally give the user more visibility into the underlying k8s cluster and helm charts.

By default, Porter looks and works just like Heroku. With "devops mode" turned on, Porter looks more like OpenShift and Rancher. Essentially, there are two user personas we are building for: an application developer with no knowledge of k8s and the devops engineers who need to help the application developers and often even build out an IdP. We are focused on the former for now, but I think what distinguishes us from the other k8s based PaaS's is our commitment to building the mature version of Porter to accommodate the latter.

Thanks for that response.

Do you have any plans to cater to devops engineers who want to use infrastructure as code tools such as Pulumi or Terraform to manage both their Kubernetes cluster and their other cloud resources (e.g. AWS RDS database) with one tool?

Also, just so you know, the abbreviation IdP (with that particular capitalization) is already a term in security, particularly in the context of single sign-on; there it stands for identity provider. Edit: I suggest IPaaS as an alternative.

Co-founder (Alexander) here.

> Do you have any plans to cater to devops engineers who want to use infrastructure as code tools such as Pulumi or Terraform to manage both their Kubernetes cluster and their other cloud resources (e.g. AWS RDS database) with one tool?

Yes, this is a request that we've gotten from current users, and we'd like to release a Terraform module in the next two months that allows users to provision a cluster compatible with Porter for this exact use-case. We're also thinking about releasing a Terraform module that can install a cluster hosting the PaaS layer for fully on-prem use-cases. This wouldn't be too hard to do considering our cluster provisioner is packaged as a Terraform runner and we use Terraform to manage our infrastructure internally.

Also, we're going to open-source our provisioner in a separate repo at some point soon, and we're thinking about using Pulumi to get slightly more control over the automated infrastructure provisioning (using Pulumi's automation API: https://www.pulumi.com/blog/automation-api/). So I wouldn't be surprised if we released something more native to Pulumi as well, but we have to look into it more.

> Also, just so you know, the abbreviation IdP (with that particular capitalization) is already a term in security, particularly in the context of single sign-on; there it stands for identity provider. Edit: I suggest IPaaS as an alternative.

I thought I recognized that abbreviation -- I believe we picked it up after reading an interesting article about various internal dev platforms[1] (to be fair, that article uses the capitalization IDP).

[1] https://www.infoworld.com/article/3611369/how-to-build-an-in...

I played with convox a little and a month later discovered I unexpectedly owed AWS a rather large sum of money. For small projects I'm now happy running caprover on dedicated hosts where I understand the cost (and it's really quite small).

One way porter could interest me would be if it incorporated best practices for me not to get fleeced by the cloud operator.

We've encountered this from our early users and are definitely looking for ways to incorporate transparency of cost. AWS is particularly opaque when it comes to pricing, and I'd love to hear any ideas you have in things that would help you better understand costs. What comes to mind is integrating with something like InfraCost (YC W21)...

That said, for small projects we are adding support for cheaper independent cloud providers very soon. We've talked to folks at both Vultr and Linode, which provide significantly cheaper k8s offerings, and are working with them right now!

Co-founder of Infracost here, happy to help with integrations if needed. Regarding smaller cloud providers, someone from our community is adding Scaleway, such providers usually have pricing that is an order of magnitude simpler than AWS/GCP/Azure.

Hey greetings from Romaric :)

Yes let's talk!

> AWS is particularly opaque when it comes to pricing

How so? Doesn't AWS break down the cost of each resource you consume? I suppose it's difficult to predict all of the little costs that will add up though.

I think Convox estimated their racks were around $140/mo min on AWS

Yes there was also Skyliner.io and I had one coincidentally named Surfliner 3 years before that which I killed before launching. What I’ve learned is that in this particular space there are two kinds of developers: the ones that don’t want to run anything and the ones that want to run everything themselves.

This was our biggest hesitation when we were first evaluating the idea - we thought companies want to either "outsource" devops completely by using something like Heroku, or hire a devops engineer to do the devops work, obviating the need for a platform like this.

However, we were surprised to find that a lot of our users actually fall in the middle - they want to run things in their own cloud, but don't want to deal with the complexity of k8s. Perhaps the biggest change in the last 3 years is that k8s became a popular option even for startups - adoption of k8s has been "trickling down" and now the k8s user base is increasingly composed of those who "know the basics of k8s, but don't want to deal with all of its complexity". We've found that a platform like Porter fits in with that type of demographic, and we are optimistic that there are more of these companies based on our current data.

No doubt K8s could have changed things and I certainly don’t mean to discourage you! Best of luck!

Deis Workflow (now Hephy) is another one that didn’t last. This is an area I’m very interested in, but I worry there isn’t enough of a critical mass to support tech like this.