I might be biased because I really like this technology. I’m not going to go for the ten because of the downsides but Temporal would be a strong eight out of ten, definitely nine. But if they consider improving the weaker points, I would definitely see this as one of the strongest stacks we have currently. I’d recommend it, but be cautious before going for the tech just because it sounds nice. Users definitely have to lay out their use cases and figure out whether they need an orchestrator in the first place becauses it’s not a Swiss army knife. It’s not a tool that fits every use case. But for our use cases, for example, I definitely recommend it. It's a really good product.
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 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.
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.
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 delivers durable execution. It abstracts away the complexity of building scalable distributed systems and lets you keep focus on what matters – delivering reliable systems, faster. It allows you to avoid coding for infrastructure nuances and their inevitable failures.
Temporal eliminates recovery logic, callbacks, and timers from your code so you can spend more time building features.
Temporal makes your software durable and fault tolerant by default, reducing failures by 10-100X....
I might be biased because I really like this technology. I’m not going to go for the ten because of the downsides but Temporal would be a strong eight out of ten, definitely nine. But if they consider improving the weaker points, I would definitely see this as one of the strongest stacks we have currently. I’d recommend it, but be cautious before going for the tech just because it sounds nice. Users definitely have to lay out their use cases and figure out whether they need an orchestrator in the first place becauses it’s not a Swiss army knife. It’s not a tool that fits every use case. But for our use cases, for example, I definitely recommend it. It's a really good product.
I would recommend it to other people. Try Temporal Cloud because on-premise is kind of expensive. Overall, I would rate it a nine out of ten.
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 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.
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.
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.