Guess what? You shouldn’t need a team of certified DevOps engineers to deploy reliable, scalable, cost-effective, serverless applications.
Earlier this year, I and two other TMG engineers started building what would become TMG Fuse. This dynamic integration platform allows Shopify merchants to quickly and seamlessly integrate their stores with external ERP and CMS systems. TMG Fuse is the fastest way to connect Shopify with SAP S/4HANA or ECC, offering a private, cloud-based integration solution embedded into Shopify. With such a small team, our priority had to be writing integration code, leaving little bandwidth for the complexities of infrastructure deployment and management. What was our solution to this? AWS Lambda. Offering high-speed deployments without the operational overhead of traditional server management, we thought this would be the ideal choice for hosting our backend logic. Although Lambda is a compelling technology, after a few weeks of development work, we found multiple pain points and barriers to entry. Working with Lambda required a great deal of AWS-specific knowledge. Templates maintaining our AWS services became so complex that we spent equal time configuring “serverless” infrastructure while developing new features. Finally, as new features emerged, costs began to skyrocket, forcing us to look for a new solution. Enter DBOS, a serverless platform that radically simplifies serverless application development. DBOS Cloud is a high-performance serverless platform designed to deploy cloud-native backend solutions efficiently. After a demo from the DBOS team and two days of work on a proof of concept, we had a production-ready application able to support two key integrations. In this article, I’ll explore how DBOS solved our pain points with Lambda and why we love building on DBOS.
The Hidden Complexity of AWS Lambda
At first glance, AWS Lambda offers a compelling simplification of backend infrastructure. You write code, upload it, and let AWS handle the rest—right? Unfortunately, that’s far from the whole story. While Lambda removes the need to manage physical servers, building a robust serverless backend with AWS still requires deep knowledge of a wide range of services. For us, deploying a functional backend meant configuring and maintaining AWS Lambda functions and API Gateway for our HTTP endpoints, Step Functions for orchestrating workflows, and RDS with RDS Proxy for database connections. These are standard steps for anyone hosting a cloud-based backend application with Lambda. Each service requires specific AWS expertise, and misconfigurations often lead to performance bottlenecks or security risks.
This tangled web of AWS services meant we constantly switched contexts between writing feature code and battling infrastructure configurations. What we initially thought would be a “serverless” experience required extensive AWS-specific knowledge, adding overhead that our small team could hardly afford. The learning curve for each service was steep, and maintaining it all was a time-consuming burden that directly impacted our ability to ship new features. Integrating AWS Lambda with other AWS services like API Gateway, DynamoDB, and RDS was essential for developing efficient serverless applications.
DBOS, on the other hand, stripped away the complexity of managing individual AWS services by offering powerful abstractions through TypeScript decorators. Instead of setting up and managing API Gateway to expose HTTP endpoints, we could add a @GetApi() or @PostApi() decorator to a function and instantly make it accessible via HTTP.
DBOS also eliminates the need for RDS Proxy when connecting to a database. Rather than managing database connections manually, we leveraged the @Transaction() decorator, which seamlessly provides a context to interact with the database using an ORM. We no longer had to worry about scaling connection pools or ensuring secure, reliable access to our data. With DBOS, database interactions became as simple as writing application logic, enabling us to focus on building features, not infrastructure.
The Headache of Managing “Serverless” Architecture
As I’m writing this, I can’t help but laugh at the oxymoron I just typed. How could serverless infrastructure require so much management? Yet, that’s exactly what we encountered as we dove deeper into deploying our application with AWS Lambda. Using the Serverless Application Model (SAM) to provision our serverless infrastructure felt more like wrangling complex configurations than achieving the simplicity we had hoped for. Managing and provisioning AWS resources within serverless applications adds another layer of complexity, especially regarding debugging and testing.
Let me illustrate this with an example. To deploy a simple API Gateway endpoint with Lambda support using SAM, we had to write a template that looked something like this:
Resources: MyApiGateway: Type: AWS::Serverless::Api Properties: StageName: Prod MyLambda: Type: AWS::Serverless::Function Properties: Handler: index.handler Runtime: nodejs14.x CodeUri: ./src Events: MyApiEvent: Type: Api Properties: RestApiId: !Ref MyApiGateway Path: /hello Method: GET
That’s just to set up one endpoint with a Lambda function! With each additional route or Lambda function, the template grew larger, and the complexity became harder to manage. As the templates expanded, we dealt with deeply nested structures where resources depended on other resources buried layers deep. This led to many problems: debugging configuration issues felt like untangling a web, and even minor changes had a ripple effect, often breaking things elsewhere. Managing dependencies between resources in these deeply nested templates became a constant headache, adding unnecessary complexity to the code and making it harder to troubleshoot or expand the system without introducing new issues. Additionally, AWS Lambda’s provisioned concurrency feature enables functions to remain initialized and ready to respond promptly, which is crucial for applications requiring quick responses.
In comparison, here’s what it looked like in DBOS to expose a function as an HTTP GET endpoint:
@GetApi('/hello') async function getHelloMessage() { return { message: 'Hello from DBOS!' }; }
That’s it—just a decorator added to a simple TypeScript function. There is no need to configure API Gateway routes, tie them to a Lambda function, or manage any underlying infrastructure. DBOS abstracts all that complexity, allowing us to focus on building features rather than maintaining templates. This shift was liberating; what once took dozens of lines of configuration code was replaced by a single line of TypeScript.
And here’s the kicker: I haven’t even included the code that gets executed inside the Lambda function in the AWS example. The infrastructure configuration was so overwhelming that implementing the feature felt like an afterthought. With DBOS, the code is the feature, and infrastructure is effortlessly handled in the background.
The Real Cost of “Serverless”
One of the final straws that broke us away from AWS Lambda was the unexpected surge in our monthly costs. AWS Lambda appeared cost-effective when we first started, especially with its pay-per-execution model. However, as our application grew in complexity, so did the costs. AWS Lambda’s automatic scaling, which dynamically adjusts resources based on demand, initially seemed beneficial but eventually contributed to the rising expenses.
With each additional Lambda function, API Gateway route, and RDS instance, our monthly bill started to creep higher and higher. For example, the cost of running API Gateway with multiple endpoints and RDS Proxy for efficient database connections quickly increased. We spent upwards of $1,500 per month to maintain the infrastructure—this didn’t even account for the additional costs of scaling our Lambdas to handle spikes in traffic or for services like CloudWatch to monitor everything. As a crucial computing service within the serverless architecture, AWS Lambda integrates well with other AWS services but can become costly as usage scales.
In contrast, DBOS provided a much more predictable and affordable pricing model. We maintained the same integrations and functionalities for our use case while spending 15x less monthly. The simplicity of DBOS’s infrastructure and the fact that we no longer had to provision and manage individual services drastically reduced our operational costs. The flat-rate pricing for serverless applications meant we could scale without worrying about unexpected spikes in costs, allowing us to focus our budget on feature development and growth, not infrastructure overhead.
In their blog post, DBOS explains how they achieve significant cost savings compared to Lambda. DBOS provides a more efficient and cost-effective solution for serverless applications by optimizing resource allocation and reducing unnecessary usage.
Switching to DBOS wasn’t just a technical win but a financial one.
Why We Love Building On DBOS Cloud
Since switching to DBOS, the benefits haven’t stopped at reduced costs and simplified infrastructure. The performance improvements alone explain why we’re still stuck with DBOS. Unlike traditional Lambda deployments, DBOS consistently delivers faster execution times and smoother scalability. While it’s difficult to quantify precisely how much time we’ve saved since making the switch, there’s no doubt that DBOS’ claim that you can “build in days, not months” has held in our experience. Features that used to take weeks to develop and deploy now move from idea to production in a fraction of the time.
One of the standout benefits has been the consistency between local environments and production. With AWS Lambda, our local environments often felt disconnected from the app’s real-world behavior, leading to frustrating rework post-deployment. DBOS, however, ensures that what we build and test locally mirrors exactly what will run in production. DBOS users also benefit from not having to manage or upgrade the underlying operating system or network layers. This has led to greater confidence in our deployments and significantly fewer surprises after pushing new features live.
DBOS also comes packed with features that previously required additional setup or third-party tooling. For example, its built-in once-and-only-once execution, transactional idempotency, and partial retries for failed processes benefit our application’s stability and reliability. In our old setup, achieving these guarantees would have required considerable time and effort configuring Lambda, Step Functions, and other AWS components. DBOS is a key component of serverless solutions in cloud architecture, integrating seamlessly to enhance our development process.
DBOS has transformed not just how we build applications but also how we think about the entire development process. DBOS has proven to be the right choice for our team, from cost savings to performance gains to feature development faster.
**Join the webinar to discuss the move from AWS to DBOS with DBOS! Our VP of Technology, Thomas McNally, and Commerce Engineering Lead, Aaron Brill, will discuss the move to DBOS and how it powers our Shopify-embedded IPaaS App, TMG Fuse. Register to attend the October 23rd session!
