I disagree. App Engine is nothing like Cloud Functions/Run. The former is a better fit for your entire app stack (think Heroku) while the latter is for ad-hoc.
As for Cloud Functions and Cloud Run, the way you deploy is completely different. Cloud Run is strictly meant for containers.
> As for Cloud Functions and Cloud Run, the way you deploy is completely different. Cloud Run is strictly meant for containers.
AWS Lambda (arguably the "inspiration" for Cloud Functions) just announced support for custom containers. Cloud Functions could too. And then you essentially have Cloud Run.
This isn't true. App Engine Flexible is in fact very similar to Cloud Run, and my understanding is that it runs on the same infrastructure. In fact, App Engine Flexible "Custom Runtime", which lets you load a docker container in App Engine, is very similar to Cloud Run.
FWIW, though, as a user of App Engine Flexible for Node, I'm very glad this Cloud Run option now exists.
I've switched newer projects from app engine flexible to cloud run. I do think the underlying infrastructure is slightly different but for the better. If I remember correctly, app engine was using VMs vs pure containers. Deploys to app engine took me 10 min start to finish, but cloud run is around 3.
I used to use a combination of app engine standard and flexible depending on requirements, but I feel like cloud run gives me the benefits of both.
I would be interested in something like AWS Lambda@Edge or Cloud Workers from Google. Love to run a simple script close the visitor's location e.g. from Belgium DC instead of US DC etc
That would be nice although Google CDN even without any compute is pretty slow compared to cloudflare.
Google has many data centers around the world. I don’t see why they can have cloud run automatically select the data center closest to the user and spin up the container there. That would deffo solve a lot of problems.
Actually, App Engine is a LOT like Cloud Functions/Run. You have some code that you want to run in the Cloud and you don't want to worry about server ops.
Whether that's your "whole stack" or something "ad-hoc" is a totally arbitrary distinction. Your "whole stack" will almost certainly involve external concerns, and your "ad-hoc" concerns will almost certainly grow in complexity until they converge on the same spot.
AppEngine is also running containers via gvisor.
The distinction is being driven by PMs and marketers but not by the needs of customers. What end-users need is one well-supported tool, not 8 separate tools with uncertainty about which one will receive future support and matrices and flowcharts to decide between them.
> The distinction is being driven by PMs and marketers but not by the needs of customers.
This is not true. It came directly from customer needs -- customers were looking for an effortless way to run containers without having to deal with orchestrators like k8s or be locked into frameworks like AppEngine.
I've used Cloud Run for a bunch of projects, and it's fantastic.
As for Cloud Functions and Cloud Run, the way you deploy is completely different. Cloud Run is strictly meant for containers.