Need advice about which tool to choose?Ask the StackShare community!
AWS Lambda vs Cloud Functions for Firebase vs Google Cloud Functions: What are the differences?
< AWS Lambda and Cloud Functions for Firebase and Google Cloud Functions are serverless compute services that allow developers to run code without provisioning or managing servers. These services support multiple programming languages and automatically scale based on demand.>
Deployment Options: AWS Lambda allows deployment of functions through the AWS Management Console, AWS CLI, or SDKs, while Cloud Functions for Firebase and Google Cloud Functions offer deployment solely through the Firebase CLI or the Google Cloud Console. This difference in deployment options may impact developers' preferred workflow and tools.
Pricing Model: AWS Lambda follows a pay-per-use model where you are billed based on the number of requests and the compute time required to run your functions. In contrast, Cloud Functions for Firebase and Google Cloud Functions also adopt a pay-as-you-go model based on the number of invocations and the resources consumed, but they include a free tier that provides a certain level of usage at no cost.
Supported Integrations: AWS Lambda integrates seamlessly with other AWS services, providing a wide range of possibilities for building serverless applications within the AWS ecosystem. On the other hand, Cloud Functions for Firebase is tightly integrated with Firebase services, offering enhanced capabilities for mobile and web app development, while Google Cloud Functions offer integration with various Google Cloud services, enabling developers to leverage Google's advanced cloud offerings.
Execution Environment: AWS Lambda runs on AWS's proprietary infrastructure, while Cloud Functions for Firebase and Google Cloud Functions run on Google Cloud Platform, allowing developers to choose based on their familiarity with a particular cloud provider's ecosystem. This difference may affect networking configurations, storage options, and other cloud-specific features available to the developers.
Concurrency Limits: AWS Lambda imposes default concurrency and scalability limits per region, while Cloud Functions for Firebase and Google Cloud Functions provide automatic scaling without predefined concurrency limits. Developers using Google's cloud services may have more flexibility in managing concurrent invocations based on their requirements and usage patterns.
Monitoring and Logging: AWS Lambda offers comprehensive monitoring and logging capabilities through Amazon CloudWatch, providing detailed metrics and insights into function performance. In contrast, Cloud Functions for Firebase and Google Cloud Functions provide logging and monitoring through Stackdriver, Google's monitoring and logging solution, which may offer different metrics and visualization options for tracking function execution and diagnosing issues.
In Summary, key differences between AWS Lambda, Cloud Functions for Firebase, and Google Cloud Functions lie in deployment options, pricing models, supported integrations, execution environments, concurrency limits, and monitoring/logging solutions, catering to different developer preferences and requirements.
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.
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
Pros of AWS Lambda
- No infrastructure129
- Cheap83
- Quick70
- Stateless59
- No deploy, no server, great sleep47
- AWS Lambda went down taking many sites with it12
- Event Driven Governance6
- Extensive API6
- Auto scale and cost effective6
- Easy to deploy6
- VPC Support5
- Integrated with various AWS services3
Pros of Cloud Functions for Firebase
- Up and running4
- Multi-region1
- Affordable1
Pros of Google Cloud Functions
- Serverless Applications7
- Its not AWS5
- Simplicity4
- Free Tiers and Trainging3
- Simple config with GitLab CI/CD2
- Built-in Webhook trigger1
- Typescript Support1
- Blaze, pay as you go1
- Customer Support1
Sign up to add or upvote prosMake informed product decisions
Cons of AWS Lambda
- Cant execute ruby or go7
- Compute time limited3
- Can't execute PHP w/o significant effort1
Cons of Cloud Functions for Firebase
Cons of Google Cloud Functions
- Node.js only1
- Typescript Support0
- Blaze, pay as you go0