Show HN: Porter Cloud – PaaS with an eject button • Hacker News Board

Re: Show HN: Porter Cloud – PaaS with an eject button

#31

Post by MobileVet » Thu, May 23, 2024, 9:23 PM UTC

I have never quite understood this value proposition (maybe I am not the target audience?) The point of PaaS is to avoid DevOps... making a PasS with an eject just feels orthogonal to the value prop of the main business. Ejecting seems like a low probability event as they CHOSE PaaS in the first place. (unless the money got really high)

We included Porter in our post-Heroku research and chose Render. We have loved Render and expect to be with them for quite a while (as we were with Heroku). If they happen to go south as Heroku did, we will find another PaaS... we will not 'eject' to bare metal or self configuration on AWS.

Re: Show HN: Porter Cloud – PaaS with an eject button

#32

Post by latchkey » Thu, May 23, 2024, 9:40 PM UTC

I personally don't get it. You can start on GCP today, without being tied to GCP much at all. It isn't even expensive to do so. Is there something I'm missing here?

Cloud Functions are just a http handler with no hard dependencies on GCP.

Cloud Tasks are just a handler and the tasks just hit your Cloud Functions.

Cloud SQL is just postgres.

You connect your github with actions that CI/CD auto deploy to the above.

If you do it that way, you're pretty much dependency free and can move anywhere else if you need to.

Re: Show HN: Porter Cloud – PaaS with an eject button

#33

Post by adenta » Thu, May 23, 2024, 9:44 PM UTC

talk to me about GPU’s? I saw some gpu_node config stuff in your documentation a couple days ago.

If Porter can host GPU’s, that’s a superpower render.com doesn’t have.

Re: Show HN: Porter Cloud – PaaS with an eject button

#34

Post by kiney » Thu, May 23, 2024, 9:52 PM UTC

Any plans to support eject to on-prem or bare metal hosters like Hetzner?

Re: Show HN: Porter Cloud – PaaS with an eject button

#35

Post by jedwhite » Thu, May 23, 2024, 9:55 PM UTC

We migrated microservices from Heroku to Porter, and also from standalone VMs and K8s running on AWS to Porter. As a coder trying to do both dev and devops on a tiny team, it was life changing for me.

The key benefits for a small startup team are:

1. Effortless CI/CD: Deploying services on K8s clusters across different clouds becomes trivial. Setup a dockerfile in your repo, point Porter at it, deploy. We mostly run APIs behind AWS API Gateway.

2. Startup credits: You can use your existing credits on AWS, Azure etc.

3. Zero lockin: You can deploy in parallel and switch service providers.

4. Devops expertise: The Porter team have given us next-level hands-on support and help to figure out how to run things optimally. A lot of sensible defaults are built in. As a coder, they have knowledge of how to scale services effectively that (to be blunt) I couldn't match no matter how much time I spent trying to learn it as a lay person.

If you're a K8s and devops master, you probably don't need this. If like me you're a programmer with limited devops skills looking for the fastest and easiest way to just solve deployment and scaling, Porter is close to magic. Plus they have one of the most helpful and friendly teams I've worked with anywhere.

(edit for typo)

Re: Show HN: Porter Cloud – PaaS with an eject button

#36

Post by chadsix » Thu, May 23, 2024, 10:02 PM UTC

kiney wrote: post #34

Any plans to support eject to on-prem or bare metal hosters like Hetzner?

There's a separate project Cloud Seeder [1] which is completely open source and gives you 1 click server appliances and IP addresses on-premises. Disclosure, I work there.

[1] https://github.com/ipv6rslimited/cloudseeder

Re: Show HN: Porter Cloud – PaaS with an eject button

#37

Post by dangoodmanUT » Thu, May 23, 2024, 10:17 PM UTC

latchkey wrote: post #32

I personally don't get it. You can start on GCP today, without being tied to GCP much at all. It isn't even expensive to do so. Is there something I'm missing here? Cloud Functions are just a http handler with no hard dependencies on GCP. Cloud Tasks are just a handler and the tasks just hit your Cloud Functions. Cloud SQL is just postgres. You connect your github with actions that CI/CD auto deploy to the above. If…

You're just like the dropbox launch just use ftp guy

Re: Show HN: Porter Cloud – PaaS with an eject button

#38

Post by jusrhee » Thu, May 23, 2024, 10:23 PM UTC

kiney wrote: post #34

Any plans to support eject to on-prem or bare metal hosters like Hetzner?

At the moment we only support the major hyperscalers since they're the most common ejection destinations, but we're considering adding more options. No concrete plans for this at the moment though

Re: Show HN: Porter Cloud – PaaS with an eject button

#39

Post by jusrhee » Thu, May 23, 2024, 10:30 PM UTC

scottmessinger wrote: post #26

Very cool! As someone pointed out, your github repo says it was archived: https://github.com/porter-dev/porter-archive Naively, I would think Porter cloud would just be a managed version of your porter-dev/porter-archive. Could you talk about how it's a different product than before? Did the code base change significantly?

Our archived repo functioned as more of a Kubernetes-centered dashboard - Porter Cloud is intended to offer a more complete PaaS experience including spinning up non-application resources like databases

Re: Show HN: Porter Cloud – PaaS with an eject button

#40

Post by latchkey » Thu, May 23, 2024, 10:32 PM UTC

dangoodmanUT wrote: post #37

latchkey wrote: post #32

I personally don't get it. You can start on GCP today, without being tied to GCP much at all. It isn't even expensive to do so. Is there something I'm missing here? Cloud Functions are just a http handler with no hard dependencies on GCP. Cloud Tasks are just a handler and the tasks just hit your Cloud Functions. Cloud SQL is just postgres. You connect your github with actions that CI/CD auto deploy to the above. If…

You're just like the dropbox launch just use ftp guy

Ouch, that's an absurd comparison. Instead of commenting nonsense, how about explaining to me how I'm missing the mark here?

Let's break it down a bit...

"Porter takes care of a lot of generic DevOps work for you (like setting up CI/CD, containerizing your applications, autoscaling, SSL certificates, setting up a reverse proxy)."

All of this is done for you on GCP with the aforementioned services.

"Porter Cloud for as long as it saves you time and development cost, but at any time you can press the “eject button” to migrate your app to your own AWS, Azure, or GCP account as you please."

Why add an additional service, and set yourself up for having to "eject", when you can just start off on the right foot to begin with?