February 22, 2024

To be or not to be a Durable Execution Service Provider

Cully Wakelin

Cully Wakelin

Consider the term “Durable Execution Service Provider.”

That is what anyone can become thanks to Temporal.

When I say “anyone,” I mean any team of software engineers willing to take it on, can use Temporal Technologies’ open source software (collectively called Temporal) to become a Durable Execution Service Provider.

blog-image-to-be-1 The image above was generated by an AI tool.

It is possible that you are a developer with experience building your own Durable Execution Service Provider. Many large companies that operate applications at massive scale have invested lots of money building and maintaining such systems. And there are several well known pieces of technology that have spun out from those efforts.

And so you may be asking, “what is different about Temporal Technologies’ version of such a system?”

The short answer is that it boils down to the right iteration at the right time.

blog-image-to-be-2 The image above was generated by an AI tool.

In other words, the software engineers who built Temporal have done this before. They applied their knowledge and experience to make a better version than the ones we have seen previously. And they made it open source at a time when many of the other systems were clearly at their limits, creating a flood of early adopters.

The longer answer is that, this version (Temporal) is so good that it eventually became obvious that they hadn’t just created a production level system that is great for large scale distributed applications, they uncovered a new software development abstraction: Durable Execution.

Durable Execution is the guarantee that the main function of your application and all the steps defined in it, will effectively execute just once and to completion.

And because Temporal provides that as an abstraction so clearly, this is ultimately what sets it apart from other systems intended to provide a similar experience.

Temporal Workflow Execution = Durable Execution

Durable Execution is the generic abstraction that the distributed systems community has been yearning for.

Workflow Execution is the same abstraction by a different name which has been baked into the components of Temporal.

In the context of Temporal (Temporal Technologies’s version of a Distributed Service Provider) the term Durable Execution is more or less synonymous with Workflow Execution.

If you dive into Temporal Technologies’ technical content, you tend to see a lot more about Workflow Executions than Durable Executions. But you can think of a “Workflow Execution” as Temporal Technologies’ proprietary name for the Durable Execution abstraction.

The market is converging around Durable Execution as the name for this abstraction. This emphasizes the result, rather than the implementation, and also avoids associations with the less effectual “Workflow engines” from the past.

Evolution can be a little bit tricky like that. At what point do you stop calling something one thing, and call it something else?

For example, at what point does an application become a distributed system?

Note: that the following diagram is meant to illustrate the evolution of a system - this is not a portrayal of a Durable Execution Service Provider architecture.

blog-image-to-be-3 The diagram above was created for this article.

That is exactly the situation that Temporal Technologies finds itself in.

On one hand, the system that is now Temporal evolved from the idea of distributed event-driven workflow engines.

On the other hand, it is different enough that a refreshing world of application architecture is being unearthed, offering a new fundamental unit for applications to revolve around; i.e., the Durable Execution.

SDK + supervisor = Temporal

So, how does a Durable Execution Service Provider provide Durable Execution to its customers?

  1. SDK
  2. Supervisor service

In the case of Temporal, our users are other software engineers who are building applications to serve a specific use case. These could be any number of a wide range of use cases, such as a payment portal, a browser shopping cart and checkout flow, a web crawler, a file processing pipeline, and so on.

So, the first thing that Temporal provides is a software development kit (SDK). There is an SDK for many popular languages. In the simplest of terms, SDK packages are added as dependencies to your application project. But really, the SDK is both an API library and a framework for the software engineers to write their business logic in. They can also use the SDK components to run their application on any servers they want.

The second thing that Temporal provides is a “supervisor” service.

Consider if each and every time the business logic was invoked it executed to completion and there were never any issues, no matter how many times it needed to execute. You might not ever need the supervisor service.

But thats not the reality, and hardware components fail at weird times, a network request can time out, a server somewhere along the way could be restarting, and every now and then, that business logic could be in jeopardy of failing to complete. Imagine if a step in the process to charge your credit card failed. Was it charged already? Will you be double charged if something retries? Are refunds built in if the process? Was it not charged at all?

blog-image-to-be-4 The diagram above was created for this article.

The supervisor service is responsible for being the source of truth for those applications, such that if they run into trouble, they can chat with their supervisor to remember exactly where things left off and continue on from there. Because the application is written using the SDK, it strategically communicates with the supervisor and becomes “durable” in the face of many types of platform level and application level failures.

Even if both the application’s server crashes and the supervisor crashes, whatever the application was processing will resume where it left off once both are back online.

Choose your supervisor

In the case of Temporal, Temporal Technologies went one step further.

Not only did they build all the publicly available software you need to become a Durable Execution Service Provider yourself (use it for your own applications or offer it as a service to other software teams).

They also made a software-as-a-service (SaaS) supervisor which works with any application written using a Temporal SDK: Temporal Cloud.

blog-image-to-be-5 The diagram above was created for this article.

Once you learn some key points about the SDK, it can be relatively easy to get the hang of the development pattern and build a lot of stuff. But the truth is that, running the supervisor can be harder. The supervisor is actually a set of scalable services and databases that needs to be monitored and tuned to ensure the optimal performance of the system.

Temporal Cloud is run by folks who have many years of experience building and running these types of supervisor systems at a very large scale.

This means that you can get started building a durable application completely on your own, free of charge, anywhere you want and run your application anywhere you want.

And then when you need to operate at a large-scale production level, you can choose to self-host the supervisor service or use Temporal Cloud.

If you want the Service Level Objectives (SLOs) of Temporal Cloud without the heavy overhead of running your own supervisor, just point your applications at Temporal Cloud.

Namespace as a service

Want to become a Durable Execution Service Provider, but don’t want to self-host all of the software?

Great, Temporal Cloud does that too!

Using Temporal Cloud and its associated tools, you can offer Namespaces to software teams inside your organization. A single Temporal Cloud Account empowers you to offer the Durable Execution abstraction as a service to feature teams, infra teams, storage teams, data teams, etc through a Namespace, which provides a level of isolation for Workflow Executions, enabling multi-tenancy for metrics, cost, and more.

Conclusion

Adopting Temporal, whether that is by self-hosting or via Temporal Cloud enables you to offer your applications a new core abstraction: Durable Execution. Become your own Durable Execution Service Provider using publicly available software or use a SaaS supervisor that makes it even easier to adopt and run your durable applications.

Skip the part where you build your own Durable Execution provider and jump right into building durable applications.

Get started today by checking out the Temporal Production deployment docs at docs.temporal.io.