We use Temporal in our company to create child components and complete workflows that are dependent on each other. We also use it for child workflows and employee task orientation.

The most valuable thing about Temporal is that we can create multiple and child workflows. We can segregate work as we want, which is good for work organization. It's also easy to maintain. We're trying to generate and fill PDF forms with custom data, including digital signatures. We call AWS and do all activities through Temporal, like calling and saving data in buckets. We do this because we have a lot of load, with multiple users requesting data. We have two types of users: admin and customer. The admin creates forms, and employees or customers fill them out. When admin gets a form, it's stored in Temporal.

We convert RSA files to PKCS format for integration and have configuration settings. Many libraries help integrate the tool, making it easy to implement in Java and Python.

One issue is that we don't have enough resources in the community to get answers when we face problems. We once had a cross-cluster persistence issue, which we solved using different keys. I think Temporal is good right now, but I'm part of the community and will let you know if I think of any improvements.

We use the cloud version of Temporal. They provide a key that we insert in our files to execute functionality. Our certificate expires in one year, which can cause issues in the product. It would be beneficial if the certificate expiry timeline could be extended to two or three years, as changing it every year is challenging.

 One issue is that workflows without an expiry time can run indefinitely, overloading the server. It would be helpful to have a default timeline that automatically deletes or removes workflows after a month.

I have been working with the product for a year. 

The tool doesn't have any performance issues. 

The solution's scalability is high. 

I haven't contacted support yet. 

Before Temporal, we tried to implement Kafka, but Temporal was better suited to our use cases. We evaluated Kafka but decided to go with Temporal.

The initial setup can be tough for beginners as it's not like simple coding languages. You must understand how functions work, including small things like run methods. I followed the personal document. Three to four people were involved in the deployment. Deployment locally can take one or two days, including all activity checks and finalizing components.

I rate the overall solution a nine out of ten. 

We use the product in our environment to manage a complex data pipeline for our highly data-intensive virtual operating system. Our system processes continuous data flows from instruments worldwide that collect stratospheric weather data. This data undergoes multiple conversions through several layers to reach an L2 format. 

The platform has significantly improved our organization's handling of complex and long-running workflows. It has enhanced our distributed systems' resilience and fault tolerance, especially considering our extensive use of load balancers, API gateways, and complex server configurations. It ensures that if something goes wrong, it is handled in a way that minimizes harm.

The solution's most valuable features include its ability to simplify the management of complex workflows, improve system resilience and fault tolerance, and reduce the need for extensive boilerplate code. 

One area for the product improvement is the learning curve. It can be challenging for new users, particularly those unfamiliar with the concept of workflow as code or data-centric applications. The complexity of managing the pipeline introduces some operational overhead, which requires more communication and coordination within the team.

I have been using Temporal for approximately nine months.

The solution is highly stable, particularly in maintaining resilience and fault tolerance across distributed systems.

I have had positive experiences with Temporal's support, particularly through their Slack workspace, where original developers are highly responsive and engaged in user support. They typically respond within a minute and remain involved until the issue is resolved.

Previously, we used tools like Airflow and DAXTER. We switched to Temporal because it offers superior fault tolerance and robust techniques for handling complex workflows.

The setup complexity is context-dependent. For our proprietary system, we integrated Temporal, which required managing multiple integration points, such as Docker servers, endpoints, distributed databases, and configuration management systems like NGINX or Caddy. While the installation was straightforward, the testing process was more complex due to using workflows as daemon processes.

The implementation was done in-house. 

For those new to workflow orchestration tools, start with simpler tools like Airflow before transitioning to Temporal. 

Temporal is better suited for users with a solid concept understanding and a well-developed intuition for complex systems.

It was chosen for its robust techniques in handling such complex workflows. We operate it on-premises using dedicated servers, and our customized scripts manage it.

I rate it a ten out of ten. 

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.

There are some issues that we face with the versions of Temporal and the databases that we use for Temporal. That's the pain point for us. 

We have been using Astra DB for Temporal, and that has been creating issues. Versions lower than, I guess, v14 point something has some issues. We get some errors in the lower versions. So, sometimes, the workflow gets terminated because of that.

It's been around one and a half years.

Currently, I have not faced any major issues with stability. 

We face issues regarding the databases themselves and nothing apart from those.

60% of our employees use it. I prefer them to use Temporal unless it's for long-running workflows or something where you need to generalize a solution, then it's very useful. 

The other issue is that Temporal's debugging is a bit complex. I guess that's the other issue. I guess it's mostly sorted in the newer versions.

Like earlier, it does not support Elasticsearch. Actually, earlier, it wasn't supported. So, it supports it in the newer version.

I have met some core teams of Temporal. They have been to India and Bangalore, and there was an event for the same. I have been there.

From there, I realized that this issue that I get is due to the versions and all.

Positive

The initial setup is easy.  

The pricing is worth it. The price that they've set is, I guess, worth it.

It's completely up to your requirements. If those requirements meet the expectations of Temporal, I would suggest you go with Temporal rather than any other system. Because in Temporal, you can actually track the activities that have been performed, and it has a proper UI. So it would be very easy for you to debug things and the errors that you have rather than check all the logs.

It is easy for a beginner to learn to use Temporal for the first time. Overall, I would rate it a nine out of ten.

Our team's project is about a service that allows you to hit third-party APIs. Let's say we have multiple products at our company. They will want to hit some third-party APIs for document verification, for which we have some third-party vendors. Instead of them directly hitting their product, we act as a layer in between. They hit our APIs, and then we hit the vendors, ensuring that the response they get is generalized.

Different vendors might have different responses. We give a generic response so that it's easier for them to handle at their end. We have two different modes of operation, namely, sync and async APIs. Async APIs are where we mostly leverage Temporal because async workflows are prone to errors and are not that durable. That's where Temporal comes in. We use Temporal to ensure the durability and scalability of our product.

The solution's most valuable feature is its ability to retry from an interrupted state. I think this feature makes it more popular among developers, and we specifically use and leverage this feature the most in our project.

Temporal doesn't have built-in data storage to store the state of the ongoing execution. We have to configure separate RDS for state management and data storage. Temporal should consider having its own data store so that we don't have to integrate with a third-party data store app.

I have been using Temporal for a couple of months in my company's recent project.

We didn't face an incident where Temporal was down for any reason. The only issue we faced was that we had allocated less storage to the RDS, which Temporal was using to store all sorts of data. Since the storage was less and we had more data pushed, it broke down. However, that had nothing to do with the solution.

I rate the solution’s stability a nine out of ten.

Temporal is a scalable solution both in terms of integration and handling multiple requests. When I spin an activity in a workflow, Temporal can manage it pretty well and store the state of the ongoing code irrespective of how heavy that activity is. In case of a failure, it retries from the current state.

The major challenge we faced was durability. There are instances where an execution gets interrupted, or our service goes down for some reason. Since we mostly use Temporal to interact with third-party vendors, those vendors or endpoints would often be down.

We had to have our own custom retry mechanisms, which come with building Temporal. There was no way to ensure the execution could be durable. The best thing we could do was ask the product to hit that API again.

I would recommend the solution to other users. The main reason why Temporal was built was to have a defined state for microservices. For databases, if we do a transaction, we can be sure either it will succeed or fail. There won't be any state where it's somewhere in between that. Temporal does the same thing for microservices.

Many open-source applications have to implement their own custom logic to ensure things Temporal offers by using an API call to their service using gRPC. This custom logic is heavy, apart from the business logic itself.

Overall, I rate the solution a nine out of ten.

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.

Developers often mention the desire for a more intuitive visualization of workflow states. While Temporal has matured significantly, its current workflow state visualization can be challenging to interpret. The tooling required for visualization, such as integrating with platforms like Grafana, involves extensive instrumentation that developers must handle. Improvements in this area would be beneficial. Additionally, the methods and documentation could be enhanced, as Temporal’s SDK can be costly and has a steep learning curve. Better documentation would be crucial to help developers navigate these challenges.

I have been using Temporal for more than two and a half years.

 Our entire bot uses Temporal quite heavily. 

Scalability depends on the infrastructure. Temporal is highly scalable because it is divided into history service, HD servers, and others. The infrastructure is distributed, and Cassandra is used to manage the state, which is also highly scalable. Uber has designed the infrastructure to be scalable, but building it in-house requires significant DevOps skills. CapEx is substantial for orchestrating and managing the infrastructure; scaling it can be challenging. A dedicated team is needed to manage and scale the infrastructure.

We do have access to the community channels where the community is quite helpful, and many Temporal engineers respond to issues. The platform is great. Maxim himself responds to a lot of issues, even though he is the CEO.

When segregating services, transfer failures, network interruptions, and service downtimes occur. All these things need to be handled. Developers handle it by building SDKs or using other tooling and a cache. A developer has to consider many different products and tools to solve all these problems.

To complete a booking, you must code it to accept the booking and process the payment. But you must also worry about what happens if your payment system is down. 

These things require additional tools and platforms for a developer to achieve these goals. With Temporal, all these issues can be addressed with the system itself, eliminating the need for additional infrastructure or separate mechanisms to handle them.

We use the open-source version of Temporal. 

I highly recommend Temporal for building critical systems that involve distributed transactions. It's an excellent choice for such scenarios.

The cloud option is a good fit if you want to minimize CapEx and don't have many long-running workloads or operations running continuously. Building and managing it in-house might be more cost-effective if you have substantial use cases with many teams or numerous workloads that need to run persistently.

Overall, I rate the solution an eight-point five out of ten.

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.

The network should consider adding a basic authentication system to Temporal, such as JWT token-based authentication. Temporal doesn’t include these features by default, and while Temporal Cloud might offer them, on-premise users have to build their security systems. This is an area where there is room for improvement.

Temporal terminology can be confusing for new users. A more user-friendly approach or improved documentation could help ease the learning curve. The current documentation often requires users to piece together information from various sources, including existing implementations from other organizations or direct developer support. The documentation needs a significant update. Not all necessary information is available online, and community support is limited. For instance, our security team implemented certain features a year ago, but it included relevant information in their documentation. Improved documentation and better community support would greatly benefit users working with Temporal.

I have been using Temporal for the last one and a half years.

While Temporal is generally stable, improvements could be made in some areas. Temporal UI provides information on execution status; it only shows the latest state and not the history of previous attempts or failures. This limits our ability to diagnose issues without setting up a separate logging system in tools like Splunk or Elasticsearch.

The traceback provided by Temporal isn’t always helpful when working with core areas such as interceptors. For instance, verifying if tokens are correctly attached to headers and linked with requests is difficult.

Another challenge is with SDKs. Temporal uses different approaches depending on the language: for Go and Java, it provides native SDKs, while for Python and TypeScript, it uses a Rust core with wrappers. This division makes it difficult to trace issues in the Rust core from Python or TypeScript, creating a barrier to debugging and development.

I rate the solution’s stability a seven out of ten.

From a scalability perspective, Temporal excels. It allows us to spawn multiple workers and handles task distribution across them efficiently. We don’t need to worry much about load balancing. We build and launch as many containers as needed, pointing to the same Temporal server. Its server is a load balancer and a queue system, making it highly effective for scalable applications.

It would be beneficial if Temporal could simplify scalability by allowing workers to spawn multiple processes within a single container based on a specified number rather than deploying multiple containers. This approach would streamline scalability and reduce the need for additional management from the Jenkins side.

We have around ten to twelve services running on the top of Temporal.

I rate the solution’s scalability an eight out of ten.

We did not find any dedicated support. We had to either raise concerns in their forum or connect to the Slack channel of Temporal and raise concerns in the appropriate channel, such as the Python SDK channel, for Python-related issues. 

They operate in US time zones, and since I am in the Indian time zone, I have to wait until they are online to receive assistance. The support is text-based only, and there is often a delay.

Suppose you have multiple technologies across your portfolio and want to implement business logic. In that case, it’s better to use technologies like Temporal instead of converting all the business logic to a single language. If you’re starting from scratch and the business logic is simple without complex scenarios, using Temporal from the beginning might not make sense because it can be complex and requires heavy infrastructure, which increases costs. Temporal may not be recommended for small-scale projects, but it could be a good fit for larger scales where you’ve already implemented many things in different languages.

Overall, I rate the solution an eight out of ten.

We normally use Temporal to create pipelines and to move data from FTP servers to some accounts.

When some jobs take a lot of time and fail midway, the solution’s retry feature automatically causes them to retry. We can put to sleep long-running jobs that take a lot of time and then run them again after some time.

Temporal lacks many resources, like YouTube videos, which users can use to learn or refer to if they get stuck with the solution. Normally, if someone gets stuck with other products, they can see some videos on YouTube, get an idea, and implement it. Temporal is very new in the market, so it lacks such resources.

I have been using Temporal for six months.

Temporal is a stable product. The solution has many good functionalities, but its documentation is very limited, with fewer examples. There's something called Signal in Temporal, but I'm not able to implement it because there are no videos or proper examples given on how to implement it.

Installation is the best part of Temporal because it is very easy to install the solution.

Temporal is a free, open-source tool. You don't have to pay anything. You just have to install the software and run it. Unless you go for the cloud version, you don't have to pay anything. If you go for other ETL tools, like ADF, you have to pay some price even for basic things. Temporal can be used for some basic things. Temporal is an open-source tool, and you can write anything customizable in Python code.

The project I was working on was an AI project. We used to bring data from different sources using Temporal and put it into Elasticsearch. We would then take data from Elasticsearch, implement some AI logic on it, and insert it back into Elasticsearch. AI logic was implemented in Python codes, and our Temporal job was to do the calculations using Python codes and dump the data back into Elasticsearch.

I suggest not using Temporal if your product is vital because if you are stuck somewhere, you will hardly get any resources. You will have to spend a lot of time to find out some functionality. Temporal has very limited documentation. If we have some POCs that are not so vital, then we can use Temporal to check something.

I was able to do some basic things. However, you will find very little documentation or examples if you want to implement some big things. You must spend a lot of time understanding the functionality or connecting with the Temporal team to understand it.

It is easy for a beginner to learn to use the solution for the first time. A new user may take around 15 days to one month to understand workflows. I also took around one month to understand the tool and then try to implement it.

Overall, I rate the solution a seven out of ten.

Temporal serves as an orchestration manager for our Mac platform. It allows us to view and manage all the workflows within the application, providing a framework for implementing these workflows efficiently. Temporal itself doesn't store data; our AWS setup handles storage and other functionalities. Temporal offers a platform for orchestration management and provides SDK tools.

Temporal serves as an Orchestration Manager for our microservices architecture. It automates the communication and actions between multiple microservices. With Temporal, we can track workflows' progress, identify failures, and retry actions as needed. It eliminates the need for each microservice. Previously, we had a dedicated microservice for orchestration, but Temporal replaced it seamlessly.

Temporal provides visibility into workflow progress and analytics andsupports scheduled tasks with customizable settings, making it very convenient.

There are areas where Temporal could improve. For instance, calling multiple microservices with Temporal introduces latency due to workflow registration and analytics overhead.

I have been using Temporal for the past year.

I haven't experienced any stability issues or bugs with Temporal. It has been stable and reliable throughout my use, up to version 1.5.

I once contacted Temporal's support team regarding a certificate issue, but it was our mistake. Overall, I was satisfied with the support.

The initial installation and setup of Temporal was straightforward. We needed to generate a certificate and private key, making the process very simple.

If someone asked me whether they should use Temporal for the first time, I'd say it depends on their customer base. If they have few customers, RabbitMQ might be a better choice. However, if they have many customers or an event-driven system, Temporal would be easier to manage and track. For a beginner joining our team, learning Temporal might initially have a moderatelearning curve, but once you get the hang of it, it becomes pretty easy to understand.

I would rate Temporal nine out of ten because it's the best workflow manager I've used.The one-point deduction is mainly for potential improvements and the latency issue that can sometimes occur.

We use this solution to power an internal workflow engine we've developed. Currently, it's being used within our company to manage workloads running on the orchestration platform.

Temporal fault tolerance has been beneficial for our critical business operations. It handles scheduled tasks and failures effectively, automatically retrying processes in case of issues. Additionally, our workflows are managed smoothly, with our internal engine providing inputs toTemporal for task execution. As for AI-driven projects, we haven't utilized Temporal in this domain yet.

The most valuable feature is its ability to manage and automate workflows without manual intervention efficiently. This includes handling functions and activities and orchestrating various tasks seamlessly. Temporal's reliability and performance have been exceptional for us, even with thousands of workflows running daily on-premises.

Temporal could be improved by making it more user-friendly for beginners and non-technical staff, ensuring easier integration and usability across different use cases.

I have been using Temporal for the past year and a half.

In my experience, I haven't encountered any issues or bugs. Everything has been working smoothly.

It is very scalable. We can run thousands of workflows simultaneously without any issues, so scalability-wise, it's perfect.

The initial setup of Temporal is straightforward. It's similar to deploying other servers; you must adjust the resources if necessary. Overall, no special knowledge is required.

I would rate it an eight because while it's robust and scalable, once you're familiar with it, there's a learning curve for newcomers due to the complexities involved. Additionally, managing specific errors and concepts can be initially challenging. However, its scalability and open-source nature are significant advantages.