The main purposes for using Temporal are automation flows, especially financial automations and supply chain automations. Our company name is SR, we are a digital-first CPG brand making company, managing over 70 brands, and managing the supply chain in terms of POs, transfer orders, and moving stock between 3PL to Amazon and vice versa involves a workflow process that could include manual or automated steps, and for everything, we use Temporal.

We are just a customer; we directly use it for our internal use cases, building software for our company, and we are not a reseller or any of those modes.

Our workflows are pretty straightforward, not involving multi-step or multi-stage workflows. It's more about making sure it is an automated workflow, not big complex workflows. Therefore, the basic retry mechanisms are solving our needs, and we haven't explored the advanced capabilities yet, as our problems are already resolved.

In terms of scalability, it is the best feature. I did use Camunda in the past for almost three years, and resource constraints-wise, Temporal is much more prudent in doing the work. While Camunda comes with an exceptional UI and more forms, for our use case, pace is more important than actually the UI. Hence, I would say Temporal is working in the right way.

The deployment process is quite straightforward as it provides both Kubernetes and Docker Compose versions, allowing us to run it in ECS containers, and I find it simple for both Camunda and Temporal.

The only area for improvement in Temporal is the UI. I know it is a non-UI first product, but comparing Camunda versus Temporal UI, there is a difference. Moreover, n8n, being a no-code platform, is easier for business people when writing workflows. Hence, we maintain two systems today: n8n for no-code solutions where business automations can be managed, and Temporal for mission-critical systems which cannot fail.

We have been using the solution for roughly about eight months now, not one year.

I do not see performance issues or latency problems with Temporal; the stability largely depends on how we write the code rather than the tool itself. Both Camunda and Temporal are stable as long as we adhere to proper design patterns.

I am tight on schedule today. We can discuss Camunda sometime later, but I can only provide insights on Camunda 7, as I chose Temporal over Camunda 7 for production use.

We haven't engaged any Temporal experts; we've learned everything from their documentation, which I find helpful and clear with examples.

The ROI is apparent in terms of business case automation; previously, a bunch of people filled in data in NetSuite or managed stocks between warehouses and Amazon, but now everything is automated, saving time. We have streamlined processes and saved roughly 300 to 400k in chargebacks, considering our revenue is around 0.5 billion a year.

In terms of pricing, Camunda is indeed costlier than Temporal. The cloud deployment costs differ, and while Camunda 7 can be cheaper due to its integrated setup, comparing latest versions between Temporal versus Camunda 8 is not straightforward. Temporal is faster and cheaper regarding our use cases.

My overall experience with Temporal is rated between 8 to 9, mainly due to a learning curve that only senior developers can navigate effectively, which makes it a bit challenging for junior developers.

We don't have any instances of on-premise, so I cannot comment on that because we are a first company, with all services deployed on cloud infrastructure.

Most of the integration is through RPC or APIs, ensuring all our systems are in cohesion.

We do state persistence to a Postgres instance, and we have modified it to our use case with better indexing. And for fault tolerance, we built a queue and an alerting mechanism that notifies us if any workflows fail after specific failure points so we can act upon it.

On a scale of 1-10, I rate Temporal an 8.

We use Temporal to manage workflows for a client project involving interactions with MongoDB. We needed a framework to manage workflows and set the correct order and timing. We chose Temporal over Azure Functions because it worked better for our needs.

What I like best about the tool is that it's easy to install, especially since it uses JavaScript. It's also easy to set up with Docker, and the documentation is easy to understand.

Configuring workflows can be improved —the solution could offer more options, but it's not a must-have.

I have been using the product for a year. 

I haven't experienced any stability issues or bugs with Temporal. Any problems I encountered were more related to our specific project than the tool itself.

I think Temporal's scalability is very high. While our current project hasn't required much scaling yet, I can see the benefits for future use. I'd rate its scalability as an eight out of ten, mainly because it was easy to implement with Docker. 

In my organization, at least three people used Temporal when I was involved in the project.

I haven't contacted the support. I can manage with the documentation. 

Before implementing Temporal, we struggled with Azure Functions, which was hard to understand and manage. Temporal made it clearer how the workflow would function from start to finish.

Temporal is open-source and free to use, which is great. We didn't have to pay for any premium features.

You need to know Node.js, Express, and Docker to use the tool effectively. Docker is particularly important for easy setup and image mounting.

Overall, I'd give the tool a solid an eight out of ten. It's easy to use and start up, making it simple to begin a project.

I would recommend Temporal to others. My advice would be to clearly understand Docker, as it goes hand-in-hand with using Temporal for setup and implementation. I'd also recommend reading the documentation about creating plugins for Temporal to understand how to build workflows for any project.

We needed to implement different workflows for various processes, each involving distinct steps. We used these workflows to handle large data flows or complex operations within our system. We employed them to limit rates, as it was the simplest solution. Furthermore, we implemented some cron jobs, not because they were required but because we wanted to avoid excessive zooming.

It is fairly easy, though it has some undefined aspects if you're unfamiliar with it. For instance, you need to properly define your functions and handle various small issues that can arise. It's easy to get started and user-friendly. There are some internal challenges. For example, I initially missed some error handling and connectivity issues, which led to problems because I implemented things incorrectly. 

I don't like the limitations on data flow, particularly the difficulty of passing large amounts of data between different activities. I encountered issues with this and explored various approaches. I decided to store the data in files, but there were other methods. This was redundant because it added complexity to the implementation, making it more challenging to manage.

I have been using Temporal for about a year.

Due to an overload on our cluster, we encountered some problems. We started too many tasks simultaneously. Initially, we attempted to run many tasks at once, but this approach caused issues.

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

The system has good scalability, though it does have some limitations. For instance, Postgres handles scalability well up to a certain point, typically around eight to ten instances. Using a NoSQL database might address some scaling issues more effectively. Postgres was sufficient, and we could work within its constraints.

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

You can use it for free if you want.

In most cases, you don't need extensive prior knowledge to use this technology; the documentation is usually sufficient. It was likely my mistake for not understanding the problem correctly, even though it was logically straightforward. Fortunately, we had an experienced developer on our team who helped me identify some best practices.

I recommend this technology even to large tech companies. It’s pretty substantial and impactful. I suggest reading the documentation more carefully, as it affected my experience.

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

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.

One area where I think Temporal could improve is its dashboard, particularly in event tracking. Currently, the dashboard doesn't show a time-based view of events, meaning it doesn't display when an event started or went through the retry process. If this feature could be added in a future release, it would significantly enhance monitoring capabilities. Other than that, Temporal's overall performance is quite impressive, and we're confident we can migrate to the Temporal workflow.

I have been using the product for two years. 

When we started the POC, my team was the only one using workflow management, with around ten people. However, it eventually expanded to the entire company, so the whole engineering team is currently using it. I can't say the exact number of people because it’s a company-wide adoption.

I have talked to Temporal's support team before. They have a Slack channel and community, which I joined. We faced an issue with the scheduling of EventBuild in some time zones. I asked a question there, and they quickly responded to my query and solved my problem. The support team is very active and generally provides the best solutions possible. The community is great and very helpful.

Before the tool, we used Airflow, but it didn't support complex business logic and only worked with Python. We explored options like Cadence and other workflow management or event processing systems. However, after doing a POC, we found that it offered multiple SDKs, allowed us to write complex business logic, and provided a good monitoring dashboard. So, we decided to switch to Temporal and finalized it as our workflow management solution.

Deployment is easy, especially if you're familiar with Kubernetes. We used Helm for the deployment, and it was straightforward to set up the web service, UI service, front end, and everything else. It didn't take much time, and the documentation was helpful, though it could be improved. The documentation sometimes only covers the basics, which might not be sufficient for someone new to Kubernetes. However, for those with experience, the deployment process is smooth. I also created a document to guide others through the deployment process.

The tool's cost depends on how you implement it. If you're running it in-house, using your own infrastructure like Kubernetes, and managing your own database (e.g., Cassandra), the cost isn't different from what you might be paying for other workflow management solutions. However, you may save some costs by consolidating multiple jobs into a single workflow, which can reduce the number of workloads and resources you need.

On the other hand, cloud hosting might be more expensive. We haven't tried cloud hosting, so I can't provide specific details on that, but it's something to consider if you're looking at cloud-based options.

If you're considering using the tool for the first time, my advice would depend on your specific use cases. If your needs are simple, with no long-running processes, and retrying the same event without issues is acceptable, you might be fine using alternatives. However, if your business logic is complex, especially if you need to ensure that once an event like a transaction is processed, it should not be retried, then Temporal would be a better choice.

Just note that while it's great for these purposes, adding something like a DAG implementation would enhance its usability even more. But overall, Temporal is one of the best options for complex and long-running processes.

Overall, I would rate it around seven to eight out of ten. It solves many problems, like availability, consistency, retry logic, and offers a good dashboard. However, the reason for not rating it higher is due to the documentation and event graph, which could use some improvement. While the documentation is great, it could be more detailed, with more examples, and the server deployment can be tricky for those unfamiliar with it. Additionally, a more advanced monitoring tool, such as a visual graph showing the workflow's progress and where any failures occurred, would be a valuable enhancement.

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 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.