Hacker News Reader

On the one hand, I don't want to post a shallow dismissal on your big launch day. On the other hand, this does look like something that's been tried a dozen times before. To name one example, Convox (https://convox.com/) started out using ECS on AWS, but more recently switched to being a multi-cloud platform on top of Kubernetes. Cloud66 has also tried a few things in this space. What sets Porter apart from other products in this apparently crowded field?

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.

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!

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!

> 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.

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!

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

We are early Porter users, and it strikes the right balance of being being "full service" to get you started quickly but then letting you tweak what we need in custom ways as you grow.

The setup was simple - EKS cluster created for you (or you can use your own), automatic bot instrumentation to build and push containers for you, Heroku-like "git-ops" etc.

But, under the hood they made the (IMO) wise choice to use each cloud's tooling as much as possible so you can modify things as needed. For example, the EKS cluster on AWS is in a regular autoscaling group. Persistent drives for containers (if you opt-into them) are regular EC2 block devices, etc.

After just skimming through the landing page, one thing I want to point out:

I absolutely love the fact that they simply show me what the product looks like. Often times you have to dig through docs and "features" pages just to get a glimpse of the offering. Here it's front and center, screenshots are right there in your face, can't miss it even if you want to.

To other SaaS developers, I say: SHOW ME THE DAMN PRODUCT!

The only step up from this is to have an interactive, radically simplified version of the product embedded in the landing page, with dummy data I can play with it, just to get a feel of the product. Obviously this is much more difficult to get right.

Thank you! That's a great idea, at the moment you need to go through cluster provisioning to get the feel of our product - we were looking for ways to make the product more accessible without having to provision an entire cluster in your cloud (was playing with the idea of demo accounts). We'll take this into consideration when we update our landing page next time. Thanks again :)

I'd second this. Too many developer-facing products focus on the call to action being to curl-bash something, without showing them what it is.

Showing off the product with clear screenshots is a real differentiator for me - I can understand far more quickly what you're offering from that visual.

Making that interactive (in a minimal sense) would be a great next step - demo accounts are nice, but a working demo in the actual page itself would be really powerful - someone looking at the screenshot wondering if it has X option can click it and see for themselves.

> The only step up from this is to have an interactive, radically simplified version of the product embedded in the landing page

Just having a live demo link would be great.

To get the cluster up and running using AWS EKS, it costs $0.10/hour which means at a minimum you're spending $72/mo ($860+/year) to just run the cluster and not the underlying resources. How do you justify this and compare against other options like Qovery?

I've self-hosted Dokku on Digital Ocean before with decent success: https://github.com/dokku/dokku. It's pretty nice for the scale of pet projects.

Yes Dokku is an awesome option for smaller projects. The maintainers are great!

Your point is valid, but 2 things:

> One thing we noticed is that there's an increasing number of startups who start on a PaaS like Heroku and end up migrating to k8s later as their applications “grow out” of Heroku, due to constraints in networking, performance, security, etc.

They seem to be particularly targetting users who are migrating off of Heroku (and are migrating to 'their own' Kubernetes) due to cost, at which point $72/m is likely a tiny drop in the bucket.

Second, I agree with you that the EKS pricing is extremely restrictive for small projects, and especially for projects that require multiple clusters. But that is kind of a gripe at AWS and their Kubernetes offering, rather than Porter. They appear to support other Kubernetes cloud offerings, so just use DigitalOcean's (DOKS) if you don't want to pay for your control plane.

When compared to non k8s-based PaaS solutions like Heroku, using a managed k8s offering like EKS can be expensive. For those who are running small scale projects, k8s is an overkill and the benefits of scalability and stability might not be enough to justify using Porter.

However, the underlying EC2 machines added to the $72/mo management fee on EKS is relatively cheap, and we've found that if you are using more than 4GB RAM/4 CPU on Heroku, the cost on EKS starts getting cheaper than Heroku (at scale, using EKS is substantially cheaper than Heroku). That said, we are actively working on partnering with independent cloud providers with cheaper k8s offering for those who are running small projects. At the moment the cheapest option is to use Digital Ocean with Porter, which can be as cheap as $35/mo. With regards to Qovery, AFAIK, Qovery also runs EKS and does not yet have the option to use cheaper cloud providers like Digital Ocean.

Hi, I am Romaric, co-founder of Qovery. We do support Digital Ocean (https://docs.qovery.com/docs/using-qovery/configuration/busi...) as well as AWS (https://docs.qovery.com/guides/tutorial/how-to-deploy-your-a...). We plan to support Scaleway and GCP in Q3 and Q4 2021. Here is the roadmap https://roadmap.qovery.com

Ah, this must have just been released, thanks for the correction. I was going off what's listed on qovery's repository [1] - It says "In Progress" next to Digital Ocean, you might want to update it along with the docs!

[1] - https://github.com/Qovery/engine#-plugins

Oh yes. Thank you. And good job for porter guys.

if you're running any kind of reasonably large deployment serving real customers, $72/month is NOTHING. my startup is dropping more than 1k/month already without including our devops guy's retainer!

Practically speaking for a company that's doing well in any way $70/month is basically nothing. Not every product needs to cater to every potential user and they seem to be catering to users who have some amount of money.

Even without a ton a money, I would pay for this in almost any startup environment.

As an early stage founder, my time would be way more valuable than $70/month. I need to do as many (practical) things as I can to focus on delivering the unique value of my product.

Really nice project, and really hoping these efforts could make devs lives easier! Alibaba indeed built a OSS project named KubeVela (https://kubevela.io) with similar goal though with a bit different approach:

1. Modeling all platform capabilities with Helm/CUE modules, so essentially a PaaS built with Helm/CUE.

2. Self-service workflow based on above LEGO-style components.

3. No specific add-on system, so just Helm charts.

We also auto-gen forms based on Helm/CUE, it's great more and more products are leveraging this capability and wider ecosystem.

It's great to see enterprises like Alibaba build out these types of internal developer platform (IDP) around Helm. We've talked to the engineers who built out these IDP's at different companies because we wanted to build a generalized solution that is not specific to one company's devops culture. We hope to democratize IDP's to smaller companies who can't afford to build things out themselves internally!

Have been using Porter for about 2 months now and all I can say is how impress I have been with the team's ability to ship new features + updates while also keeping up with their fantastic customer service! Have very high hopes for them and would definitely recommend betting on them early!

Can someone please list the existing "Heroku" on K8s PAAS (I know about a dozen on top of my mind) and compare with them one by one?

Would 'your own' not at least also imply bare metal? Kubernetes on standard hosting hosting (without special routers/private networking) seems a pita. I want my own because I want to get away from the big hosters, but seems no boxed solutions with kubernetes cater for that. Or maybe I just do not know them yet; I have asked around a lot.

(The load balancer is the issue: there seem no good ingress solutions if you do not have hardware support even though there are lb as a service like cloudflare and software loadbalancers which are not supported. Again as far as I can find)

I run enterprise cloud infra for living. If I were to use a self hosted Heroku thing, would be conflicted about it being based on K8s.

On the one hand, I get it that what you're doing is complex and K8s does a lot of it for you. On the other hand, you're building a complex system on top of a complex system. This naturally leads to more difficulty and doesn't really give much advantage after the system is built. Technically if your system is buggy I could dive into K8s, or add functionality with K8s. But I don't want to have to do either of those.

The best system would be one whose essential complexity is stripped down to just what one needs to do for the primary goals of the system. One example is Drone.io, which is the simplest CI system I have ever seen. It is limited in functionality, yet I don't think there's anything you can't do with it. And it's insanely trivial to configure and run. It certainly has issues you have to work around, but it's so simple that that's not hard to do.

I admire your goals, but my bet is that unless you are geniuses, this is going to end up more complicated than you imagine, and it'll take more sales work than engineering to make it successful. Best of luck to you.

does anyone have any insight what's with all these companies coming out of yc that are just open source implementations of currently successful projects? there's been at least 5 now

is there some reasoning behind it or are we running out of ideas?

Natural selection?

Most devs try to avoid a lock-in situation. Having an open source option for the base functionality with additional paid features is something you can compete on.

> does anyone have any insight what's with all these companies coming out of yc that are just open source implementations of currently successful projects? there's been at least 5 now

I can't speak for other companies, but we didn't look at Heroku and think to just create an open-source competitor. We thought of the idea after interacting with companies that migrated to Kubernetes that wanted their Heroku experience back, and later decided to be open-source. So I don't think our core value proposition stems from the open-source aspect, but it made sense for a lot of reasons -- unique to our product/team we felt that open-source was appropriate for a tool in the cloud-native ecosystem and since all three of us are developers, it was our natural inclination.

On the technical side, being open source has come with a bunch of benefits thus far -- we get detailed bug reports since our users are developers, we get a channel where devs can keep tabs on our progress, it gives us a public log where we explain our decision-making in the specs for various features, and it forces us to be better technically. We had to create a development process rather than just push code (when we worked on projects in the past, we didn't follow best practices with regards to PRs, documenting issues, reviewing code and testing changes, because we were solely focused on immediate velocity, which we would have regretted if those projects ever got off the ground).

Building open source comes with a bunch of technical benefits like my co-founder mentions, and I don't think the recent trend is a result of YC startups "running out of ideas". It's somewhat like food companies going organic - at first organic food was a special thing, but organic food is becoming increasingly common because every company is doing it. (or maybe it's just at my grocery store :) )

We decided to go open source quite naturally for the benefits that Alexander mentions, but we are also aware of the business benefits that OSS brings. Open source/open core is increasingly becoming a standard in the devtool world and as the other comment points out, there is a certain degree of natural selection at play. To gain traction as a devtool company and drive bottoms-up growth, building in public helps tremendously these days, because developers almost don't want to use closed source products. Although the rise of "open core" and commercial open source projects does come with a bit of tension with open source purist ideology, I think this trend is something we should welcome as an industry. But this trend definitely isn't just a result of running out of ideas like Disney's endless real life remakes :)

Hello! I'm currently using Heroku and exploring a switch due to technical limitations with Heroku.

My team is evaluating porter versus alternatives like Qovery and Skaffold. What is your pitch on Porter versus other attempts to replicate the magic of Heroku with kubernetes on a directly controlled cloud?

Skaffold is a bit different from Porter and Qovery because it's mostly a tool for development on Kubernetes, and its primary goal isn't to make deployments as easy as Heroku on k8s.

I describe this in more detail in the comment above, but I would say the biggest difference between Porter and Qovery is that we intend to make Porter a platform that accommodates not only those seeking the magic of Heroku in their own cloud, but also the devops engineers who want to customize and "opt-in" to be exposed to the underlying complexity of k8s. Please give the above comment a look and lmk if you have any lingering q's.

Hi - thank you for asking - I am Romaric, Co-founder of Qovery. Give a try to both product and pick the one is best for you. Porter and Qovery respond to two different purposes. Qovery offers a free plan for individual developer and a generous business plan (free up to 10 apps). Have a good day. Romaric

Yup, we don't plan to support a fully-hosted alternative to something like Heroku/Render where your applications run on our cloud.

First, congrats on the launch! Glad to see more products in this space. Now, some questions :)

I've looked at many of the attempts similar to this over the years and while you hear "you don't need to know how to operate K8S" you are in fact operating K8S and when there's a problem suddenly all this complexity is revealed. If Heroku has a problem, it's pretty clear where the responsibilities lie, but with this it's your code but my deployment so I'm kind of on the hook. What are your thoughts on that?

How would you compare to something like app platform at Digital Ocean?

Thanks!

> I've looked at many of the attempts similar to this over the years and while you hear "you don't need to know how to operate K8S" you are in fact operating K8S and when there's a problem suddenly all this complexity is revealed.

You're definitely right to flag that there's a fine line between a useful and leaky abstraction of Kubernetes as a PaaS. Since Porter expects you to deploy services by linking up a GitHub repo or Docker container, our responsibility is the same as a service like Render which also delivers a Heroku-like experience on Kubernetes. Fwiw at least half of our users are teams that have no existing familiarity with k8s and they're able to use Porter treating it purely as an implementation detail.

> How would you compare to something like app platform at Digital Ocean?

The main difference on the flip side is that app platform locks you out of deeper control of the underlying infrastructure if you ever want it (say, for configuring a production environment): https://docs.digitalocean.com/products/app-platform/#when-no.... Also, I suppose it goes without saying, but the abstraction we provide has the benefit of being cloud-agnostic and is the same regardless of where your environments are hosted (DO, AWS, GCP, etc).

I had the pleasure of speaking with the founder way back when they were super early. Was really impressed but didn't have a very good use for it for me.

So glad to see them grow into what they've become today :)

Off topic, but my last name is Porter and a couple years ago I tried to register the domain porter.dev but it was taken. I'm guessing you probably tried to do the same :-D

Porter looks really nice, kudos on open source.

Also, lots of companies in this area, was talking to folks behind Octad (https://octad.io) who are doing similar stuff too.

I also wonder how will it all play out in 1yr and how it would impact customers. Almost all these cos are on the similar tangents - Render (self hosted), Qovery, Convox, Platform.sh, Octopus.com, Reploy, Releasehub, etc etc.

The advent of k8s really gave the PaaS providers the luxury to focus on the platform layer rather than creating the infra layer from scratch. The market is early and we're excited to see what innovation each of us is going to bring to the table!

I think my major hesitation is your pricing model, I don’t want to be surprised by some bill and that is the biggest turn off from your product.

I just want to peacefully launch my side projects without being “locked” into a vendor or framework that will start charging me on a random day after it was free.

That’s why I opted out of porter and learned to deploy and build my own automation pipeline.

Please change my mind porter guys.

Pricing discussion is always tough for startups because the pricing model evolves so quickly and so often. As I address in the post, we are still figuring out the specifics and we completely understand that some users will be turned off by this - we apologize for this uncertainty. I am aware how naive and hand-wavy this sounds, but we genuinely mean it when we say our goal is to not charge smaller companies and indie devs. We are not maliciously avoiding the pricing discussion because we want to "surprise charge" users later.

It is simply too premature to settle on pricing at the moment because we do not have enough data on the "bigger users", who will likely comprise most of our revenue. We have no intent to go out of our way to squeeze revenue from smaller users hosting side projects - quite frankly, the addressable revenue of that user segment is just too low compared to that of larger businesses for us to even fight that battle.

Does Porter support having isolated environments per git branch like Quovery?

https://docs.qovery.com/docs/getting-started/what-is-qovery/...

Yes it's possible to do that on Porter. When you deploy an application, you choose which branch you want to deploy from and we build/deploy the application on every push to the specified branch. Under the hood, we write a GitHub actions file in your repo, so it's completely flexible and up to the user to configure how branches map onto environments (i.e. whatever is possible on Github actions is possible on Porter).

We also plan to support a more out of the box behavior by adding integration with GitHub's recent deployment feature: https://docs.github.com/en/rest/reference/repos#deployments

How does this compare to Dokku?[1] I've been using that for a few years now with minimal lift/maintenance. I'm wondering what the trade-offs are of something like this?

[1]: https://dokku.com/

If you're running small projects, Dokku is a cheaper option compared to running a k8s cluster. Porter helps you leverage all the benefits of k8s like scalability, scalability, configurability, and is great for multi-cloud environments due to interoperability - these are all useful when you're dealing with projects at a larger scale.

A short video of how it works or more screenshots might be a nice addition to the repo.

github and documentation[1] have more screenshots

[1] https://docs.getporter.dev/

How useful would Porter be for teams that have little to no Kubernetes experience?

Teams with little to no k8s experience are the type of users we are primarily designing it for! The advanced features like "devops mode" is completely optional and only useful if you want to expose yourself to the complexity of k8s.

What happens when someone has no k8s experience and the kubernetes cluster malfunctions?

This is the benefit of using managed providers, which don't expect you to have any experience with the Kubernetes control plane. If you don't modify the underlying infrastructure that Porter creates, the chances of a malfunction are quite low (we haven't actually come across a cluster-level issue that wasn't easily resolvable, although I'm sure it'll happen at some point).

Also, if a Kubernetes deployment malfunctions (or any other Kubernetes resource is added incorrectly) and you created it through Porter, it's a bug on our end, and would be dealt with by pushing a fix and requesting that you upgrade that application to the latest version. Along with this, if a Kubernetes deployment fails due to expected behavior (e.g. your worker machines are out of resources), it is our responsibility to propagate that error to the user and give you an easy way to fix it.

Again, there are likely some edge cases for more complicated use-cases, but this has been our experience so far.

I have found it easy to deploy with Dockerfiles on Porter, but tough to use buildpacks (with python. Node seems to work).

Is there a guide on how to deploy with docker-compose, instead of dockerfiles?

it's not possible to use docker-compose to deploy on Porter atm. This is something we've considered implementing but it gets too hairy to accommodate every option possible on docker-compose. Please reach out in our community if you have trouble using buildpacks!

Neat project. I was recently looking at Fly for similar functionality. Wonder how different the day to day experience is? Anyone familiar with the two?

Any chance you could add Azure support as well? Perhaps there is something particular that is making that harder?

We've talked to the folks at Azure recently, and Azure support is on its way along with a few other cloud providers!

Great idea! I'd totally use this if it had Azure support. Is Azure support on its way?

Yup, we're rolling out support for Azure and some other cloud providers in the next few months!

i think your website looks good. the subtle animated gradient on the rectangle at the bottom of the page is a nice touch. i like how straightforward the page is. nice work

Nice, but no Azure support. Why?

Lack of technical bandwidth, for the most part. To break down our decision-making: EKS was the most widely requested from the beginning, we have the most collective experience on GKE, and we wanted a cheaper option with DO. And between the three of us, none of us have experience on Azure.

But we're working on Azure support first, and then looking at some smaller providers. I would expect the first Azure rollout in ~4 weeks.

Sick project! When's the IPO? :D

Launch HN: Porter (YC S20) – Open-source Heroku in your own cloud