I had worked on a home-grown workflow engine previously, and have got lots of ideas and unanswered questions in my mind. Your talk really opened my mind. It's a bit concise and takes some pondering on certain parts, but definitely worth of watching many times. Thank you, Maxim!
I was particularly interested in the discussion of the temporal workflow engine. Temporal is a relatively new workflow engine, but it has quickly gained popularity due to its focus on scalability and durability.
Great presentation! I am making a presentation to pitch Temporal internally; what software are you using for this presentation? Can't seem to find that B logo anywhere else.
From my experience every additional infrastructure dependency I need to have to work with Temporal will make adoption of Temporal harder. As I understand to work with Temporal I currently would need to sell a DB (maybe Cassandra), ElasticSearch and Temporal to my management. Can you not get rid of ElasticSearch and implement the listing functionality on some kind of global "workflow visibility" table? I guess you don't need to support arbitrary ad hoc queries. I also guess the domain workflow visibility has only a limited amount of queries that make sense. This would probably also improve listing consistency (you mention the time lag). Then you would not need to "go through 10000 shards" or am I wrong?
Great stuff. The arguably sad part is that elegant languages become much less important when designing complicated and interdependent systems, when you have a framework simplifying this much of the resilience and fault handling
This would benefit from a lot more polish. It's very hard to follow, even for someone like me who has built workflow engines from first principles already.
in fact, Tom.. if you'd like to do a call with me to talk about how we could do better, or explain it from your experience, i'd love to chat - want to email me at swyx at temporal.io?
Agree it has assumptions that users have used temporal or cadence before. For example at 14'37'' it mentions activities and task-queues, those are temporal terminologies, in fact what would better is that you use normal terminologies to explain temporal. You cannot just use temporal to explain temporal, that's a recursive explanation and hard to follow.
I only came across Temporal 30 minutes ago, and this makes sense. I work on distributed systems so domain terms like task queue and activities can be inferred from context to understand their constraints. I think you're being too harsh.
I had worked on a home-grown workflow engine previously, and have got lots of ideas and unanswered questions in my mind. Your talk really opened my mind. It's a bit concise and takes some pondering on certain parts, but definitely worth of watching many times.
Thank you, Maxim!
thanks for watching! please ask your questions in our slack! temporal.io/slack
I was particularly interested in the discussion of the temporal workflow engine. Temporal is a relatively new workflow engine, but it has quickly gained popularity due to its focus on scalability and durability.
PoA talk! It's really fascinating to see software engineering blocks' best practice are becoming product nowadays.
Loved this. The transcript documentation was a great help. Had to look up a lot of concepts. Very cool
Great presentation! I am making a presentation to pitch Temporal internally; what software are you using for this presentation? Can't seem to find that B logo anywhere else.
@@dilipramirez that was just the software that the Scale conference used to record this talk, not within our control :)
From my experience every additional infrastructure dependency I need to have to work with Temporal will make adoption of Temporal harder. As I understand to work with Temporal I currently would need to sell a DB (maybe Cassandra), ElasticSearch and Temporal to my management. Can you not get rid of ElasticSearch and implement the listing functionality on some kind of global "workflow visibility" table? I guess you don't need to support arbitrary ad hoc queries. I also guess the domain workflow visibility has only a limited amount of queries that make sense. This would probably also improve listing consistency (you mention the time lag). Then you would not need to "go through 10000 shards" or am I wrong?
Great stuff. The arguably sad part is that elegant languages become much less important when designing complicated and interdependent systems, when you have a framework simplifying this much of the resilience and fault handling
This would benefit from a lot more polish. It's very hard to follow, even for someone like me who has built workflow engines from first principles already.
in fact, Tom.. if you'd like to do a call with me to talk about how we could do better, or explain it from your experience, i'd love to chat - want to email me at swyx at temporal.io?
just following up tom i'd love to chat :) swyx @ temporal . io
Agree it has assumptions that users have used temporal or cadence before. For example at 14'37'' it mentions activities and task-queues, those are temporal terminologies, in fact what would better is that you use normal terminologies to explain temporal. You cannot just use temporal to explain temporal, that's a recursive explanation and hard to follow.
I only came across Temporal 30 minutes ago, and this makes sense. I work on distributed systems so domain terms like task queue and activities can be inferred from context to understand their constraints. I think you're being too harsh.