We’ve often heard developers working on stateful applications say that they want to adopt serverless technology to more easily deploy to the cloud, but can’t because it’s prohibitively expensive. For clarity, by “stateful applications” we mean applications that manage persistent state stored in a database (for example, a web app built on Postgres).
In this blog post, we'll show how to make serverless 15x cheaper for stateful applications. First, we'll explain why it's too expensive right now. Then, we'll show how we architected the DBOS Cloud serverless platform to make serverless affordable for stateful applications.
Improving Serverless Efficiency
The first strategy DBOS Cloud uses to make serverless efficient is sharing executors across requests to improve resource utilization. The key idea is that stateful applications are typically I/O-bound: they spend most of their time interacting with remote data stores and external services and rarely do complex computation locally.
Consider an e-commerce application that shows you the status of your latest order. When you send it a request, it calls out to a database to look up what your last order was, then waits for a response, then calls out again to look up the status of that order, then waits for a response, then finally returns the status back to you. Here’s what that might look like:
Current serverless platforms execute such applications inefficiently because they launch every request into a separate execution environment. Each execution environment sends a request to the database, then is blocked doing nothing useful until it receives the database’s response. Here’s what it looks if two people concurrently look up their latest orders in AWS Lambda:
For stateful applications, current serverless platforms spend most of their time doing nothing, then charge you for the idle time.
By contrast, DBOS Cloud multiplexes concurrent requests to the same execution environment, using the time one request spends waiting for a result from the database to serve another request. To make sure execution environments are never overloaded, DBOS Cloud continuously monitors their utilization and autoscales when needed, using Firecracker to rapidly instantiate new execution environments. Here’s what it looks if multiple people concurrently look up their latest orders in DBOS:
DBOS Includes Reliable Workflow Execution
The second strategy DBOS Cloud uses is leveraging DBOS Transact’s reliable workflows to efficiently orchestrate multiple functions in a single application. Many applications consist of multiple discrete steps that all need to complete for the application to succeed; for example, the checkout flow for an online store might reserve inventory, then process payment, then ship the order, then send a confirmation email:
Conventional serverless platforms require an expensive external orchestrator like AWS Step Functions to coordinate these steps, executing each in sequence and retrying them when they fail. By contrast, DBOS Cloud uses the reliable workflows built into open-source DBOS Transact to guarantee transactional execution for an application at no additional cost.
DBOS Cloud vs. AWS Lambda Cost Comparison
Now that we’ve explained how DBOS Cloud achieves its cost efficiency, let’s measure it by comparing the cost to run a stateful application workload on DBOS Cloud versus AWS Lambda. We’re referencing AWS Lambda because it’s the most popular serverless platform, but the numbers are comparable for other platforms like Azure Functions or Google Cloud Functions.
Consider an application workflow with four steps. To keep the math simple, let’s say each step takes 10 ms and the application is invoked 250M times a month (~100 application invocations/second). Since the workflow takes 40 ms total, this works out to 10M execution seconds per month. Assuming a 512MB executor is used for both DBOS Cloud and Lambda, here’s how the cost compares:
DBOS Cloud Cost
We’ll assume that in DBOS, the application is implemented as four operations in a DBOS Transact reliable workflow. Stateful, reliable workflow execution is built into DBOS, so there is no need for a separate orchestrator like AWS Step Functions. The 10M execution seconds per month falls within the $40 per-month DBOS Cloud Pro pricing tier, so the total cost is $40 per month.
AWS Lambda + AWS Step Functions Cost
In AWS Lambda, this application would likely be implemented as four functions orchestrated by an AWS Step Functions workflow. AWS Lambda charges $0.20 per 1M function invocations plus $8.33 per 1M execution seconds (assuming a 512MB executor). Additionally, AWS Step Functions charges (using Express Workflows, the cheapest option) $1.00 per 1M workflow invocations plus $8.33 per 1M operation-seconds of execution. Thus the total cost for Lambda is $200 for the 1B function invocations (four per workflow) plus $83.33 for 10M execution seconds. The total cost for Step Functions is $250 for 250M workflow invocations plus $83.33 for 10M operation-seconds. The grand total is $616.66. As we said earlier in this post, that is over 15 times more expensive than DBOS Cloud. Here's a table to summarize our cost comparison:
Try it out!
To get started with DBOS, follow our quickstart to download the open-source DBOS Transact framework and start running code locally.
If you have any questions about the article or about DBOS, please ask in the comments!
Top comments (1)
It's awesome!