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

Firebase is Google's answer to AWS. Kind of.

You can think of Firebase as a done-for-you backend for web and mobile apps. Set up an account, pick your options, and it's ready to go.

Right now there are 18 firebase services ranging from analytics to database and even machine learning. I've tried their database solution and it works great.

This is less extensive than the AWS section and that's the point. Firebase doesn't want you to think about any of this.

When to choose Firebase

You get the backend in a box with Firebase. There's little setup.

You'll have to change how you write your frontend code so it hooks up with Firebase and ... that's about it.

Great for small demos and when you don't want to think about the backend at all.

When not to choose Firebase

Like with other Magic providers, you're in trouble as soon as you step off the beaten path. Or when you have a special requirement they didn't predict.

When that happens your choice is to either change your app or rebuild from scratch.

Netlify

Netlify is wonderful. They invented everyone's favorite JAMstack buzzword.

Starting as a static site host for JavaScript-heavy applications, Netlify now offers cloud functions, authentication, and other backend functionality. Meant for simple backend tasks.

Among Netlify's biggest draws are:

a great web UI to manage your projects
git integration for automated deploys
custom URLs for every branch
automatic CDN and SSL setup for your site
app builds run on their servers
you can run their infrastructure locally
PR deploy previews
great support for teams

When to choose Netlify

Netlify is one of the best funded startups in this arena. That can be an important factor.

They've been around long enough to rely on and are young enough that you'll get decent support, if you have issues. I find that to be a great balance :)

If you like a git- and UI- first mentality, Netlify is great.

When not to choose Netlify

Netlify is almost always a great choice for your web app. Their cloud function support can be cumbersome and malnourished. It doesn't feel like a focus.

If you like interacting with your sites via the command line, I've found Netlify to be less great.

Vercel

Vercel is wonderful. Netlify's direct competitor created by Silicon Valley veterans.

Vercel's focus, however, is different than Netlify's.

Where Netlify makes static deploys painless to configure and deploy via git and their UI, Vercel tries to make any app painless to deploy via their CLI. Command-line first, git and UI second.

Vercel's cloud function support is similar to Netlify's. Meant for small functionality and help with frontend tasks.

Among Vercel's biggest draws are:

superb command line interface
configure-less deploys
git integration for automated deploys
custom URLs for every deploy
automatic CDN and SSL setup for your site
PR deploy previews
app builds run on their servers
great support for teams

When to choose Vercel

Vercel is almost always a great choice for your web app.

Honestly it's a toss up between Netlify and Vercel right now. They're both playing catch up. When one releases a new feature, the other gets it a few months later.

I like Vercel's command line interface and the fact I can run vercel in any project and it shows up on the internet. No clicking or config needed.

When not to choose Vercel

Vercel is best for frontend-heavy apps and when you're using their NextJS framework. Like Netlify, it feels unlikely their backend support will reach the full power of AWS.

Any project that fits on Netlify, fits on Vercel. Then it becomes a matter of preference and familiarity. Personally, I like Vercel's aesthetic and CLI focus. If you prefer clicking in a UI, go with Netlify.

So ... what to choose?

My preference is to put the frontend on Netlify or Vercel and the backend on AWS.

This gives me a balance between control, simplicity, and developer experience. We look at that in the next chapter.

Did you enjoy this chapter?