AN OVERVIEW OF SERVERLESS FOR GOOGLE CLOUD PLATFORM

Introduction

The concept of serverless cloud computing is relatively new to some organizations, especially as many enterprises adopt the cloud and push forward with their cloud maturity. While it may sound like a misnomer, applications running within serverless environments do execute on a machine in the cloud, but resources are often provisioned just-in-time to meet demands, rather than running 24×7 as a traditional environment might. Like traditional cloud computing models, resources physically belong to the cloud provider and are paid for as consumed. In this article, we’ll review why you would want to pick a serverless environment over a traditional one, three offerings from Google Cloud Platform, and the pros and cons of each.

Why Choose a Serverless Option?

For specific use cases, especially short-running or low-priority processes, serverless can be an easy and economical way to run workloads, allowing developers to focus on business logic and avoid infrastructure management. Applications can be deployed and run in a matter of seconds, and developers can still use languages and frameworks they are familiar with. Further, as demand increases during certain times of the day or year, serverless options handle scaling automatically. Finally, the entire environment under the application layer is managed by the cloud provider, freeing up developers to focus on building and modifying source code rather than infrastructure maintenance.

Consider the following example – a business wishes to obtain metrics on invoices and receipts as submitted by employees. They could build a script to use Google Cloud Storage to store the image, Google Cloud Vision API to extract the data, and Google BigQuery to store text of interest. Since receipt and invoice submissions may not happen on a regular basis or may happen in large bursts (such as at the end of the month or on a Friday), using a long-running VM to run this script may not be appropriate or economically feasible. In this case, invoking a Cloud Function to tie GCS, Vision API, and BigQuery together may be a simple solution for this very specific use case.

However, there are times when a serverless option may not be appropriate for the use case. For instance, if you require specific control over the deployment environment, wish to tune scaling manually, or need to make configuration updates to the operating system layer, a traditional virtual machine may be a better fit. Let’s dive into three serverless offerings provided by Google and review use cases for each.

Cloud Functions

Google Cloud Functions allows developers to focus only on the business logic itself, without worrying about containerization, infrastructure, or certain API dependencies. This option is good for single-purpose functions that perform one task with minimal user interaction, such as a function that is fired in response to an event. In our earlier example, an event might be an image uploaded to a Cloud Storage Bucket, and the action might be the function consuming that image and doing something meaningful with it.

Cloud Functions are also useful for things like acting on other resources by using a subscription service and Google Cloud Scheduler. For example, you might wish to power off or deprovision virtual machines over a certain age automatically. A simple Python or Node.js script running in a Cloud Function could execute this for you by running every day at midnight against your Compute Engine instances.

It is worth noting that Cloud Functions may not be appropriate for longer-running or more complex tasks that require user interaction, given their quota limits. In these cases, Cloud Run or Google App Engine may be a better choice.

For more information on Cloud Functions, see: https://cloud.google.com/functions/docs/concepts/overview.

Cloud Run

Google Cloud Run allows developers to deploy scalable and containerized applications with minimal configuration. Like Google Kubernetes Engine (GKE), Cloud Run focuses on container orchestration, but strips away configuration management to allow developers to focus on business logic, like the philosophy behind Cloud Functions. Cloud Run is useful for when development teams are looking to deploy business logic via microservices for longer-running tasks, but don’t need to change scaling options, storage, memory, pods, or other configuration that is present within GKE.

Because Cloud Run is container-based, developers can use the language they prefer (if it can be used within a container) and bundle custom binaries that may be relevant to the workload. Containers within Cloud Run scale automatically, can integrate easily with other Google services, and provide longer execution time than Cloud Functions for complex tasks.

Cloud Run can be allocated to run 24/7, or only when requests are received. Depending on the use case of the workload running within Cloud Run, this can be an economical option for workloads that have infrequent or random requests, and when the workload can tolerate cold starts. If the workload is sensitive to latency or has consistent requests, configuring Cloud Run to be available 24/7 without cold starts could be a better option.

As stated before, Cloud Run is appropriate for developers who do not wish to manage infrastructure and want to focus on writing code and bundling binaries within a container for the task at hand. If more complex configuration is required, GKE or another container environment that offers additional features may be more appropriate.

For more information on Cloud Run, see: https://cloud.google.com/run/docs.

App Engine

Google App Engine is a fully managed serverless platform for a large scale, such as for web applications. Like Cloud Run, developers can focus on deploying application code without needing to configure infrastructure, if they so choose. App Engine can be a good use case for mobile backend environments by using a great integration with Firebase. Finally, App Engine is a great choice for web applications that depend on microservice architectures.

This offering from Google does allow additional configurations if required by development teams. Developers can choose from the Standard or Flexible environments within App Engine. Standard environments are useful for rapid scaling and bursts of traffic, while flexible environments are container-based, focused on consistent traffic, and have more access to resources within a GCP virtual network. One thing to keep in mind as teams experiment with App Engine is that the Standard environment has a free tier, while the flexible environment does not. Further, while Standard can scale to zero instances when no requests have been received, Flexible always has at least once instance running. Developers are locked into certain restrictions within Standard, such as no access to the lower environment and the inability to modify the runtime, while Flexible instances can write to an ephemeral disk and modify the application runtime if required.

App Engine is suited to larger web applications that perform numerous tasks and need to scale globally. If the workload is infrequently used, only performs one specific task, doesn’t require a container, or has a standard container that can be deployed to Cloud Run, App Engine may not be the best choice for the workload.

Conclusion

In this article, we have discussed three serverless options from GCP: Cloud Functions, Cloud Run, and App Engine, along with the pros and cons of each. When deciding between serverless offerings from Google, carefully review the application and workload requirements to determine the best fit, as there is a tradeoff between allowing complete focus on business logic and infrastructure configuration.

Whether you need assistance with deploying a Cloud Function, setting up a Dataflow pipeline to BigQuery for analysis, or migrating and modernizing your on-premises workloads to GCP, an experienced cloud partner can provide the competitive advantage you need to stay ahead of the curve.