Serverless Platform Comparison: Google Cloud Function vs. AWS Lambda

Can Tepakidareekul
7 min readNov 26, 2018

--

Serverless computing is a new trend in software development, it is used to build your application by deploying application’s functions separately. It reduces lots of steps in designing software architecture and deploying the application.

Although, you know you can take lots of advantages from the serverless computing but there is one more question that you have to answer yourself before starting to use this technology. The question is which provider you should use their service.

Google Cloud has Google Cloud Function and Amazon Web Service has AWS Lambda. So, which one is the best? Let’s find the answer in this article.

In this article, we are going to share about what we did to compare the serverless platform on both providers by comparing functionalities of them which include supported language, ease of deployment, availability, scalability, network performance & stability, CPU throughput, memory management, and pricing.

Supported Language

Programming language is very diverse. Many languages are used in API service development. To compare this functionality, we listed the supported languages on both providers.

Supported languages on AWS Lambda
Supported languages on Google Cloud Function

We found that there are several supported languages on AWS Lambda while there is only one version of Node.js which fully supported and there are the beta versions of Node.js and Python on Google Cloud Function. So, AWS Lambda is better than Google Cloud Function, if the variety of supported language is concerned.

Ease of deployment

Ease of deployment is one of the most important functionalities because easy deployment means how fast you can deliver the product to your users.

In this part, we did an experiment by comparing the number of deployment steps which used to deploy a basic function on AWS Lambda and Google Cloud Function from the first step to the last.

List of step comparison

From the table above, there are a lot of steps on AWS Lambda while Google Cloud Function has only one step to deploy the function. It is because AWS Lambda provides many options which the users can config their function.

Moreover, we counted the time on both providers use to deploy the functions and update the functions.

Deployment time comparison

Although, Google Cloud Function has fewer steps than AWS Lambda but AWS Lambda can deploy and update the function faster than Google Cloud Function can do.

Availability

We did an availability test on both AWS Lambda and Google Cloud Function by keep sending a request to the function every 5 minutes for an entire week. We created a Microsoft Azure Instance to act as a middleman.

Availability testing code (on Google Cloud Function)
Cron-job script

We found that there is no downtime in both AWS Lambda and Google Cloud Function. Maybe from there is too much gap in between test iteration, in the further experiment we should reduce the gap down to around every minute.

Some of the result

Scalability

Scalability is an ability to scale which every cloud feature should have because the main purpose of using the cloud provider is to serve every response to every request from all of the clients.

We did an experiment on this functionality by sending the specific number of request to the functions that have the same purpose at the same time on both providers. Then, we observed the result and limitation that happen on both providers.

Javascript code for testing scalability (on Google Cloud Function)

We used Apache Bench to send 1000 requests to AWS Lambda and Google Cloud Function at the same time.

Script for testing scalability

We found that there is no failed request from our test on both providers. They can response to all of our requests. So, we can say that AWS Lambda and Google Cloud Function have the efficient scalability and no one wins for this round. It is very interesting that there is no option to config about scalability. It seems like both providers are able to do an auto-scaling without any extra settings needed.

Network Performance & Stability

We compared the network performance between AWS Lambda and Google Cloud Function by finding time used until the request is responded.

Javascript code for triggering endpoint and logging
Result from network testing

The average time used of AWS Lambda is 117.16 ms and Google Cloud Function is 176.80 ms. According to the result, AWS Lambda is slightly faster and more stable.

CPU Throughput

Performance is the most concerned functionality for choosing the serverless provider because no one needs slow computing performance, right?.

CPU Throughput is the number of executions per time unit without network constraints. We did an experiment on this functionality by writing a script with a loop for counting the number of iterations and limiting the execution time to the same list of specific number when running on both providers.

Javascript code for measuring CPU throughput
CPU throughput testing result

From the result, AWS Lambda is faster than Google Cloud Function. The throughput of AWS Lambda is 1.02 million executions per second and the throughput of Google Cloud Function is around 0.9 million executions per second.

Memory Management

For this functionality, we did an experiment by try to find an actual maximum memory size that we can allocate on AWS Lambda and Google Cloud Function at the same memory capacity.

Before testing memory management, let’s have a look at the memory setting on both providers.

Memory setting on AWS Lambda
Memory setting on Google Cloud Function

As you can see, memory setting form of AWS Lambda is a slider which provides more options to the users to select their desired size between 128 MB to 3008 MB. On Google Cloud Function, memory setting form is just a dropdown selector which limits the available options to 128 MB, 256 MB, 512 MB, 1 GB, and 2 GB.

However, the input type is not an indicator to judge which one is better on memory management. So, we wrote a script to allocate memory on AWS Lambda and Google Cloud Function with 128 MB memory capacity for both providers, then maximized the number of memory size that they are able to allocate.

The result is we could allocate 6.29145 MB on AWS Lambda and 6.99999 MB on Google Cloud Function. So, Google Cloud Function wins on this round. Its memory management is better than AWS Lambda.

Pricing

There is a slight difference in pricing between AWS Lambda and Google Cloud Function. All of the information is in the tables below.

Invocation is measured from how many requested is made to the function.

Compute time is measured from the time your function receives a request to the time it complete.

Fees for compute time are variable based on the amount of memory and CPU provisioned for the function. Units used in this calculation are:

GB-Seconds : 1 GB-second is 1 second of wall-clock time with 1GB of memory provisioned

GHz-Seconds :1 GHz-second is 1 second of wall-clock time with a 1GHz CPU provisioned (Google Cloud Function Only)

The total fee = Invocation cost + Compute time cost
Compute time cost = GB-Seconds + GHz-Seconds

Free tier pricing
Real pricing

* Note: The price above is an average price based on 128 MB memory but the real price varies by the amount allocated to the function.

Conclusion

Conclusion table

To conclude, AWS lambda seems overall better than Google Cloud Function. However, choosing the right server less provider is depend on the objectives of your work. AWS Lambda works properly with the users who want flexibility and more freedom to setting their own functions. While Google Cloud Function works properly with the users who want simplicity in their work and the users who have few experience with this kind of work such as students.

** Note: The test was using Google Cloud Function on “asia-northeast1” region and AWS Lambda on “ap-northeast-1” region which are placed at Tokyo, Japan.

*** Note: This article is a part of the course named “2110498 - Cloud Computing Technologies” taught in Department of Computer Engineering, Chulalongkorn University.

Authors: Arin Trongsantipong & Manussawee Tepakidareekul

Recommended Articles

--

--