Need advice about which tool to choose?Ask the StackShare community!
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:
- 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.
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.
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.
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.
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.
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.
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.
Need advice on what platform, systems and tools to use.
Evaluating whether to start a new digital business for which we will need to build a website that handles all traffic. Website only right now. May add smartphone apps later. No desktop app will ever be added. Website to serve various countries and languages. B2B and B2C type customers. Need to handle heavy traffic, be low cost, and scale well.
We are open to either build it on AWS or on Microsoft Azure.
Apologies if I'm leaving out some info. My first post. :) Thanks in advance!
I recommend this : -Spring reactive for back end : the fact it's reactive (async) it consumes half of the resources that a sync platform needs (so less CPU -> less money). -Angular : Web Front end ; it's gives you the possibility to use PWA which is a cheap replacement for a mobile app (but more less popular). -Docker images. -Kubernetes to orchestrate all the containers. -I Use Jenkins / blueocean, ansible for my CI/CD (with Github of course) -AWS of course : u can run a K8S cluster there, make it multi AZ (availability zones) to be highly available, use a load balancer and an auto scaler and ur good to go. -You can store data by taking any managed DB or u can deploy ur own (cheap but risky).
You pay less money, but u need some technical 2 - 3 guys to make that done.
Good luck
My advice will be Front end: React Backend: Language: Java, Kotlin. Database: SQL: Postgres, MySQL, Aurora NOSQL: Mongo db. Caching: Redis. Public : Spring Webflux for async public facing operation. Admin api: Spring boot, Hibrernate, Rest API. Build Container image. Kuberenetes: AWS EKS, AWS ECS, Google GKE. Use Jenkins for CI/CD pipeline. Buddy works is good for AWS. Static content: Host on AWS S3 bucket, Use Cloudfront or Cloudflare as CDN.
Serverless Solution: Api gateway Lambda, Serveless Aurora (SQL). AWS S3 bucket.
Netlfiy Functions uses AWS Lambda under the hood, but Netlify adds some nice sugar. The biggest advantage is the local development experience with netlify-cli. This allows you to run your functions locally with local configuration or pull configs from the Netlify dashboard. I built a health-check endpoint in about 2 minutes, and my send-email function in less than an hour.
Run cloud service containers instead of cloud-native services
- Running containers means that your microservices are not "cooked" into a cloud provider's architecture.
- Moving from one cloud to the next means that you simply spin up new instances of your containers in the new cloud using that cloud's container service.
- Start redirecting your traffic to the new resources.
- Turn off the containers in the cloud you migrated from.
When adding a new feature to Checkly rearchitecting some older piece, I tend to pick Heroku for rolling it out. But not always, because sometimes I pick AWS Lambda . The short story:
- Developer Experience trumps everything.
- AWS Lambda is cheap. Up to a limit though. This impact not only your wallet.
- If you need geographic spread, AWS is lonely at the top.
Recently, I was doing a brainstorm at a startup here in Berlin on the future of their infrastructure. They were ready to move on from their initial, almost 100% Ec2 + Chef based setup. Everything was on the table. But we crossed out a lot quite quickly:
- Pure, uncut, self hosted Kubernetes — way too much complexity
- Managed Kubernetes in various flavors — still too much complexity
- Zeit — Maybe, but no Docker support
- Elastic Beanstalk — Maybe, bit old but does the job
- Heroku
- Lambda
It became clear a mix of PaaS and FaaS was the way to go. What a surprise! That is exactly what I use for Checkly! But when do you pick which model?
I chopped that question up into the following categories:
- Developer Experience / DX 🤓
- Ops Experience / OX 🐂 (?)
- Cost 💵
- Lock in 🔐
Read the full post linked below for all details