AWS, Azure, Vercel, Netlify, or Firebase?

You've read the getting started of serverless, you know the pros and cons, and decided to use serverless in your next project.

Now what?

There's a bunch of providers with different features, different pricing, different developer experience, different focus ... how do you choose?

Having tried many of those providers myself (AWS, Netlify, Vercel, Firebase), here's how I think about it 👇

AWS

AWS is the serverless workhorse. They offer everything from function-as-a-service to hosted blockchain and machine learning products.

Many other hosting providers use AWS. Heroku runs their dynos on EC2 instances, Netlify and Vercel use S3 for static files, Lambda for cloud functions, etc. The exact details are a secret, but we can guess.

Did you know AWS was more than half of Amazon's revenue in 2019? It's a beast.

With over 165 services, it's impossible to try or even know all of AWS. A few that I've used are:

• EC2 – old school cloud. You get a virtual computer, set it up, and you're in control. Runs forever unless you make it stop.
• S3 – the standard solution for static files. Upload a file, get a URL, file stays there forever. Used for image and video assets, but can't run server code or host a website.
• CloudFront – a CDN that integrates with S3. Point to static files via CloudFront and they go to a server nearest to your users. Works like a read-through cache, makes your apps faster.
• IAM – identity and account management. AWS forces you to use this to manage permissions. It's secure, tedious to set up, and a thorn in your butt. Until it saves your butt.
• AWS Secrets Manager – a secure way to use secrets in your serverless apps. Not in code, not in environment variables, but a secure encrypted storage.
• Lambda – the poster child for serverless. One of the first to popularize function-as-a-service architectures. Write your function, Lambda handles the rest.
• SQS – simple queue service is a simple way to implement queues. It's best used for communication between services. Stores and retries messages if necessary.
• SNS – simple notification service. Similar to SQS but designed for broadcasting. Many listeners can read each message and every message is delivered just once.
• DynamoDB – a hosted JSON document storage. One of the quickest-to-setup ways to persist data in a serverless application. Save a JSON blob and read it later. Not recommended for relational data models.
• RDS – relational database service. Set up a Postgres or MySQL database and AWS handles the rest. Better fit for traditional data with lots of relations.
• CloudWatch – a logging system. Every service in AWS connects to CloudWatch to dump logs and other debug data. You can use it to trigger lambdas on a schedule.

AWS services add up fast. Every tool does one job. No tool does your job.

When to choose AWS

I use AWS when I want control over the developer experience and how the system fits together.

For example: I'd use AWS when my project involves data pipelines, coordinating between users, and complex backend logic. You know it's backend logic because it impacts multiple users on different devices.

When not to choose AWS

Where AWS becomes overkill are typical JAMstack apps. A static site with lots of frontend logic.

Hosting those on AWS is a pain whereas Netlify and Vercel make them a core feature.

Azure

Azure ... exists. Microsoft's answer to AWS and it's hard to find people in the wild who use it.

Popular in the enterprise world with companies that can't or won't use Amazon services. I would stay away unless there's a good reason.

Firebase