If you're worried that switching to serverless infrastructure is too expensive for your business, you're not alone. Total spending on cloud services will top $284 billion by 2024. The good news is there are many ways to track and lower your serverless operation costs without slowing down your business. Lambda and how can it help your business? Find out more by reading these Lambda frequently asked questions.
Amazon Web Services, or AWS, is Amazon's cloud computing division. AWS offers serverless computing with its Lambda service since 2014.
Because outsourcing computing power is still so new, it still has many tech workers asking, "What is serverless?" How could using someone else's servers be efficient or cost-effective?
Let's talk about the top reason businesses are switching to serverless infrastructure.
The best part of serverless infrastructure is that you only pay when your users are online. Your business will have as much computing power as it needs without buying new equipment when you grow. A new app can handle the same traffic as if it had a fully equipped server room.
But small businesses aren't the only ones going without servers. Let's go over how big businesses are making the change. Bustle, an online publication with over 30 million unique visitors a month, started their new brand Romper entirely on serverless architectures.
Why does that matter to you?
For starters, Bustle, a major news and entertainment website from the US, has seen its IT spending drop by 84%. A big part of that is that their maintenance crew is only about half the size a comparable website needs if they were managing their own servers.
Since your team doesn't manage servers, you don't have to pay for an operations team that AWS is providing. The cost of this maintenance is included in every AWS Lambda request you pay for.
AWS Lambda counts a request as an event notification or invocation. Even when testing your app's features from the console, these tests count as requests. Let's take a look at how much requesting data costs.
The good news is, your first million requests are free. So are the 400,000GB seconds of computing time that come with every account.
GB seconds? Yes, you pay per millisecond and memory allocation. If you run ten milliseconds with 128 MB memory, you pay less than ten milliseconds at 1024 MB memory.
All requests outside of the free tier come in at $0.20 per one million requests and $0.0000166667 per GB second after going through your free usage.
Are there other costs you should consider?
Yes, let's dig into all the other reasons that add up to your bill.
Many businesses new to serverless infrastructure are often surprised by extra fees. Let's consider how transferring data from other services on the cloud adds to your monthly requests:
If you store data on Amazon S3 and Lambda reads from it, these count as requests. EC2 data transfer rates apply when your app initiates external transfers. Using Amazon DynamoDB for reading and writing storage incurs requests. For example, you set 512 MB of memory to your function. Let's say users execute your functions 3,000,000 times in one month. What would your cost be?
$18 for 3 million invocations is a great deal!
Just $18.34 for 3 million requests. But that's a lot of data transfer. How can you keep track of everything and manage crashes?
Monitoring Lambda functions is a growing issue among serverless users. Just like it's easy to lose track of how much data you use on your phone, tracking your requests can be confusing.
Coca-cola North America has switched from EC2 to serverless a while back and was kind enough to share their experience with us. Coca-cola went from $13000 per year to $4.500 per year after switching to serverless.
Let's start with reading your dashboard. AWS has some basic tracking services built into Lambda. These services include:
A great way to forecast the future use of Lambda. You can see how much you spent last month, an estimate of this month's use, and a prediction of how much you'll use the next month.
This shows which AWS services you use most and the percentage of your budget going towards each.
It also shows the services you use most with a breakdown of their costs. These tools are fine for free tier use, but there is a better option when you have multiple Lambda functions.
This is where serverless trackers make things easy. Serverless trackers show the status of all your Lambda functions in one place. It allows you to make data-based decisions on how to interact with your customers.
These are some of the ways a tracker will visualize costs.
With Dashbird you can track the cost for any particular project, allowing you to see exactly how many dollars you are spending for AWS Lambda.
Furthermore, you can see the individual cost for each of your functions and other important information like execution time, invocations, errors, etc., under the Lambda functions view section.
Now that you know how pricing works and how to keep track of it let's talk about some other ways serverless saves you money.
No upfront cost with serverless. Without cloud computing, the only other option is to buy servers before creating a new app. This means more waiting time for an ROI on your servers.
Scaling is much cheaper. Instead of buying more servers and hoping they provide the capacity you need, you can just pay for how much you use without worrying about your system crashing.
You don't pay for maintenance!
Now being forced to hire a big DevOps team is a huge cost saver for companies. There are many examples of companies that managed to run apps with millions of people with only two developers behind the scenes. By switching their infrastructure to AWS and relying on them to handle the day-to-day maintenance operations, they could sleep at night knowing there wouldn't be a crash or outage in the middle of the night. No more sleeping with one eye open.
Speaking of crashes, serverless presents a unique problem in the form of cold starts. The first invocation of your lambda function will take some time to execute since the container needs time to spin up.
With the traditional computing methods, every request gets put in a queue and will be served one by one.
With Lambda, every request gets served at once, provided they don't run into the concurrency limit.
This in itself is probably the main reason why people get so excited over this technology. The fact that with serverless, you can serve ten, a hundred, or even a thousand people at once without breaking a sweat; your application gracefully scales to fit the needs of your users.
To create this beautiful scaling that I keep yammering about, the unused Lambda containers get destroyed after a period of time. We've gone ahead and tested the time to deletion and found out that it seems to be anywhere from forty to sixty minutes of inactivity. Now, if this wasn't clear up until now, cold starts are necessary to allow AWS to pretty much infinitely scale our Lambdas. Old containers make room for the new ones.
Not everyone will get bothered by those cold starts, but for the ones that are, there is one way to prevent this, and that's by using provisioned concurrency.
With this feature, you can tell the Lambda service it shouldn't delete all your function instances after sixty minutes but keep a specific number of them loaded. This goes a bit against the serverless philosophy of on-demand pay, but if you know exactly how your system is used, it can be a good way to improve latency.
If your app is experiencing a lot of cold starts, try increasing your memory limits. Lambda functions with higher memory allocation also get more CPU power, which can cut down cold starts quite a bit. Although it will cost more, you may be losing customers to long wait times.
It's important to know when and how often your cold starts happen, and if need be, use that knowledge to make adjustments to create a better experience for your users. I use Dashbird's function view to filter out cold starts and note how often they appear.
The most likely answer is your code isn't optimized. Sometimes 128 MB can be more expensive than 1 GB because the function runs much longer.
Lambda power tuning can help you to find the optimal memory configuration for your functions.
The size of your function in terms of source code and assets can have an impact too. Your 2 GB Docker-based Lambda function won't perform as well as a 1 MB one.
Try to build small functions without many lines of code. Find the optimal memory configuration and use caching when it makes sense.
If you use Lambda to power your APIs, you should also consider caching requests inside API Gateway, or AppSync, depending on your chosen service. After all, a function not called is the cheapest and doesn't even have cold starts.
The simple answer for many of those researching serverless is a resounding yes.
However, there still are numerous factors to consider and many facets to operational complexities an organization should consider.
If you're still on the fence, the deciding factor should be whether your business can continue to stay competitive while taking longer to deploy new features to your app. If the answer is no, then going serverless is definitely the right direction.
Running backend operations is a business in itself. That's why it makes sense to switch to serverless and focus on what your business does best --- delivering a better experience for your users. We wrote a great post on how much you could actually save by switching to serverless. I recommend you see for yourself how big of a difference it actually makes.
We've gone over some ways to figure out how much money serverless will cost.
While not free, serverless is hard to beat in terms of upfront and maintenance costs. Anyone wanting to get their app up and running as quickly as possible should consider using serverless.