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!
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
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
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)
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
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
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
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
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
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.
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)
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.
Perfect example of "right tool right job". I love it.
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.
Totally agree. I think that at some point the complexity is necessary because of the direct correlation with flexibility.
Thanks for such a detailed article.
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.
The personality that went into this!! Couldn't stop reading
😂 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
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...
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!
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.
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.
Good catch on both fronts!
It's not "Gigabytes per second", it's "Gigabyte seconds".
I'll update the post.
Nice 😄, In
PaaslikeApp 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 theAzure 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 ?I see, so serverless to start, serverfull (if that's a term) at large
Serverful when you reach Facebook-scale
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.
It sounds like an example of an overprovisioned solution, but what do I care? it's your company's money, not mine.
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?
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)
Great article, especially love the figure calculations! It is indeed a great technology when used for the right reasons.
Crunching Facebook's numbers is fun. I would like to see their actual monthly operating run rate. 😲
xDDD
I completely agree regarding the scale, with one addendum: there is a second range, where you outgrow a dedicated server. You either have to deal with the new complexity of load-balancing and making the application ready to be distributed, or go with a serverless system again, which largely cuts down on costs for operation now (covering failover scenarios, even outside business hours etc.).
This is a fascinating perspective. So you can outgrow Serverless, but then outgrow a dedicated server and come back to Serverless? I never even considered this. I suppose the distributed needs are the driver from coming back from dedicated?
Isn't that more about booking a reserved, dedicated capacity and scale out when and if needed?
The key thing that often people miss when talking about cost of serverless is the use case. Sometimes its just not the right tool for the job. In those cases, usually, its just more expensive than running a server. Just like in your example with FB.
What prevent me to use it is you cannot cap the cost, there are so many horrors stories on that :)
You can cap your spending - at least in Azure...
docs.microsoft.com/azure/billing/b...
Now that does take your resources offline when you hit your spending cap. The other option is to use something like the Dedicated Plan, which gives you a dedicated VM.
"The spending limit is $0 and it can’t be changed." ??? then it's useless.
I don't need to go to azure for a VM there are plentifull out there ;)
The benefit of the Dedicated Plan is that it allows you to pay for dedicated VMs, but still make use of the Functions development model. So, it's not just a VM that you can get from anywhere, it's a fixed cost Function execution environment.
docs.microsoft.com/en-us/azure/app...
ah ok thanks.
Thanks for this particularly the Facebook scale calc. I do think it's a bit odd though to emphasize that your friend paying zero and then play down that he gets billed $30. There are services where the bandwidth is free. For example the fully managed kubernetes hosting we use charges $25 a gig then limits the cpu but the bandwidth as free. It requires that we sign up for 2G minimum so that's a minimum of $50 per month but there are no hidden costs, no propriety technologies, and no lock in and it's portable to all the clouds.
Also if the service you are talking wasn't second in the market and in a price war with a competitor would it have such a large discount? How many millions is your company paying to host so many apps that don't make it past a million hits? Can you post a link to a commitment that the first free million will be free forever? If not can you provide an estimate of how much cost it would be for your friend to rewrite their app onto a competitors serverless offering?
I'm not familiar with pricing for all providers everywhere. Some do give away hosting and bandwidth free, but rest assured they are paying for it somewhere - usually they are absorbing it to attract developers. Bandwidth is an unavoidable charge in the cloud.
Here's some comparisons...