The notion of serverless computing has acquired a lot of momentum in the cloud services with the launch of AWS Lambda in 2015. GCP experts insist that GCP was way ahead of its time with App Engine in 2008, which was essentially also serverless.

The disputes over whether or not to utilise serverless architecture and which cloud provider to leverage for serverless are many and largely dependent on the use case.

However, one thing that is unanimously agreed with, by cloud experts, is that serverless is the best way for swift onboarding on the cloud. And, there’s nothing more intuitive and easier than GCP’s cloud functions, from personal experience, to get started with building great weekend projects and MVPs.

Here’s my shot at serving you serverless, on a platter. :)

So what again, is serverless?

It is essentially that, run code without provisioning servers.

What does that mean?

• No need to setup any virtual machines (like EC2 or Compute Engine). Servers are there behind the scenes, but the cloud platform takes care of it
• Servers automatically start and stop when needed
• The charges are based on the number of times the functions are invoked. Just pay for the services you call
• Serverless app scales automatically according to the traffic
• GCP Cloud Functions offers multilingual support, they can be written in Node.js, Python, Go, Java, .NET, Ruby, and PHP programming languages, and are executed in language-specific runtimes

And why serverless?

Provisioning servers can be a pain, especially when all you want to do is run a simple function in the cloud.

Configuring and provisioning servers makes sense if we’re deploying a full application to cloud, but it’s a lot of labour if we’re simply running a simple function on the cloud. Even deploying an app to one compute engine requires a lot of work.

Having said that, let’s be clear about why serverless isn’t always the best solution.

Limitations of Serverless

• Not for long running processes: Cloud functions have a timeout of 9 min and Lambda,15 min, which is the amount of time the cloud functions/Lambda allows a function to run
• May affect performance: They have cold starts(overhead in function invocation), which implies that it takes time for it to provision and start the server, copy code and run the function.
• Application size limitation: 100MB (compressed) and 500MB (uncompressed) for sources
• Debugging might be difficult as no visibility into other backend processes

What is GCP? Why should you start with GCP?

Google Cloud Platform(GCP) is a cloud platform service provider, like AWS.

• GCP is more beginner friendly, and more developer friendly.
• Lot less time to get onboarded, more intuitive.
• Also it has a lot of support for Go.
• GCP services are all quite simple albeit a little less configurable

Google Cloud Functions-Functions that run on the cloud

• With Cloud Functions you write simple, single-purpose functions that respond to cloud events without the need to manage a server or a runtime environment. Your code executes in a fully managed environment.
• Cloud Function will only bill you for the resources consumed during the function’s execution. Cloud functions are often used to do activities that are triggered by an event. Also, it can trigger other services.

Types of cloud functions based on trigger

1. HTTP functions Invoke HTTP functions from standard HTTP requests.
2. Event driven functions These are indirectly invoked via an event that triggers the function such as messages on a Pub/Sub topic, or changes in a Cloud Storage bucket.

Use cases of cloud functions

The most common use cases of Cloud functions are:

• Processing file uploads: Analyse/compress any file uploaded by user before saving it
• On-demand Video analysis: Use GCP’s ML APIs to analyze the video content uploaded by the user

Structuring your Go code for cloud functions

Cloud Functions defines its own package main to import and run your function. In order for Cloud Functions to find your function’s definition, each runtime has structuring requirements for your source code. For Golang,

• Function should be at the root of the directory. It should not be in package main.
• If packages are imported, then go.mod needs to be in the directory
• Can have sub packages within the directory
• Your source code must contain an entry point function that has been correctly specified in your deployment, either via Cloud Console or Cloud SDK

.
├── function.go
├── go.mod
└── shared/
    └── shared.go

For all troubleshooting, refer cloud.google.com/functions/docs/troubleshoo..

Get started with GCP- Prerequisites

• Create a Google Cloud Platform account and provide your payment details.
• GCP services are free for the first 90 days; after that, unless you expressly request it, your credit/debit card will not be charged. GCP is free to try for three months; thus, provide payment details and billing will be generated
• To get started, log into your Google account and navigate to the GCP platform. Make a project, choose it, and turn on billing for it.
• Enable the gcloud functions api and the gcloud build api, which are used to create and deploy applications to the cloud.

Getting started with the Inline templated function

• Go to Cloud Functions and click on Create Function
• Give a function name and select a region, set trigger as HTTP and select allow unauthenticated invocations
• Select the runtime of your choice, select Inline Editor and Click on deploy. If it asks you to enable the cloud deploy api, go ahead and enable it. (If the deployment did not work, then enable cloud deploy and go to edit in cloud functions and try again)
• After deployment, select the function, we can see metrics, source, trigger, logs, test. Go to the trigger tab and try hitting the trigger url, it should give an unauthorised error
• Select the function on the console, go to permissions, add allUsers as new member and trigger the url again. It should say hello world! Congrats! You’ve just deployed your first serverless function on GCP!

Cloud Inline functions with authorization

You can use the Compute metadata server to fetch ID tokens with a specific audience(your function’s trigger url in this case) as follows:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=<trigger-url>" \
-H "Metadata-Flavor: Google"

Now add this token id in bearer auth header for GET curl request for trigger-url from postman. :)

Cloud Functions from the Gcloud CLI

• Run functions from local machine by using the gcloud command line tool.
• Download and extract google-cloud-sdk-347.0.0-darwin-x86_64.tar.gz.
• Run the script (from the root of the folder you extracted in the last step) using this command:

./google-cloud-sdk/install.sh
./google-cloud-sdk/bin/gcloud init
gcloud components update
gcloud init

In your browser, log in to your Google user account when prompted and click Allow to grant permission to access Google Cloud resources. Select region and project and you’re good to go!

Get started with gcloud CLI local

• Create a Go project (eg on Goland) and create a functions directory
• Your source code must contain an entry point function that has been correctly specified in your deployment, either via Cloud Console or Cloud SDK Just a simple function with this structure:

func SimpleHelloWorldFunction(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(200)
    w.Write([]byte("Hello World!"))
}

• Don’t define a main function in the same directory as the function
• In the functions directory, in the terminal

Go mod init <module name optional>
go mod tidy
go get all

Run your function cd to your functions directory from the terminal

gcloud functions deploy <function name> \
--runtime go113 --trigger-http --allow-unauthenticated

Hit enter and after 2 minutes, voilà! See the logs and hit the trigger url once deployed.

Cloud Functions called from CLI with Authorization

• If you are working from your local machine, make sure you have downloaded the service account key (and added cloud functions invoker as permission) and set your GOOGLE_APPLICATION_CREDENTIALS environment variable.
• Provide authentication credentials in your request as a Google-generated ID token stored in an Authorization header. For example, you might get a token via gcloud as follows:

curl https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME \
-H "Authorization: bearer $(gcloud auth print-identity-token)"

Congrats! You now have got the basics of deploying your app with cloud functions on inline cloud functions and through gcloud CLI on your local machine with and without authentication.

Here’s to you for making it till the end of this article! Stay tuned for the next article on how to make serverless bots!