To deploy for real, the fact service needs to connect to the Cloud SQL PostgreSQL database. There are several options for connecting to a Cloud SQL database from Cloud Run. In this case, as you are using the Spring Cloud GCP starter for Cloud SQL to connect to a Cloud SQL database using the Cloud SQL Proxy, as shown in Figure 7-3.
Figure 7-3. Cloud SQL Proxy
The Cloud SQL Proxy is a binary that normally runs as a sidecar container to the main application container. This is a proxy client that creates a connection via a secure tunnel to a corresponding proxy server on the machine the Cloud SQL database is running on, and then forwards the connection to the application container. If you were using Kubernetes, you could use a sidecar container to run the Cloud SQL Proxy, but as you are using Cloud Run, you need to use a different approach.
Fortunately, there is a mechanism in Cloud Run to provide the Cloud Proxy for you using the Cloud SQL Proxy as a Cloud Run service and then using the –add-cloudsql-instances option to connect to the Cloud SQL Proxy service, specifying the connection name of the Cloud SQL instance.
You can update the Cloud Run service to switch to using the Cloud SQL database by adding the –add-cloudsql-instances option and using the service account to run the Cloud Run container, so it has the correct permissions.
At this point, you also switch to passing environment variables in a file using env-vars-file and pass the secret containing the database password using –update-secrets.
This is because the service is expecting a valid token in the Authorization header. This token would normally be provided by the user’s browser when they log in to the application using a UI. However, for testing, you can use the command line to log in and retrieve the token. To do this, you need the API key from Identity Platform. This API key would also be used when calling the Identity Platform API from the client application.
Go to the Identity Platform providers page in the Cloud console and click the link for APPLICATION SETUP DETAILS.
You should see that the first request takes a few seconds to return (in my case 25 seconds) but the subsequent requests are much faster (259 ms). This is because the service has been started up to serve the first request but is still running for subsequent requests.
This is known as the cold start problem and is a common issue with serverless platforms, especially when using a language like Java where startup times are relatively slow. In a language like Go, it would be less of a problem, as Go starts relatively quickly compared to Java; however, the first request would still be slower than subsequent requests.
The way to avoid this is to keep at least one instance of the service running all the time. You can do this by setting the –min-instances option to 1 to ensure that at least one instance is always running.
You can also set the –max-instances to allow the service to scale up to handle more requests. However, you don’t want it to scale to the default of 100 replicas. Remember, you only have a limited number of database connections, so you need to be careful not to scale up too much, as each instance is configured to keep five connections in its connection pool. This is one limitation of using a noncloud native database like PostgreSQL with a serverless application. It is manageable, but it is something to be aware of.
If you think of Cloud Run as a taxi, transport
on demand, this is a bit like always having a taxi waiting outside your house
ready to take you to the airport. It is more expensive, but it is much more
convenient.
In my test, the fastest response was 240 ms and the slowest 235 ms, a great improvement in consistency and below the 500 ms that you require.