AWS, Azure, Vercel, Netlify, or Firebase?

You've read the getting started of serverless, you know the pros and cons, and you're using 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. With a near infinite array of services it's been leading the charge with everything from function-as-a-service to hosted blockchain and machine learning products.

A lot of 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 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 include:

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're served from the physically nearest server 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 storage that's encrypted at rest.
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. Best used for async 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, read it later. Not recommended for relational data models.
RDS – relational database service. Set up a Postgres or MySQL database in the cloud 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 debugging 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 like to use AWS when I need control over the developer experience and how my 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, 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. Sort 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
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 is basic and a little cumbersome. It doesn't feel like a focus.

If you like interacting with your sites via the command line, I've found Netlify to be cumbersome. Their configuration files are written in TOML, which is less popular than YAML and takes getting used to.

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.

My favorite use-case for Vercel is buying domains from the command line and deploying static sites.

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
configureless deploys
git integration for automated deploys
custom URLs for every deploy
automatic CDN and SSL setup for your site
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 esthetic 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?