[latchkey]

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.

[sungrokshim]

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 mentioned in the post, this is exactly what we've done for countless companies that wanted to move from a PaaS to the big 3 cloud providers.

The more important question is: what is the switching cost? Why do companies so rarely switch hosting providers and if they do, why does it take months and sometimes years for them to move?

We want the process of moving from Porter Cloud to one of the hyperscalers as arbitrary as a click of a button.

[latchkey]

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

[mitchitized]

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.

[latchkey]

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.

[oooyay]

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

[latchkey]

This is PaaS, there is no "infrastructure". It is a http handler function and that is it.

[oooyay]

Yes, OP is talking about the ease of migration from cloud providers vs a PaaS. My point is most companies these days either build their own or operate a PaaS so "migrating cloud providers" would be daunting to them due to lack of exposure to core services (network, compute, etc).

[latchkey]

GCP Cloud Functions are PaaS running on top of a “cloud provider”. My point is that if you start with CF, there is no lock in and no migration.

[dilyevsky]

How do you do secrets with CFs without lock-in? Telemetry? Releases? and on and on

[latchkey]

Tons of options, some more "lock-in" than others. But the stuff you're talking about in general is really not that much lock-in.

For secrets, I personally use Github for that and you can add them in as a build step. Google also offers this: https://cloud.google.com/functions/docs/configuring/secrets

For logging, I just use Google's logging layer. If I was to migrate somewhere else, I'd just use that logging layer.

For releases, I just used github releases as part of my build step. But google also has the concept of releases... https://cloud.google.com/functions/docs/deploy

and on and on...

None of these are major lock-in problems though... any other PaaS platform you want to go to will need those sorts of things too.

[jusrhee]

Cloud providers (particularly the hyperscalers) are ultimately bundles of multiple services. Given that the hyperscalers do almost everything, you could extend this point in a variety of ways: why do companies already on AWS bother to use MongoDB, Snowflake, or even GitHub when DynamoDB, Redshift, and CodeCommit exist?

The answer tends to boil down to a combination of developer experience, performance, and pricing. Fwiw the actual platform offerings on GCP are also more intuitive than the equivalent services on AWS + Azure where most businesses/startups are hosting services

Edit: cloud vendor lock-in is also a very real phenomenon regardless of how much it just "looks like" all cloud providers should be easily interchangeable. Needless to say, the incentives when you make money selling compute are to keep people on your stuff

[redwood]

Totally; the ability to migrate seamlessly between cloud providers is compelling to many

[verdverm]

Migrations between clouds are a rare thing, seamlessly is an impossibility, just too many nuances if you've done it before

[dangoodmanUT]

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

[mickael-kerjean]

The ftp guy is the spark that inspire me to work on a storage independant web ui as I was trying to understand what in the actual FTP protocol was missing to make it happen. Turns out, it works and file manager are great abstraction to a lot more things than FTP alone and that oss project has been used by a couple millions people around the world (https://github.com/mickael-kerjean/filestash). If the FTP guy ever see this, I owe you a couple beers!

[meiraleal]

That's definitely not the same situation. Porter's advantage would be pricing but GCP, AWS and Azure give away thousands of USD for startups to start so it's even cheaper than Porter to start.

[sungrokshim]

For startups with credits, we offer this deal so you can pair up Porter with your cloud credits: https://porter.run/for-seed-stage-startups.

We also offer a feature called one-click SOC2 compliance that configures your AWS account to pass controls on platforms like Vanta/Drata in a single click, which many startups find useful.

[dilyevsky]

Not everyone gets those credits. If you’re not vc-backed or ai it used to be harder to get decent credits. Also the credits expire after 1-2 years and then what?

[latchkey]

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?

[benatkin]

It looks like Preview Environments could be a part of it. It seems costly though. It says they get a copy of the database. I don’t know if they pass the costs on to the customers and if the customers have to avoid pushing code too often without excluding it from the build (by adding something like “no ci” to the commit message).

[danpalmer]

I love GCP (did a migration to it at my last place), but I think like all cloud providers, it's a lot more "some assembly required" than Porter looks like, or like Heroku used to be back in the day.

To my knowledge GCP doesn't have a git-push deployment. Cloud Run might be the closest thing if you do a Docker push, but that is just one part, then you need a database, still need CI/CD, etc.

It's close. And while I like the look of Porter, I probably wouldn't bother and would jump straight to GCP, but I do think there are usability differences.

[sungrokshim]

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 designed to be a competitor to these services that is 1) more flexible 2) cloud-agnostic 3) more cost-effective. Many of our users come from Cloud Run because they need to customize networking settings (timeouts, websockets, etc.) or autoscaling behavior, not to mention the rather expensive cost (taking as an example a machine with 2 vCPU and 4GB RAM, Cloud Run is around 3~4x the cost of what equivalent compute would cost as a VM).

[latchkey]

That is why I said Cloud Functions instead of Run.

[baridbelmedar]

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.

[latchkey]

> To my knowledge GCP doesn't have a git-push deployment.

https://cloud.google.com/source-repositories/docs/deploy-clo...

It also has the ability to deploy cloud functions directly from github actions, which is super easy to set up and works really well...

https://github.com/google-github-actions/deploy-cloud-functi...

> I probably wouldn't bother and would jump straight to GCP

This is exactly my point. Just do that.

[dilyevsky]

Pretty hilarious that link you posted has a big red banner announcing product EOS but yeah just use proprietary GCP APIs why don't ya

[latchkey]

Good catch! Yea, I responded quickly and didn't note that that was Googles private repo thingy that they EOS'd.

Just use the second link. Works fine with github.

[zackify]

I agree, people act like these big providers are so difficult. Almost all of them offer some form of container deployments that takes 30 minutes to setup a GitHub action workflow for, and as long as you keep using open source stuff, like postgres on cloudsql, you are never locked in