frequently asked questions.
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.
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.
So why does that matter to you? Well, for starters, Bustle has seen its I.T. spending drop by 84%. A big part of that is that their maintenance crew is only about half the size a comparable website would need if they were managing their own servers.
Since your team doesn’t manage the servers, your provider will charge only when users are requesting data from the server.
The good news is, your first 1M requests are free. So are the 400,00 GB-seconds of computing time that come with every account.
All following requests come in at $0.20 per 1M requests and $0.00001667 per GB-second after going through your free usage. But are there other costs you should consider? Yes, here’s a look at other reasons your bill is higher than normal.
If you are storing data on Amazon’s s3 service that Lambda will be reading from, 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 So 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?
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:
Spend Summary. Your spend summary is a great way to forecast 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. Month-to-Date Spend by Service. This shows which AWS services you use most and the percentage of your budget going towards each. Month-to-Date Top Services by Spend. Also shows the services you use most with a break down of their costs. These tools are fine for free tier use, but when you have multiple Lambda functions there is a better option.
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.io you can track the cost for any particular project from the main screen allowing you to see exactly how many dollars you are spending for your AWS Lambda. Furthermore, you can see the individual cost for each of your function as well as other important information like execution time, invocations, errors, etc. under the Lambda functions view section.
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’s a lot of 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. No more sleeping with one eye opened, fearing those midnight crashes.
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 server 10, 100 or 1000 people at once without breaking a sweat, your application gracefully scaling in order to fit the needs of your users.
Not everyone will get bothered by those cold starts but for the ones that are there is one way to prevent this and that is by warming up your APIs, especially if you are expecting a rush of customers. For example, a restaurant that uses their app to accept orders can send a rush of concurrent requests just before lunch rush so less of their users will experience lag.
You can also write your code in languages with a low cold start time. A few languages that react fast to first requests are node.js, python, and go.
If your app is experiencing a lot of cold starts, try increasing your memory limits. 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 in order to create a better experience for your users. I use Dashbird’s function view to filter out cold starts and make note of how often they appear.
The deciding factor if you’re still on the fence should be whether your business can continue to compete while taking longer to deploy new features to your app. If the answer is no, then going serverless could put you in the right direction.
Running back-end operations is a business in itself. That’s why it makes sense to switch to a serverless provider and focus on what your business does best, better experience for your users, not I.T. Annika wrote a great post on how much you could actually save by switching to serverless and I recommend you go see for your self how big of a difference it actually makes.
Failure detection, analytics and visibility for serverless applications in under 5 minutes.