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

41–50 of 59 posts

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

#41

Post by gvdongen »

skrtskrt wrote: post #30
gvdongen wrote: post #26

Earlier quoted context omitted.

Hi! I work for Restate A few key differences. Restate has a more flexible programming model. You don't write workflows with activitities, but just durable processes/handlers. Durable steps execute inline and get persisted over an open streaming connection in Restate (low latency, lower overhead per durable step, sharing resources like sandboxes) instead of working with a pull-model where each activity executes remote…

How do “stream over an open connection” and things like “sleep for months” play together? Naively without digging into the code I would look at a “streaming over an open connection” as likely to strictly more brittle.

If a handler starts a sleep/human approval/RPC call, or so, then this timer/promise is persisted in Restate's journal. Restate does the waiting. The handler process itself can suspend (e.g. on a serverless function), and the bidirectional connection is closed. Once the timer fires/approval comes in, Restate re-invokes the service with the journal of previously completed steps, and the service can replay to the exact point in the code where it suspended and continue from there. Restate is like a DB for journals, so you can sleep for as long as needed, also months.

So you have fast persistence of events while a handler can make progress, and suspensions while waiting.

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

#43

Post by stsffap »

skrtskrt wrote: post #30
gvdongen wrote: post #26

Earlier quoted context omitted.

Hi! I work for Restate A few key differences. Restate has a more flexible programming model. You don't write workflows with activitities, but just durable processes/handlers. Durable steps execute inline and get persisted over an open streaming connection in Restate (low latency, lower overhead per durable step, sharing resources like sandboxes) instead of working with a pull-model where each activity executes remote…

How do “stream over an open connection” and things like “sleep for months” play together? Naively without digging into the code I would look at a “streaming over an open connection” as likely to strictly more brittle.

The way it works is that Restate supports suspending workflows that sleep for months and later (once the sleep finishes) resumes them at exactly this point. Technically, this is the same process as resuming a crashed workflow.

While the workflow is actively doing work (like calling other services, accessing state or interacting with external services, for example) the server is connected to the workflow deployment via a low-latency bidirectional streaming connection to receive and acknowledge progress that the workflow makes. That way the workflow can finish as fast as possible.

A nice side effect of this model is that you can co-locate your workflow with expensive resources, such as a sandbox, which should be used by all durable actions that the workflow executes. The reason this works is because Restate can inline durable steps (what would be modeled in Temporal as activities, I believe).

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

#44

Post by KptMarchewa »

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.

The fintech (now bank) that I worked in couple of years ago utilized this pattern pretty effectively.

The overhead of doing something in this way is quite large, but, as this handled literal money, it was definitely worth it.

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

#46

Post by skywhopper »

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.

Yeah, I’ve seen it working. It does work well to implement a multi-system transactional workflow broken down into retryable steps. So, eg, if you are operating a SaaS and need a workflow for new customer signup to wait for multiple steps that might last for hours or days like: validate credit card info, wait for email confirmation, add entries to customer database, set up workspaces in downstream systems, spin up cloud resources, initialize systems, notify customer, start billing cycle, etc. and if any step fails, you might want to retry or send alarms or internal notifications, or roll back other steps, or kick off other workflows. Then you can define all of that, in code. Each step can be different runtimes run on different worker systems, etc, all coordinated through a central database.

You can scale the workflows up and down to as complex or simple as you want for whatever your business is. The example above is one I’ve seen, but it works on a smaller scale as well. But you have to write the implementation code in very specific ways to get the benefits, and the overhead ends up being very difficult to plan and reason about, and a lot of business logic actually gets hidden amongst the weeds of the tool’s overhead.

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

#47

Post by sewen »

skrtskrt wrote: post #30
gvdongen wrote: post #26

Earlier quoted context omitted.

Hi! I work for Restate A few key differences. Restate has a more flexible programming model. You don't write workflows with activitities, but just durable processes/handlers. Durable steps execute inline and get persisted over an open streaming connection in Restate (low latency, lower overhead per durable step, sharing resources like sandboxes) instead of working with a pull-model where each activity executes remote…

How do “stream over an open connection” and things like “sleep for months” play together? Naively without digging into the code I would look at a “streaming over an open connection” as likely to strictly more brittle.

I guess the confusion is that it doesn't have to be one single persistent stream.

While the durable function does fast work and adds steps, it pushes it through a stream. When a wait point comes, it closes and replays on resumption (typical durable execution style).

That gives you the best of both worlds: same long-running workflows with long sleets and suspensions, but also ability to add steps with few ms overhead only.

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

#48

Post by sewen »

slaughtr wrote: post #7
pksunkara wrote: post #4

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

AI workflows are a convenient fit for temporal, their platform is great for much more than just those. It’s an elegant and easy to use solution for a lot of workflow needs.

That's fair, but they are also a great fit for Restate. For example, Replit migrated their whole coding agent from Temporal over to Restate, a pretty big setup.

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

#49

Post by hedgehog »

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…

In concrete terms if your app has functions that do very little work but run for hours or days at a time blocking on external resources, and it is acceptable to add 100+ms latency + a serialization boundary to every function call, it is acceptable to take on a bunch of other tooling complexity, and you are willing to sacrifice verifiability of the code, then it might be a fit. In those situations the structure of it (or DBOS or similar) can help standardize that part of your app. Unlike a regular state machine based approach it's easier to represent branching logic and so forth in imperative code. I think its popularity is like the Mongo NoSQL fad, it looks convenient up front but in practice is very painful in most situations. Having used it a fair amount I would recommend starting with actors and state machines, especially in this age of robot code where it's easier to apply heavier approaches to testing in verification.

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

#50

Post by mshafir »

gvdongen wrote: post #26
pksunkara wrote: post #4

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

Hi! I work for Restate A few key differences. Restate has a more flexible programming model. You don't write workflows with activitities, but just durable processes/handlers. Durable steps execute inline and get persisted over an open streaming connection in Restate (low latency, lower overhead per durable step, sharing resources like sandboxes) instead of working with a pull-model where each activity executes remote…

How does that compare to Inngest? As I understand it it also executes inline and has a streaming connection to the inngest server. We ended up going with them over temporal because it was so much simpler operationally, but restate seems even lighter. I can appreciate how it's hard to tackle the enterprise market, but the temporal solution feels so bloated I really hope the industry can standardize on some simpler patterns
Post reply on HN