DEV Community

Cover image for Is Serverless really as cheap as everyone claims?
Burke Holland for Microsoft Azure

Posted on • Updated on

Is Serverless really as cheap as everyone claims?

This article is part of #ServerlessSeptember. You'll find other helpful articles, detailed tutorials, and videos in this all-things-Serverless content collection. New articles are published every day — that's right, every day — from community members and cloud advocates in the month of September. Find out more about how Microsoft Azure enables your Serverless functions at https://docs.microsoft.com/azure/azure-functions/.

Summary: Unless you are operating at massive scale, Serverless is not just cheap, it's a steal. You should get started today.

One of the most compelling reasons people often give for using Serverless, is cost.

In a Serverless app, you only pay when the app is running. Which sounds awesome! Why pay for an app that's up all the time if you can get away with only paying for it while it's busy?

I mean, you don't just leave the water running at your house. You turn it on when you need it and off when you don't. Unless you're my kids. Then you wash your hands and just leave the water running because you have a 3 second attention span and LET'S GO PLAY MINECRAFT!

Running faucet

Serverless sounds like a steal. Like get on this deal before someone realizes what's happening and changes the rules. But how cheap is Serverless really?

I mean, come on; what's the catch.

Breaking down the cost of Azure Functions

When you look at the cost of Serverless, it definitely appears to be dirt cheap. Like, how-can-anyone-make-any-money-off-of-this cheap. For instance, Azure Functions consumption plan charges you (monthly) for three things:

  • Executions
  • Execution Time
  • Storage

Executions are pretty easy to understand: how many times did your Function execute? You get charged 20 cents per million executions. Which, wow. That seems like it's basically free. On top of that, you get the first million executions free every month.

To put that in perspective, your Function could run 32,258 time per day and it would cost you ZILCH. That's 22 times per minute. If you executed your function every second of every day that's 2.628e+6 times - or 2,628,000 times. THAT'S NOT EVEN 40 CENTS.

But executions are not the only thing you get charged for. You also get charged for Execution Time.

Execution Time is a bit harder to quantify in your head. It's basically a charge for how much resources your Function uses while it's executing, and for how long it uses it. This is called GB-s. Or, "gigabyte Seconds".

Here's how it works: Whenever your Function executes, Azure calculates how much memory it is using rounded up to the nearest 128MB. So if your Function only uses 25MB of memory, it counts as 128. It also calculates how long it ran, rounded up to the nearest 100 milliseconds.

So if you have a dead simple "Hello World" Serverless Function, that's going to count for 128MB of memory every time it runs, or, .125 gigabtyes. To get to the execution cost, you take the total number of executions, and multiply it by how long it took the function to execute. For "Hello World", this is going to be 100ms, because that's the least amount it can ever be.

Now assume that you run that function every second of every day. We've already said that's 2,628,000 times. You take that number and you multiple it by the number of milliseconds that it took the Function to run (100ms).

2,628,000 * .100
Enter fullscreen mode Exit fullscreen mode

That gives us 262,280. We now have to take this number and multiply it by how much memory the Function used each time it ran, which we already said was .125.

262,800 * .125
Enter fullscreen mode Exit fullscreen mode

This equals 32,850. OK, so the total Execution Time is 32,850 GB-s. How much does that cost us?

Nothing. Because you get the first 400K GB-s for free.

Alright. OK. So all those executions cost us 40 cents, and the execution time costs us nothing. This seems like a complete win-win. Who put this business model together?

Storage is how much storage your code uses up. Behind the scenes, Azure uses an Azure Storage account to put your code, any trigger logic and any queues you might be writing to.

If you are storing just your code, that's basically nothing. Azure Storage costs don't even begin to kick in until you've hit the first gigabyte. If you being to store lots and lots of data in queues, it could start to go up, but even then, you'd need to be using lots of it. Just keep in mind that storage is not free, but it almost is.

At this scale, Serverless is almost paying us to use it. But what happens when we scale up? Like way up?

Facebook scale

Let's assume for a minute that we're dealing with traffic that's Facebook-sized. That's a hard number to pin down, but Facebook reports that every second, 510K comments are posted, 293K status updates are made and 136K photos are uploaded. That's not even close to being all the traffic, but if we take just those 3 things, that's 939K executions per second.

How many executions a month is that?

939,000 * 60 (seconds in a minute) * 60 (minutes in an hour) * 24 (hours in a day) * 30 (days in a month)
Enter fullscreen mode Exit fullscreen mode

Which gives us 2.43389e12. I don't even now how to say that number. At 20 cents per million executions (with the first million free)...

(2.43389e12 - 1,000,000 free executions ) / 1,000,000 ) * .20 cents per execution
Enter fullscreen mode Exit fullscreen mode

Ready for it? $486,777.40. Don't forget the forty cents.

That's just execution cost. Now let's add in Execution Time.

To do that, we need to know how long do these operations take. Posting a comment might take less than a second, but uploading a photo might take several seconds. Let's just use 1 second as a nice, round, arbitrary number for all 939K executions. To figure out how many executions this is per month..

2.43389e12 * 1
Enter fullscreen mode Exit fullscreen mode

You can probably do that in your head. I almost could.

Now how much memory do these operations consume? It depends on how much code is being loaded up into memory on the server. This is hard to know, but let's just leave it at 128MB. That seems like a large number. I feel like you could load a hefty Function at that size.

So our final equation is...

2.43389e12 * .125
Enter fullscreen mode Exit fullscreen mode

This gives us 3.04236e11 GB-s. We get the first 400K GB-s for free. After that it's 0.000016/GB-s.

(3.04236e11 - 400,000 free GB-s) * 0.000016 per GB-s
Enter fullscreen mode Exit fullscreen mode

That gives us $4,867,769.60 in Execution Time cost. So the total bill is...

486,777.40 execution cost + 4,867,769.60 execution time
Enter fullscreen mode Exit fullscreen mode

For a whopping total of $5,354,547. Per month. Every month. And we didn't even get close to what Facebook is actually doing.

So just over 5 million per month? Is that all?

No. That's not all.

All about the bandwidth

Bandwidth charges apply to everything that you do in the cloud. That includes Serverless functions. If you have your own data center, you are paying for bandwidth. If you are running it in the cloud, you are paying for bandwidth. Either way, bandwidth.

So how much is bandwidth? Azure charges for bandwidth on a sliding scale. The more you use, the cheaper it gets. You get the first 5 GB free. Then it costs 8.7 cents per GB of bandwidth for 5GB - 10TB. Then it goes down to 8.3 cents for the next 40 TB and on and on until you get over 150 TB and it drops to 5 cents per GB.

How much bandwith do you think Facebook uses? Eek. I don't think I can even do this calculation. I wouldn't even know where to start. But I can bet you it's going to be way more than that 5.3 million monthly execution cost.

This is why Facebook has their own data centers. At some point, you get so big that it makes sense that you just become your own cloud.

But you are probably not your own cloud, so back to reality. We still haven't answered the question of how expensive Serverless is or isn't for a "typical" application. Let's do that.

A typical Serverless cost

My friend and I wrote an application a while back that is used by a few folks, but overall is not a heavily used application. It's fielding around 20K request per month.

Without even looking we know that the cost of our executions is free. We're nowhere close the million mark.

Here's our cost dashboard for the last 30 days.

Serverless Cost Dashboard

We are in fact paying zilch to host and execute this application. Nothing. It is completely free.

The bandwidth charges we are incurring. This is because our Serverless application is an API, so it's sending data out of Azure. If this was a microservice that was just moving data around within the same region in Azure, our bandwidth cost would be zero too. That's where Serverless is really an amazing deal.

The real deal

So is the cost of Serverless over-hyped?

No. It's for real. Until you reach a sizeable scale, you'll pay very little if anything at all. Serverless is one of the most remarkable technologies to come your way in quite some time. Couple that with the automatic infinite scaling and the fact that you don't even have to deal with a runtime anymore, and this one is a no-brainer.

Top comments (41)

Collapse
 
kendru profile image
Andrew Meredith

I had one project that I moved to Google Cloud Functions, and I now pay nothing to run it most months... I also have another project that I worked on that started on Cloud Functions and later moved to a Kubernetes cluster because it was $10k less per month. It was all a matter of scale.

Collapse
 
burkeholland profile image
Burke Holland

Perfect example of "right tool right job". I love it.

Collapse
 
tehmas profile image
Asad Raheem

Thanks for such a detailed article.

  • On the consumption plan, we also need to take account of the cold start. Is that time also included in the execution time? Doesn't it hinder the experience of the user?
  • Can we adopt a multi/poly cloud strategy when it comes to serverless?
Collapse
 
burkeholland profile image
Burke Holland
  • No. Azure Functions does not charge for startup time.
  • Funny you should ask this. I do happen to know of something coming quite soon that does exactly this. I've pinged those folks. Perhaps they'll drop in here and give us some news.
Collapse
 
tehmas profile image
Asad Raheem • Edited

Excited about the upcoming thing. Thanks for pinging them.

It would be super awesome if you can do a similar article on Azure Serverless Databases in the future. Dynamic scaling while being charged only when databases are being used seems to be really interesting.

Collapse
 
mistahcummings profile image
Chris Cummings

Wow. I am blown away. This sounds much more appealing than a home rolled simple kubernetes config running on a manged kubernetes cluster. Don't get me wrong managed kubernetes is incredible but I would love to bail on the complexity where I can.

Collapse
 
burkeholland profile image
Burke Holland

Totally agree. I think that at some point the complexity is necessary because of the direct correlation with flexibility.

Collapse
 
alexjpawlak profile image
Alex Pawlak

For my little functions, Storage costs and files for consumption plan were the most expensive. Each time a function starts it does an intensive read on file share, causing charge as there is no free tier in storage accounts unfortunately.

Collapse
 
allanjeremy profile image
Allan N Jeremy • Edited

The personality that went into this!! Couldn't stop reading

You turn it on when you need it and off when you don't. Unless you're my kids.

😂 this cracked me up

Loved it!
Quick question, from a learning curve standpoint, how do you think it would be like migrating from GCP? Also, from a totally naïve point of view, what would be the best azure learning resources in your opinion

PS. You should definitely make videos on these

If you've got a channel by all means shoot. You've got a new sub

Collapse
 
burkeholland profile image
Burke Holland • Edited

Hey! This is great feedback!

My colleague @jeremy Likness did some videos on coming from AWS. Could you take a look and let us know if this pattern/format would be good for GCP? I think we can make that happen.

blog.jeremylikness.com/blog/moving...

Collapse
 
allanjeremy profile image
Allan N Jeremy

Hey Burke!

I have checked it out and it definitely is a format that would do.

Even better would be the same format with direct or close to direct translations of "this is how you do it in gcp" vis a vis "this is how it works in azure)

Similarly to how @jeremy did it, having multiple sections on the various technologies would be great. For example "cloud functions" to "azure equivalent", "app engine" to "azure equivalent"

In that sense, that approach is perfect for people looking to migrate

I just joined a company planning on using azure and would definitely appreciate such a resource

Cheers!

Collapse
 
kamalhm profile image
Kamal

I see, so serverless to start, serverfull (if that's a term) at large

Collapse
 
jkhaui profile image
Jordy Lee

Serverful when you reach Facebook-scale

Collapse
 
planetadventure profile image
planetadventure • Edited

That statement translates to "Probably never" !! how many platforms (of any kind) exist that have billions of users? half a dozen, if that? followed by some in the hundreds of millions followed by many more in the hundreds of thousands (which is a happy place to be for a startup) - if a platform reaches the heights of likes of fb and others, lets be honest, building their own cloud platform is going to be the least of their worries.

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
planetadventure profile image
planetadventure

It sounds like an example of an overprovisioned solution, but what do I care? it's your company's money, not mine.

Collapse
 
shaijut profile image
Shaiju T

Nice 😄, In Paas like App Service, no mater your app is used or not you have to pay for hosting. But In Server less the hosting is free and we pay only for consuming the Azure functions. So how can cloud providers provide free hosting for server less ? What they will do if all businesses go server less ? Then How can they make profit ?

Collapse
 
mikhailshilkov profile image
Mikhail Shilkov • Edited

2,628,000 * .100 is 262,800, not 26k, you lost a zero here.
As a rule of thumb, pay-per-GBs is always more expensive than per-per-executions.
By the way, "gigabyte-per-second" doesn't sound correct to me. It's gigabytes multiplied by seconds, the same as the energy consumption is kW*h.

Collapse
 
burkeholland profile image
Burke Holland

Good catch on both fronts!

It's not "Gigabytes per second", it's "Gigabyte seconds".

I'll update the post.

Collapse
 
maxkatz profile image
Max Katz

Hey Burke - interesting article, thanks for posting! I think in addition to serverless function cost, you also have to take into account database access/storage. Your function will most likely access other resources such as a data store and other APIs. Agree that for small to medium scale applications - serverless can be a good fit.

Collapse
 
guyinpv profile image
Zack

I understand the idea about functions being called, but those functions have to be called from somewhere, like the frontend of whatever the app is? Where is THAT hosted? If you have a frontend app, handling a million people a month, and the app mostly makes use of the functions, well you still need the app hosted somewhere that can handle a million hits a month right? Or am I missing something?
Can the entire app, frontend, routing, logic, database, basically the entire architecture of the app, ALL be serverless functions?

Collapse
 
james231 profile image
James231

More modern architectures tend to have a static frontend app which interacts with the API (see JAMStack architecture). The static site is just files (html, css, js) file that need to be served with no computation. For this you can use static hosting services, which are actually very cheap. For example, GitHub Pages will host your static frontends for free handling millions of hits a month (similarily GitLab Pages, and Netlify).

(I know it's been a while since the question was asked, but hopefully someone will find this useful)