Temporal Reviews

I'm part of MoCS's platform engineering team. We initially searched for a workflow orchestration engine and discovered Temporal, which met all our development needs. We implemented Temporal in-house and built a self-service platform called Dash for developers, which allows them to use Temporal as needed.

I’m part of the API management team, focusing on deploying API proxies onto gateways. We use Temporal to orchestrate these proxies and manage the API management lifecycle, including deployment processes.

In addition to API management, our entire platform engineering team utilizes Temporal to orchestrate infrastructure tasks such as deployment, deletion, and management. On the business side, Temporal is also used to manage shipment bookings and invoicing processes.

Temporal focus on developers rather than business users. In contrast to older workflow orchestration engines like Camunda, which are more business-oriented and strongly emphasize UI and workflow authoring, Temporal is geared toward developers. It provides extensive capabilities for building complex workflows.

A standout feature of Temporal is its handling of long-running workflows, a significant advantage over many other solutions. Temporal excels in managing distributed transactions and application state durability, especially in microservice environments where transactions might fail due to network issues.

Temporal simplifies these challenges by managing retries, fail-safes, and circuit breakers. As a result, developers don't need to implement these features manually; Temporal handles them implicitly, though it also allows for tuning based on specific needs.

In general, we use Temporal for workflow management. Some of the information is private because I work for a private company.

Temporal allows retryability for different workflows whenever they fail. It helps us to retry workflows without worrying about idempotence and ensures things get done.

I use it to handle messages from the WhatsApp API. There is a product in my company that uses that API, and Temporal helps us debug and handle retries about the messages we receive, persisting the delivery of the message to the final client.

I like the inner retry system that it has, as a developer. The availability it provides to our products is great. When a micro service crash, Temporal handles the retry by itself. It helps a lot in our company and is by far the best thing Temporal has created.

I think people need to have some experience, at least with event-driven design. When someone tries to understand the signals, queries, and updates, it becomes a little challenging if they haven’t worked with webhooks or event sockets. But if someone already knows about event-driven designs, it’s pretty simple.

My friend and I are building an online software as a service platform that uses Temporal extensively. One of my use cases is integrating Keycloak, a single sign-on solution that sends events for bootstrapping organizations and users. I've created an open-source plugin or module that anyone can download and use in their projects, published on GitHub. Another use case is bootstrapping cloud-native solutions. You can write code to initialize the whole solution, defining all steps needed in a serialized fashion. Temporal runs through all sequences, workflows, and activities that need to be processed.

What I like best about Temporal is its durable execution, which means you don't need to write many boilerplate code for critical pieces, especially for retries. It also has great observability and a nice dashboard to see issues without digging into logs. The interface for viewing activities is excellent, with good tracing that shows how long activities took and what ran, making it almost perfect for debugging.

We use Temporal for several purposes. One is for scheduling purposes, where we have workflows that must run at regular intervals or over long durations. Another involves triggering specific events, like in a video processing pipeline, where processing begins as soon as a video becomes available. We also use it for ETL purposes, where once data is available in the data store or warehouse, Temporal triggers the necessary analytics processing. Different teams also define and use the tool based on their specific needs.

From my experience with the tool, I think its best feature is fault tolerance. If an issue occurs, it can be retried from the last successfully processed step without reprocessing the same message. This gives us confidence that completed events won't be retried unnecessarily, even in case of failure. Additionally, it offers a great dashboard and monitoring features, allowing us to see if and where any failures occur, and we can easily retry or replay events to identify issues. Another strong point is that Temporal stores all events in a database, handling everything independently. This feature makes it easier to debug and track logs as needed.

The tool is easy for a beginner to learn. The documentation covers activities, workflows, workers, servers, and more. While more examples could be beneficial, the existing resources are good enough to help you get started. There are also YouTube videos available that can provide additional context. The Slack community for Temporal is very active and helpful, similar to Stack Overflow, where you can find answers to a wide range of questions from basic to advanced levels. If you have a unique question, the community is responsive and provides knowledgeable support.

We have multiple products and wanted to use Temporal because different business logic was better suited to different programming languages, such as Java and Python. We needed a unified solution to handle this diversity. Netflix, one of our clients, introduced us to Temporal.

We set up an on-premise Temporal server, with Temporal handling the initial setup in our Kubernetes cluster. Another team implemented additional security measures on top of Temporal to enhance security. We developed our authentication system and library to integrate with multiple role-based access control systems.

We use Temporal primarily for orchestration. We deploy products across AWS Cloud, Azure, and on-premise data centers. Temporal helps us centralize the orchestration process. We use the Temporal SDK to implement our workflows and workers in our Kubernetes cluster. Based on user requests from a centralized portal, we trigger workflows, which drive multiple tasks sequentially or concurrently to deliver the desired outcomes.

Temporal solved a major problem for us. Implementing a saga pattern or a workflow management system traditionally requires handling many aspects beyond business logic. These include retry mechanisms, rollback mechanisms, logging, monitoring execution status, and features for pausing or resuming workflow execution. Temporal provides all these features by default, allowing us to focus solely on our business logic while Temporal manages the rest.

We have some long-running workflows, like callbacks, that we get after a day or two. We use Temporal for that.

It enables us to use it for something like a continuous process that needs a callback or has multiple steps to be followed. 

It could also be something like having some set of activities that need to be created for a particular task but some other sets for different tasks. It's useful in those situations.

We [my company] use  it to run a large workload. We have a set of security scans we want to perform, and we distribute them over a full day, that’s over 24 hours. We use it to orchestrate all the steps necessary to perform those tests.

It’s essentially an orchestrator. So, we get all those properties we want from an orchestrator. Particularly, we like the fact that the whole process is durable, which is very useful to us. The fact that you can split it up into multiple smaller steps, called activities, and store state at every single activity is something we have made a lot of use of. For example, this allows us, in case of any failures down the road, to stop the process midway and resume it later. That’s another feature that’s been really useful.

We like the fact that it integrates very well with the programming language. It’s not completely transparent; you know you’re using Temporal because you have to import the SDK into the programming language itself. But it’s done in such a way that it’s really easy to write and fits well within the language. Personally, I like that the main abstraction, workflows, allows you to follow domain-driven designs super easily. In your workflow, you can essentially speak your business language and not have to worry too much about Temporal because it’s abstracted away so nicely.

One last feature that’s super useful is that retry policies are built into the Temporal system. For example, if one of your activities fails for multiple reasons, you can configure how you want to handle your failure cases in the activity itself with a retry policy. You can say, “Okay, I want to retry this later,” and configure the cadence. This step is really configurable, it’s built into the system, and it’s something we have made a lot of use of. So, that’s pretty much a big picture summary.