During our yearly hackathon, I had an opportunity to work with Google Cloud Functions. I was already familiar with AWS Lambdas. Since many of my clients are either in GCP or looking at it as an alternative, this was a good time to experiment. In this instance, the Functions were acting as REST endpoints for a cloud database. The Function implementations are in Java built with Gradle.
After sorting out the accounts and permissions, I deployed the first Function. I tried to use an IAM authentication to get around having a DB password in the application. Because IAM authentication would not work in the few days we had, the connection used username/password credentials. Best practices require the credentials to be in a secrets manager.
Another stumbling block encountered was library dependencies. Each Function has a backing container. By default, the containers would not have any additional dependencies. The shadow plugin fixed that problem. The resulting jar was much larger than the default. The --source=build/lib argument in the gcloud functions deploy command deploys the jar in the folder.
Google’s library for Functions provides a nice way to test the Function before deploying it. The command gradle runFunction -Prun.functionTarget=<package>.<class name> starts a local server on port 8081. With this local server, you can run Postman commands or view the results in a browser. This is great for verifying logic and connection information in your application. You will need to set the GOOGLE_APPLICATION_CREDENTIALS environment variable before running this. The credentials are the local file location for the downloaded service account json key.
A couple Functions and a common library later things, seemed to be going well. Then the application started having issues. The Functions failed with a SQLTransientConnectionException. A connection not available caused the exception. Looking at the database, the connections to our database were high. Connection management seemed to be the problem. In hindsight if I had run the Function request on my local machine multiple times, I would have found the issue. The Function needed to release the connection before exiting. After releasing the connection, the Functions worked better.
The only other glitch was 'warming up' the Function. If the endpoint is idle too long, the Function has to initialize, taking longer to respond. The console has a "Minimum instances" field. The gcloud functions deploy command does not have a way to configure the minimum instances.
In my opinion, this was a successful experiment. The Functions were able to act as simple REST services. Setting up the Functions was simple enough. As they say in academia, further research is needed.
You should do your own research.
Top comments (0)