DBOS, Inc.

Hoping for a failure-free Black Friday? 🤞🏽 Secure it with DBOS, Inc.'s durable execution for building POS, supply chain, and fulfillment workflows that just work. Get 50% off Pro with code BLACKFRIDAY24 at checkout. Offer ends Dec 3! 🔗 https://lnkd.in/gjMSUkrU

How do you use Postgres to make an operation idempotent? Idempotence is a powerful property--it means that performing an operation multiple times has the same effect as performing it once. Making programs reliable is easier if they're idempotent because you can retry them without side effects. Unfortunately, you can't add idempotence to an operation externally. To make an operation idempotent, you have to know something about what it does. Luckily, there's a big class of operations that you can make idempotent--database operations! That's because database transactions are "all or nothing," either fully completing and committing or aborting and fully rolling back. To make a database operation idempotent, you commit a unique idempotency key to a bookkeeping table as part of its transaction. Because it's all one transaction, either the entire operation and the idempotency key are committed, or none of them are. That way, the transaction commits exactly once, no matter how many times it's tried. Under the hood, this is what DBOS transactions do to guarantee exactly-once execution of any database operations in your workflows. No matter how many times your workflows are called or how many times they are interrupted or restarted, your database operations execute once and only once.

Make durable execution lightweight with DBOS, Inc.! Use simple decorators like DBOS.step & DBOS.workflow to save program state in Postgres, enabling crash recovery. Just import the library & connect to Postgres. 💡Learn more: https://lnkd.in/gW9UQrAJ

It's been three months since I became CEO at DBOS. I took this role because I wanted to see these products out in the world, and one of the main things that attracted me to this company is the strong computer science fundamentals the products are based on. Our cofounders spent years doing research on how to build the best serverless platform in the world, and here is a paper that describes it!

Thrilled that mine and Qian Li's paper was just published in the Communications of the ACM! The big challenge we've been working on since grad school is how to make serverless computing work well for stateful applications. This is tricky because it's hard to make long-lived stateful workflows reliable in ephemeral serverless execution environments. The solution, which we talk about in this paper and are building at DBOS, Inc., is using database transactions to make programs durable. The key idea is to store the execution state of a serverless workflow in a database. That way, if the workflow is interrupted, it can automatically recover from where it left off by looking up its execution state in the database. If you know that stateful programs are durable, it becomes a lot easier to make them serverless. You can deploy them to ephemeral executors and leverage their durability to autoscale them and move them between executors as needed. That way, you can build incredibly reliable stateful programs that also benefit from the scalability and convenience of serverless.

Serverless cloud is perfect for stateless apps, but what if it could handle database-backed apps like a pro with DBOS, Inc.? Think time-travel debugging (yes, you read that right) & exactly-once execution. Intrigued? You should be. Check out the full article below. 💡 https://lnkd.in/grqUGhRy

Open source Open life

Last day at KubeCon, swing by the DBOS, Inc. booth to learn how we can help you ship faster and simplify your workflows to scale seamlessly. 📍T53

New feature just dropped--a GitHub integration with the DBOS Cloud console! 🚀🚀🚀 This is something a bunch of our users were asking for: you can now link your applications to GitHub repositories and deploy new apps with a button click. It's also really exciting because there's potential for a bunch of new features that will make managing backend apps even easier, including support for branching and for rolling back deployments to past commits.

As AI agents become more widely used, one problem I foresee is keeping a human in the loop. Some decisions are just too big to leave to an AI agent, so it has to escalate to a human agent to approve or deny them. Architecturally, adding a human to the loop is tricky because it's an inherently long-running and asynchronous. You need to send a notification like an email, then wait potentially hours or days for a response, then take an action based on the response. By themselves, most AI agent frameworks don't support this kind of long-running tool. Instead, I believe the future of AI agents is to use durable execution alongside agentic frameworks to build more powerful tools. Durable execution lets you build an agent that can escalate to a human, then be ready to take action as soon as the human responds, even if that takes hours or days. More broadly, it helps you build long-running, reliable tools for your agents, including tools that: - Schedule actions to occur far in the future, like "send a reminder email in one week." - Reliably run a workflow of steps, such as purchasing a plane ticket. - Run tasks concurrently or asynchronously.