Google Cloud Functions or AWS Lambda - Help me decide

By Lee Sylvester

Features

Amazon Web Services - Lambda and Google Cloud Functions are Serverless platforms; services set to execute scripts responding to specified events, such as a HTTP request or a database update. Serverless, or “Function-as-a-Service”, can be considered an evolution of Microservices, whereby applications are broken down to their smallest executable parts but without the always on server requirement of traditional Microservices. Since there are no servers to manage, Serverless deployments scale infinitely without hassle and without costly unused resources. Serverless is also inherently fault tolerant, as when a single execution fails, it has no impact on future or concurrent executions.

Both Lambda and Cloud Functions provide event hooks into existing services, enabling scripts to execute autonomously, thereby enhancing those services with custom business logic.

Amazon Web Services provide Lambda event hooks for:

• HTTP / REST (API Gateway)
• Data stores (S3, DynamoDB)
• Data throughput and dispatching (Kinesis, FireHose, SNS, SES, SQS)
• User access control (Cognito)
• Provisioning (CloudFormation, CodeCommit, Config)
• Monitoring (CloudWatch)
• Content Delivery (CloudFront)
• Event Scheduling
• and many more...

Google provides Cloud Function event hooks for:

• HTTP Triggers
• Cloud Storage
• Cloud Pub/Sub
• Firebase (Database, Storage, Analytics and Auth)

Serverless can be considered a glue which binds the services of its provider, enhancing their capabilities and enabling advanced flexibility and usefulness. However, through the use of an underlying runtime, Serverless scripts can also invoke functionality typical of Microservices, such as image manipulation, video transcoding and other data intensive tasks.

The Google Cloud Function platform provides runtime support for NodeJS versions 6 & 8 and has Python support in beta. AWS Lambda provides runtime support for NodeJS, Python, Java, Google Go and C#.

While AWS Lambda does provide more features and flexibility over Google Cloud Functions, the greatest power of Google Cloud Functions lies within its integration with Firebase. Firebase provides reactive data messaging throughput to applications, including message storage. When combined with Google Cloud Functions, additional server level functionality can be applied to messages in a pipeline like manner, greatly increasing the capabilities of the platform.

Another important feature of Google Cloud Functions is that its HTTP triggers are native, while AWS HTTP interfaces to Lambda require use of the AWS API Gateway service. This results in smaller and simpler scripts in Google Cloud Functions when handling HTTP requests.

Performance

While Microservices may typically degrade in performance with increasing numbers of requests, the reverse is often true of Serverless. The reason for this is that Serverless providers will only maintain scripts in a ready state if they are used frequently (hot start). If their use is infrequent, then they may take longer to spin-up prior to execution (cold start).

The delay in executing Serverless scripts can be problematic for some applications. As such, factoring start-up times into your application architecture is a must when using Serverless and the provider you choose may be important.

Cold start times are dependent on the scripting language used, the size of the function to execute, the number of executions already in progress and the period of time elapsed since the last execution. Both platforms typically experience an average delay of around a quarter of a second for warm starts, while cold starts may be as much as ten seconds or more. However, the pattern in which cold starts affect functions does differ between platforms, whereby AWS Lambda appears to have a larger delay at smaller load, while Google Cloud functions initially run more quickly, but tapering at higher load.

Average number of requests per second under incremental load for 5 minutes

The size of your project may also be a factor. AWS Lambda supports unlimited functions per project and will allow 1000 executions per account for each region. Google Cloud Functions, on the other hand, provide a cap of 1000 functions per project, with a maximum of 400 executions. However, with regard to execution time, AWS Lambda will timeout after five minutes, while Google Cloud Functions may execute for up to nine minutes, which may be more important for long running processes, such as video composition and transcoding.

Average response time under incremental load for 5 minutes

Google Cloud Functions is still technically in beta, so its performance may, and probably will, improve over time. As it stands, however, AWS Lambda is potentially more capable with high request rates over Google Cloud Functions.

Testing

Testing your Serverless scripts remotely can be both frustrating and time consuming. Deploying your scripts after making changes takes time and your scripts are not immediately available when uploaded, with both AWS Lambda and Google Cloud Functions taking around two minutes to fully deploy. Thankfully, both platforms provide command-line tools to assist in developing and testing your applications, locally.

AWS provides the SAM CLI; a development tool that makes it easier to create, develop, test and analyze Lambda functions. SAM is an abbreviation of Serverless Application Model. Ironically built in Google Go, the SAM CLI uses SAM templates to identify the content producers and consumers of your functions elsewhere in the AWS eco-system. SAM CLI supports each of the scripting languages supported by Lambda and runs on Windows, Mac OSX and Linux operating systems.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Processes videos
Resources:
  GetInstances:
    Type: AWS::Serverless::Function
    Properties:
      Handler: videoProcessor.handler
      Timeout: 300
      Runtime: python3.6

Example SAM template

SAM CLI assumes no knowledge of your tests or testing framework, leaving you free to choose your own. It works by leveraging CloudFormation within a local Docker container and simulating the AWS environment on your own machine.

With the SAM CLI, you generate events that might occur in a live AWS environment.

$ sam local generate-event schedule > event.json

This produces a file you can customise and include in your testing environment to trigger your function.

{
    "source": "aws.events",
    "account": "123456789012",
    "version": "0",
    "time": "1970-01-01T00:00:00Z",
    "id": "cdc73f9d-aea9-11e3-9d5a-835b769c0d9c",
    "region": "us-east-1",
    "detail": {},
    "resources": [
        "arn:aws:events:us-east-1:123456789012:rule/my-schedule"
    ],
    "detail-type": "Scheduled Event"
}

Example SAM event output

Similarly, Google provides an SDK tool called gcloud. This tool provides commands to manage many of Google's Cloud Services and not just Google Cloud Functions.

With gcloud, you can deploy your functions simply;

$ gcloud beta functions deploy myGetEndpoint --trigger-http

and invoke them with sample values;

$ gcloud beta functions call --data ‘{“id":43}’ myGetEndpoint

For local development, Google provides the Cloud Functions Node.js Emulator which, like SAM CLI, establishes a local setup that mimics the deployment environment. The emulator provides commands similar to gcloud, so you only need to learn a single API.

$ functions deploy myGetEndpoint --trigger-http
$ functions call --data ‘{“id":43}’ myGetEndpoint

As Google Cloud Functions are much simpler than AWS Lambda, events are provided simply as a passed flag. The options for such events include:

• --trigger-http (HTTP endpoint)
• --trigger-bucket (Google Cloud Storage)
• --trigger-topic (Google Cloud Pub/Sub)
• --trigger-event (other events, such as Firebase)

Monitoring

Monitoring of AWS Lambda functions occur automatically using CloudWatch which maintains running totals of your functions, including:

• total function invocations
• errors
• execution duration
• throttling due to exceeding limits
• concurrent executions

To trace the event source and downstream calls from a function, AWS provides X-Ray. AWS X-Ray generates a Service Map of events and call details, along with function idle and execution times which expose the efficiency of your Lambda services within the greater application stack.

Google Cloud Functions also provides automatic monitoring of metrics, which includes:

• invocation time
• latency
• errors
• memory usage
• CPU usage

These values are then provided as detailed visual graphs in the Google Cloud dashboard.

As with AWS, Google provides an additional service called Stackdriver. With this service, developers can search detailed logs created from the executing functions and even create alerts from a simple console.error invocation within the function itself.

AWS Lambda vs Google Cloud Functions: What are the differences?

AWS Lambda and Google Cloud Functions are two popular serverless computing services offered by Amazon Web Services (AWS) and Google Cloud Platform (GCP) respectively. Let's explore the key differences between them.

1. Language Support: AWS Lambda supports a wide variety of programming languages including Node.js, Python, Java, C#, Ruby, Go, and PowerShell. On the other hand, Google Cloud Functions primarily supports Node.js, but also provides beta support for other languages such as Python and Go.

2. Event Sources: AWS Lambda supports a wide range of event sources including file uploads, database changes, API calls, and message queues. Google Cloud Functions, on the other hand, focuses primarily on HTTP requests as the event source. While Google Cloud Functions can be triggered by other GCP services, such as Pub/Sub or Firestore, the event source options are more limited compared to AWS Lambda.

3. Execution Time and Scaling: AWS Lambda allows functions to run for a maximum duration of 15 minutes. In contrast, Google Cloud Functions imposes a maximum timeout of 9 minutes. Apart from the timeout, both services scale automatically based on incoming requests. However, AWS Lambda provides more granular control over the scaling behavior through configuration options such as concurrency settings and provisioned concurrency.

4. Integration with Cloud Ecosystem: AWS Lambda is deeply integrated with other AWS services, providing seamless interaction with AWS API Gateway, S3, DynamoDB, and more. Google Cloud Functions, on the other hand, is closely integrated with GCP services like Cloud Storage, Firestore, Pub/Sub, and Cloud Scheduler. The choice between AWS Lambda and Google Cloud Functions might depend on the specific use case and the cloud ecosystem the application relies on.

5. Pricing Model: AWS Lambda follows a pricing model based on the number of requests and compute time consumed. Google Cloud Functions also follows a similar model, but includes free monthly usage limits and different pricing tiers that vary based on the region. It's important to consider the pricing structure of both services and estimate costs based on expected usage and function execution times.

6. Developer Tooling and Ecosystem: AWS Lambda has a mature ecosystem with a wide range of developer tooling and community support. It provides a robust set of development tools such as AWS SAM (Serverless Application Model) and CI/CD integration with services like AWS CodePipeline. Google Cloud Functions also offers developer-friendly tooling and integrations with services like Cloud Build and Cloud Source Repositories, but the overall ecosystem and tooling might not be as extensive as AWS Lambda.

In summary, AWS Lambda is a serverless computing service that allows users to run code in response to events without provisioning or managing servers, while Google Cloud Functions is a serverless execution environment for building and connecting cloud services, providing seamless scaling and automatic provisioning.