Google Cloud Functions or AWS Lambda - Help me decide
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:
Google provides Cloud Function event hooks for:
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.
By 
