3 ms·

I love the idea, especially from reproducibility and debugging standpoints. It seems like there would be a significant performance hit, even if doing this on a

by ibgeek 3y ago

I love the idea, especially from reproducibility and debugging standpoints. It seems like there would be a significant performance hit, even if doing this on a single machine. If the application does external I/O, it seems impossible to reproduce state if it depends on the state of an external system. Can you give more details on the pros and cons and your ideas for ideal use cases? Thanks!

qianli_cs 3y ago
Thanks for your interest in DBOS! We talk more about how things work on this docs page: https://docs.dbos.dev/explanations/how-workflows-work https://docs.dbos.dev/explanations/how-workflows-work For functions doing database transactions, we record execution information in that transaction, which isn't much overhead. For functions that communicate with external services, we record their output in the database and use the recorded output during recovery and debugging. We think DBOS is especially valuable for applications where reliability or security is a major concern (for example, in financial services or insurance).
- ibgeek 3y ago
  That helps. Thanks! Giving the programmer control over the checkpoints make sense. Also, limiting it to “workflows” (not necessarily entire programs) and requiring that these be deterministic makes sense. I did some working with Folding@Home in grad school. All of the simulations would save their state to disk every N iterations to allow restarts. The state was relatively small (lots of compute, not a lot of data). The DBOS papers focused on implementing core OS kernel functionality on top of a distributed relational database. Trying to make a true distributed OS. This product seems like a pretty different direction (reliable execution and enhanced observability). Do your future plans tie back to the original project goals or are you going to keep going in a different direction?
  - qianli_cs 3y ago
    Both the academic vision and the commercial product are built around the same core idea: store as much application and system state as possible (ultimately, much of the state of the OS) in the database. This idea enables many of our platform's benefits, like reliable execution and time travel, and that list will only grow as we continue to build :)

by ibgeek 3y ago

qianli_cs 3y ago

Thanks for your interest in DBOS! We talk more about how things work on this docs page: https://docs.dbos.dev/explanations/how-workflows-work https://docs.dbos.dev/explanations/how-workflows-work For functions doing database transactions, we record execution information in that transaction, which isn't much overhead. For functions that communicate with external services, we record their output in the database and use the recorded output during recovery and debugging. We think DBOS is especially valuable for applications where reliability or security is a major concern (for example, in financial services or insurance).

ibgeek 3y ago
That helps. Thanks! Giving the programmer control over the checkpoints make sense. Also, limiting it to “workflows” (not necessarily entire programs) and requiring that these be deterministic makes sense. I did some working with Folding@Home in grad school. All of the simulations would save their state to disk every N iterations to allow restarts. The state was relatively small (lots of compute, not a lot of data). The DBOS papers focused on implementing core OS kernel functionality on top of a distributed relational database. Trying to make a true distributed OS. This product seems like a pretty different direction (reliable execution and enhanced observability). Do your future plans tie back to the original project goals or are you going to keep going in a different direction?
- qianli_cs 3y ago
  Both the academic vision and the commercial product are built around the same core idea: store as much application and system state as possible (ultimately, much of the state of the OS) in the database. This idea enables many of our platform's benefits, like reliable execution and time travel, and that list will only grow as we continue to build :)