Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Temporal raises $550M at a $12.55B valuation

temporal.io

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Temporal raises $550M at a $12.55B valuation

#31

Post by stsffap »

nosequel wrote: post #10
pksunkara wrote: post #4

Can someone tell me why people prefer temporal over something like https://restate.dev ?

Those two don't really compare. Temporal has been around 3 years longer and is a much more heavyweight system. Temporal can support workflows that sleep for months at a time and still reliably finish. I'm sure there is a place for restate.dev, but it isn't in the same place as Temporal.

Disclaimer: I am a co-founder of Restate.

Like Temporal, Restate supports workflows that sleep for months at a time and let's them reliably finish.

It actually does many more useful things. For example, you can have services that remember state across invocations and there is no need for continue-as-new.

Since Restate allows inlining durable steps into your workflow, it is very easy to co-locate your workflows with expensive resources such as sandboxes or other per-node resources. And the nice thing is that each durable step is really cheap and adds only minimal overhead.

Re: Temporal raises $550M at a $12.55B valuation

#32

Post by kolanos »

binlog wrote: post #13
a_c wrote: post #9

Can someone shed some lights on what temporal does? Their blog says [1] Durable Execution offers three key benefits: It improves application reliability by providing fault tolerance. It simplifies code by allowing it to focus on the goal instead of potential problems. It accelerates development by eliminating the need to write complex error-handling logic. So... like exception handling? or something like erlang's let…

It’s an async job runner that scales well. Yeah they advertise a lot of fancy features, but really what they are selling is solid failure-resistant infra. Companies could set the same thing up with an in-house team, but it’s pretty great to be able to click a button and start running workloads at tens or hundreds of thousands of RPS without needing to figure out the internals.

Durable execution comes with overhead that you'll need to determine whether or not fits your use case. If you're looking for raw speed then durable workflows are going to be a steep trade off. Most workflows should be durable by default, though, so it is more the rule than the exception.

Re: Temporal raises $550M at a $12.55B valuation

#33

Post by Syntaf »

Absolutely love temporal, but pretty shocked to see they have a $12.55B valuation.... feels nuts?

We're using temporal as the foundation for agents running on our platform doing accounting work for clients, it's proven extremely effective and I love how durable workflows are within temporal.

+100 on the technology, but realizing they are also VC funded makes me a little more cautious when it comes to vendor lock in.

Re: Temporal raises $550M at a $12.55B valuation

#34

Post by staticautomatic »

a_c wrote: post #27
a_c wrote: post #9

Can someone shed some lights on what temporal does? Their blog says [1] Durable Execution offers three key benefits: It improves application reliability by providing fault tolerance. It simplifies code by allowing it to focus on the goal instead of potential problems. It accelerates development by eliminating the need to write complex error-handling logic. So... like exception handling? or something like erlang's let…

Thank you for all the explanations. I think I have better understanding now. Another question, at what scale (in terms of number of services, and maybe throughput? what other dimensions?) should we start considering using temporal?

I think scale is less important than other considerations. For me the biggest motivator is when the use case prefers doing something exactly-once, the downside risk of failure is high, and robust failure handling is moderately complex. The canonical example I use is healthcare communications; others use payment/fulfillment.

Also having a unified control plane is handy even at a pretty small scale if your alternative is going full “cloud native” on hyperscaler microservices. The ability to see what’s happening when and where across a single workflow run is a dream compared to all the traditional logging approaches I’ve seen.

Re: Temporal raises $550M at a $12.55B valuation

#35

Post by kolanos »

binlog wrote: post #23
a_c wrote: post #16

Earlier quoted context omitted.

Can I understand it as a performant celery with a UI?

Not the same thing, because celery and the like are sdk-level abstractions that need you to plug in your own queue (usually Redis, Kafka) and all other components. The Temporal server deployment includes the full control plane, queue, persistent database, UI and everything else. So you only need to manage your worker boxes.

A Rust equivalent to Celery would be something like Apalis [0]. Where every job is just an async function, similar to a Celery task.

[0]: https://github.com/apalis-dev/apalis

Re: Temporal raises $550M at a $12.55B valuation

#36

Post by stsffap »

bpicolo wrote: post #12
pksunkara wrote: post #4

Can someone tell me why people prefer temporal over something like https://restate.dev ?

Restate is directly inspired by Temporal.

Disclaimer: I am a co-founder of Restate and might be biased.

Restate's spiritual father is Stateful Functions (https://nightlies.apache.org/flink/flink-statefun-docs-maste...) a library for event driven applications built on top of Apache Flink. If you want to learn more about why we started building Restate, I recommend this excellent blog post https://restate.dev/blog/why-we-built-restate.

I understand that Restate and Temporal look similar from a superficial perspective but Restate is not only a durable execution engine but a durable runtime that also provides consistent state and reliable communication. These are the building blocks to build reliable agents and applications w/o having to fit them into a workflow-activity like model. If you want to learn more about how Temporal differs from Restate, check out https://restate.dev/vs/temporal.

Re: Temporal raises $550M at a $12.55B valuation

#37

Post by fxtentacle »

a_c wrote: post #9

Can someone shed some lights on what temporal does? Their blog says [1] Durable Execution offers three key benefits: It improves application reliability by providing fault tolerance. It simplifies code by allowing it to focus on the goal instead of potential problems. It accelerates development by eliminating the need to write complex error-handling logic. So... like exception handling? or something like erlang's let…

"Why is it such a big deal?"

It's used by OpenAI.

Re: Temporal raises $550M at a $12.55B valuation

#38

Post by paulddraper »

a_c wrote: post #9

Can someone shed some lights on what temporal does? Their blog says [1] Durable Execution offers three key benefits: It improves application reliability by providing fault tolerance. It simplifies code by allowing it to focus on the goal instead of potential problems. It accelerates development by eliminating the need to write complex error-handling logic. So... like exception handling? or something like erlang's let…

> So... like exception handling?

Yes...with eventual consistency.

If your process OOMs, if the machine restarts, etc.

Plus some other distributed execution advantages.

Re: Temporal raises $550M at a $12.55B valuation

#39

Post by sanderjd »

tomp wrote: post #24
penciltwirler wrote: post #17

Earlier quoted context omitted.

I think it's useful for implementing Sagas https://temporal.io/blog/saga-pattern-made-easy Basically, a multi-step event handling system, where the data could be spread across multiple databases/systems, so there's no way to rollback a transaction atomically across all the databases. Instead, you explicitly codify "compensations" to undo your previous commits so that you eventually end up in a consistent state. Tempo…

Does it actually work? In a past job, they tried to implement a similar thing on much lower scale with bidirectional database migrations. Fortunately, they were mostly ran in one direction.

IME, it works, but at the cost of a pretty large amount of overhead, both in performance and (I think more importantly) cognitive.

Honestly I never did come to a satisfying conclusion on whether I thought it was worth it. The teams I worked on that used it found it neither simple nor easy to use, and I was never sure whether we were really reaping the benefits of correctness in the face of failure at the scale we were running. We eventually migrated everything off of it, and everyone was happier, but perhaps (probably) we had more lurking bugs in distributed failure cases. But to my knowledge we never tracked down an incident to the kind of problem that temporal solves.

I guess I'd say that I like durable execution (or at least temporal specifically, it's the only system like this that I've used) in theory, but not really in practice.

Post reply on HN