> and when you hit the endpoint limit on your deployment you will need to start splitting your code over multiple deployments.
Firebase allows for 1000 functions per project, all of which can be deployed at once.
If I have more than a 1000 endpoints sitting in a single folder I'll consider that I've gone a bit too micro on the idea of micro-services!
> Anything you can do with serverless can be done better with k8s
The cloud vendors work hard to make ecosystem buy-in convenient. E.g. reduced/no egress charges between their services hosting on the same cloud, and smooth integration between services.
As an example, with Google Firebase I am using their auth, database, and serverless solutions. When I needed to start storing user assets somewhere it was less than half an hour to get everything working end to end including proper security and permissions in place.
Could I have setup a VM and built out some sort of service to manage/serve assets? Sure. There is probably some open source project out there that if I spend a day or two reading up on it I could get it configured, and then get it integrated with my existing auth system.
And then I'd have one more VM to manage security updates on, and worry about deploying.
With Firebase I get test and production environments all setup for me automatically[1], with separate credentials and the works.
It isn't necessarily about scaling speed, it is also about not having to worry about infra.
I think you're confused between FaaS and Serverless. Serverless is an Amazon service, Firebase is not serverless, however both are FaaS. I'm talking specifically about AWS Serverless.
> I think you're confused between FaaS and Serverless.
I think you are confused about those.
> Serverless is an Amazon service,
No, it's not.
1. The “Serverless Application Model” is an AWS functionality (a transform for CloudFormation templates for serverless [see #3] compute.)
2. “Serverless Framework” is an open-source product that is independent of Amazon (though it originally targeted only AWS) which supports multiple cloud provider.
3. “serverless” is a broad concept for cloud computing without managing server instances, encompassing, among other things, FaaS—AWS popularized the term, but it's used generally across the industry.
Nice, thank you for the heads up.
Nonetheless, they had about 8 tables in their database when they started getting blocked by the endpoint limit on AWS Serverless, I'm guessing they were far from a thousand endpoints.
Firebase also offers DBs, storage, and even hosting. I'm confused as to why you say it isn't serverless,
AWS's "Serverless" (wow that name...) looks like a suite of existing products advertised under one label. From their splash page it looks mostly equivalent to what Firebase, although it seems Amazon has some functionality that Firebase itself doesn't have (necessitating using the full Google Cloud).
Firebase allows for 1000 functions per project, all of which can be deployed at once.
If I have more than a 1000 endpoints sitting in a single folder I'll consider that I've gone a bit too micro on the idea of micro-services!
> Anything you can do with serverless can be done better with k8s
The cloud vendors work hard to make ecosystem buy-in convenient. E.g. reduced/no egress charges between their services hosting on the same cloud, and smooth integration between services.
As an example, with Google Firebase I am using their auth, database, and serverless solutions. When I needed to start storing user assets somewhere it was less than half an hour to get everything working end to end including proper security and permissions in place.
Could I have setup a VM and built out some sort of service to manage/serve assets? Sure. There is probably some open source project out there that if I spend a day or two reading up on it I could get it configured, and then get it integrated with my existing auth system.
And then I'd have one more VM to manage security updates on, and worry about deploying.
With Firebase I get test and production environments all setup for me automatically[1], with separate credentials and the works.
It isn't necessarily about scaling speed, it is also about not having to worry about infra.