I highly recommend checking out Northflank. Their pricing is a lot friendlier.
Show HN: Porter Cloud – PaaS with an eject button
81–90 of 97 posts
Re: Show HN: Porter Cloud – PaaS with an eject button
#82We 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…
> Devops expertise: The Porter team have given us next-level hands-on support and help to figure out how to run things optimally How long until they’re victims of their own success and can’t give every customer bespoke support…
Hopefully the experience they're getting now will make increasingly more of the relevant decisions something they can bake in to their automation and defaults.
Re: Show HN: Porter Cloud – PaaS with an eject button
#83Earlier quoted context omitted.
They charge for managing the kubernetes instance that’s running on your infrastructure. What’s cool is that you can stop using Porter once everything on AWS/Azure/GCP is set-up and you’re not locked in. You just have to manage the cluster yourself.
I meant: what's the business model for Eject specifically? Why make it easy for customers to leave (aside from pre-empting buying-decision concerns)
Unless I've misunderstood entirely, Eject can move you from Porter Cloud to "you bring the cloud account but some/most things are still managed through your Porter setup."
Re: Show HN: Porter Cloud – PaaS with an eject button
#84Is the eject button the only thing that makes Porter more appealing than something like Fly.io or Render? They too automate a lot of stuff but for a better price.
I think it's not just the eject button, but Porter's service automation model being designed to move elsewhere with equivalent moving parts underneath.
I wouldn't be surprised if as a result migrating from Porter to elsewhere without using the eject button would probably be easier than migrating from fly.io - a sensible architecture on fly is likely more different to a sensible architecture on a 'normal' cloud platform.
(I could be completely wrong about all of this and would want to see worked examples before I get more certain than "wouldn't be surprised")
Re: Show HN: Porter Cloud – PaaS with an eject button
#85Earlier quoted context omitted.
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
Thanks! Followup question: After you "eject" the app and start paying AWS directly but continue using porter, is the experience more like the archived repo? Or, is it still Porter Cloud just with different billing underneath?
The experience after ejecting to your own AWS account is the same as Porter Cloud. If you're using something like Postgres on Porter Cloud that also gets switched to wrap RDS under the hood in the AWS case
Re: Show HN: Porter Cloud – PaaS with an eject button
#86Earlier quoted context omitted.
OP here. Cloud Run actually does have a git-push deployment and is pretty easy to use. This is why I preemptively added this bit in the post: > [1] By “big three clouds” we mean the lower-level primitives of each cloud provider. We don’t mean their higher level offerings like AWS App Runner, Google Cloud Run, or Azure App Service, since those run into the same PaaS problems described above. Porter is explicitly desig…
That is why I said Cloud Functions instead of Run.
Agree, and Cloud Run's upcoming application canvas feature appears to offer a simple way to integrate the various GCP services together seamlessly without much hassle.
Re: Show HN: Porter Cloud – PaaS with an eject button
#87Earlier quoted context omitted.
As long as the cloud providers of the world keep inevitably converging to, often against their own will, a single standard for each piece of the infrastructure (e.g. k8s, postgres, S3), most things that you deploy on the cloud will remain portable. You are never truly locked-in. Similarly, if you want to, you can move away even from a PaaS that is explicitly designed to lock you in to another cloud provider. And as I…
> We want the process of moving from Porter Cloud to one of the hyperscalers as arbitrary as a click of a button. What I don't understand is why someone would start with Porter Cloud.
Small startup with brand new team, no devops/infrastructure/security. Most engineers are mid-level and not really strong on infrastructure, they are hired to build features and backend.
In this environment something like Porter Cloud would make it far simpler to deploy apps as they were being built and know that there is a chance of scale (at least to a certain degree). Otherwise you get to watch engineering grind to a halt while everyone learns how ECS/AIM/SSM/XYZ works.
Re: Show HN: Porter Cloud – PaaS with an eject button
#88Can I use it on DigitalOcean?
Re: Show HN: Porter Cloud – PaaS with an eject button
#89I 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…
> Is there something I'm missing here? Your statement on the ease of migration really depends on your skill set. An increasing number of software engineers do not have to deal with real infrastructure whatsoever. Most of the "big" companies I've been at have pretty ready made platform abstractions for their engineers.
This is PaaS, there is no "infrastructure". It is a http handler function and that is it.
Re: Show HN: Porter Cloud – PaaS with an eject button
#90Earlier quoted context omitted.
> We want the process of moving from Porter Cloud to one of the hyperscalers as arbitrary as a click of a button. What I don't understand is why someone would start with Porter Cloud.
Small startup with brand new team, no devops/infrastructure/security. Most engineers are mid-level and not really strong on infrastructure, they are hired to build features and backend. In this environment something like Porter Cloud would make it far simpler to deploy apps as they were being built and know that there is a chance of scale (at least to a certain degree). Otherwise you get to watch engineering grind to…
Spend some time understanding what Cloud Functions has to offer. There really isn't much to it at all. A http handler function is all you need. No infrastructure or need to do much deeper than that.