31–40 of 65 posts
This is a response to this AWS Lambda launch, over a year later: https://aws.amazon.com/blogs/compute/new-for-aws-lambda-pred...
Cloud Run is for containers, not functions, and it's the next evolution of App Engine. The GCP equivalent to Lambda is Cloud Functions.
AppEngine has had scale-to-zero for 15 years, but instead of having a coherent product strategy, why not just launch a different competing product every year which is missing features that already exist? AppEngine vs Cloud Functions vs Cloud Run, the reasons these all exist at the same time is not because it makes any sense for customers, but because Google PMs get promoted for launching new things rather than suppor…
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.
import ( "fmt" "log" "net/http" )
func init() { setupDBConnection(dbName) }
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:])func main() { fmt.Println("Processing your serverless request") http.HandleFunc("/", handler) log.Fatal(http.ListenAndServe(":8080", nil)) }
```
This code snippet is an example of "Run bootstrapping logic once, and reuse it across Min Instances".
Assuming the boostrapping logic refers to the `init()` function that connects to DB. Does Cloud Run looks for init() in a Golang app to invoke?
I cannot seem follow the code's logic and its connection with the stated purpose.
Did I miss anything?
``` package main import ( "fmt" "log" "net/http" ) func init() { setupDBConnection(dbName) } func handler(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:]) } func main() { fmt.Println("Processing your serverless request") http.HandleFunc("/", handler) log.Fatal(http.ListenAndServe(":8080", nil)) } ``` This code snippet is an example of "Run bootstrapping logic once, and…
The big quesation is how derived we can be of actual value creation before wheels stop spinning...
Earlier quoted context omitted.
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.
> App Engine is nothing like Cloud Functions/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 ex…
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.
So if there's something always running .... isn't the same as having on always on server (with auto scaling of some sort)?
When a container is kept warm via " min-instances" but is not receiving requests ("idle"), its CPU costs 10x less than when it's actively processing requests, see pricing: https://cloud.google.com/run/pricing
So if there's something always running .... isn't the same as having on always on server (with auto scaling of some sort)?
When a container is kept warm via " min-instances" but is not receiving requests ("idle"), its CPU costs 10x less than when it's actively processing requests, see pricing: https://cloud.google.com/run/pricing
For an app with low usage, you start getting a price that can compete with Heroku.
Earlier quoted context omitted.
When a container is kept warm via " min-instances" but is not receiving requests ("idle"), its CPU costs 10x less than when it's actively processing requests, see pricing: https://cloud.google.com/run/pricing
How is this cost saving achieved? At the risk of being reductive, surely the container is either in memory and ready to serve requests or it isn't?