temporal VS DurableTask

I don't know if I agree with the argument regarding durability vs elastic execution. If I can get both (with a nice API/DX) via something like Temporal (https://github.com/temporalio/temporal), what's the drawback here?

Link to GitHub -->

However, as we mentioned, each shard needs management. Part of the management includes a cache of Workflow histories for that shard. We can see the History pods’ memory usage is rising quickly. If the pods run out of memory, Kubernetes will terminate and restart them (OOMKilled). This causes Temporal to rebalance the shards onto the remaining History pod(s), only to then rebalance again once the new History pod comes up. Each time you make a scaling change, be sure to check that all Temporal pods are still within their CPU and memory requests—pods frequently being restarted is very bad for performance! To fix this, we can bump the memory limits for the History containers. Currently, it is hard to estimate the amount of memory a History pod is going to use because the limits are not set per host, or even in MB, but rather as a number of cache entries to store. There is work to improve this: github.com/temporalio/temporal/issues/2941. For now, we’ll set the History memory limit to 8GB and keep an eye on them—we can always raise it later if we find the pod needs more.

Correct, the workflow's guarantee to always complete executing independent of hardware failures is dependent on the database not losing data. You host your workflow code with Temporal's Worker library, which talks to an instance of the Temporal Server [1], which is an open-source set of services (hosted by you or by Temporal Cloud), backed by Cassandra, MySQL, or Postgres. [2] So for instance increasing Cassandra's replication factor increases your resilience to disk failure.

[1] https://github.com/temporalio/temporal

[2] https://docs.temporal.io/clusters#persistence

Re:graph frameworks - thanks for the pointers, hadn't heard about them! I'd heard of temporal which I believe provides a similar memoization capability with the purpose of not losing work in workflows that failed partway through?

Documentation

Personally I am leveraging the knowledge and momentum of Replay to dive into the Python SDK, build out a couple of applications to deepen my knowledge around Workflows, Activities, and metrics, and continue inhaling knowledge via the monthly meetup, the application development guide, and documentation. By next year I’ll experience the conference, not as one new to Temporal, but as an expert—maybe even as one of the people helping with the architecture review or running a Birds of a Feather; if anything, I know I look forward to seeing YOU at next year’s event!

Might want to checkout DurableTasks[1] for that

[1] https://github.com/Azure/durabletask

Azure Durable Tasks are great for this. It’s open source too: https://github.com/Azure/durabletask

AWS Simple Workflows or Azure Logic Apps are both services that let you define S2S workflows however you like without any particular bias to CI/CD or business operations.

If you want to go even lower level, a framework like DTFx lets you define long-running, distributed and resilient orchestrations in code:

https://github.com/Azure/durabletask

The fast and less official way to clean up state is to use the underlying Durable Task Framework storage APIs directly. Durable Functions has an internal dependency on the Durable Task Framework, so no new packages need to be added to your app to access them. Here's an example function that demonstrates how to clean up Azure Storage state quickly (disclaimer: use any of my code samples at your own risk).

Netherite is a distributed workflow execution engine for Durable Functions (DF) and the Durable Task Framework (DTFx).

To give context - this table would track long running operations that were initiated and being executed by our worker machines (we use this c sharp framework).

Behind the scenes, the Durable Functions extension is built on top of the Durable Task Framework, an open-source library on GitHub that's used to build workflows in code. Like Azure Functions is the serverless evolution of Azure WebJobs, Durable Functions is the serverless evolution of the Durable Task Framework. Microsoft and other organizations use the Durable Task Framework extensively to automate mission-critical processes. It's a natural fit for the serverless Azure Functions environment.

I could clearly see that the developers building applications on Microsoft Azure were facing eerily similar challenges to what I had seen back at AWS. The same challenges we had tried to address with SWF. So I used one of the internal team hackathons as an opportunity to pair up with Affan Dar and take another stab at solving the problem. Affan had a very deep understanding of Azure ServiceBus so he was the perfect person to build the backend for the stateful C# experience I had in mind. Microsoft had recently added async/await capabilities into C# and it turned out to be an amazing fit for writing stateful applications which need to orchestrate calls among microservices. Since Java lacked an async/await like primitive, we had to rely on Promise-based async approach when building SWF. But with C#, we were able to deliver a much cleaner and synchronous programming model using async/await. This hackathon project resulted in Azure Durable Task Framework as an OSS client SDK which uses Azure ServiceBus as the backend to provide a stateful workflow-as-code experience for applications. I'm so glad to see Microsoft has continued investing in the experience with Azure Durable Functions as the latest reincarnation of the original effort. An effort which started with that hackathon project.