Guess what? You shouldn’t need a team of certified DevOps engineers to deploy reliable, scalable, cost-effective serverless applications.
Earlier this year, I, along with two other TMG engineers, started building what would become TMG Fuse, a dynamic integration platform that allows Shopify merchants to quickly and seamlessly integrate their store 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 an incredibly powerful 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 were spending equal amounts of time configuring “serverless” infrastructure as we were 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. 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 each of 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 just 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 not just Lambda but also API Gateway for our HTTP endpoints, Step Functions for orchestrating workflows, and RDS with RDS Proxy for database connections. These are all very common steps for anyone hosting a cloud-based backend application with Lambda. Each of these services requires specific AWS expertise, and misconfigurations often lead to performance bottlenecks or security risks.
This tangled web of AWS services meant that we were constantly context-switching between writing feature code and battling infrastructure configurations. What we initially thought would be a “serverless” experience ended up requiring 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.
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 simply 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” Infrastructure
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.
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! And with each additional route or Lambda function, the template grew larger, and the complexity became harder to manage. As the templates expanded, we found ourselves dealing with deeply nested structures where resources depended on other resources buried layers deep. This led to a host of 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.
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. No need to configure API Gateway routes, tie it to a Lambda function, or manage any underlying infrastructure. DBOS abstracts all that complexity away, 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: in the AWS example, I haven’t even included the code that gets executed inside the actual Lambda function. The infrastructure configuration was so overwhelming that the implementation of the feature itself 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. When we first started, AWS Lambda appeared cost-effective, especially with its pay-per-execution model. However, as our application grew in complexity, so did the costs.
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, combined with RDS Proxy for efficient database connections, quickly added up. We found ourselves spending upwards of $1,500 per month just 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.
In contrast, DBOS provided a much more predictable and affordable pricing model. For our use case, we were able to maintain the same integrations and functionalities while spending 15x less per month. The simplicity of DBOS’s infrastructure, combined with 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.
DBOS breaks down how they achieve significant cost savings compared to Lambda in their own blog post. By optimizing resource allocation and reducing unnecessary resource usage, DBOS provides a more efficient and cost-effective solution for serverless applications.
Switching to DBOS wasn’t just a technical win—it was a financial one, too.
Why We Love Building On DBOS
Since switching to DBOS, the benefits haven’t stopped at just reduced costs and simplified infrastructure. The performance improvements alone make it clear why we’ve stuck with DBOS to this day. Compared to traditional Lambda deployments, DBOS consistently delivers faster execution times and smoother scalability. While it’s difficult to quantify exactly 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 true 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 real-world behavior of the app, leading to frustrating rework post-deployment. DBOS, on the other hand, ensures that what we build and test locally mirrors exactly what will run in production. 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 are features that directly benefit the stability and reliability of our application. In our old setup, achieving these same guarantees would have required considerable time and effort configuring Lambda, Step Functions, and other AWS components.
DBOS hasn’t just transformed how we build applications—it’s changed how we think about the entire development process. From cost savings to performance gains to faster feature development, DBOS has proven itself to be the right choice for our team.
