thanks!! haha I appreciate it

i see DOs as stateful workers, and think unifying their interfaces to the extent possible would facilitate composition/adoption.

Add state to this worker?
[x] Yes
[ ] No

How can this worker be invoked?
[ ] HTTPS
[ ] Cron triggers
[x] Other workers
  [ ] Worker A
  [x] Worker B
  [ ] Worker C

New question! If we had worker-to-worker calls (via a binding, as described earlier)... how would you expect this to be billed? If a worker calls another worker, do you expect to be billed for two invocations or one? In Workers Unbound, which bills not just for invocations but also time, would you expect a worker which calls another worker and waits for the response means that you get billed for 2 workers running for the full time period, or only one?

I realize it may be hard to give an unbiased answer to this question, but please try. 😉

i'd expect to be billed for two invocations plus total CPU time. if worker 1 calls worker 2 and just waits for the result, worker 1 wouldn't contribute meaningfully to the latter.

Yup, agree. And hard agree on that second point. It should be the same as if I'm making an external fetch, when I am not billed for time that the remote origin takes to respond. The first worker should not be billed for any non-CPU time used in awaiting the second worker.

as i understand it, this is an area where cloudflare's architecture has a significant advantage over lambda, where wall time would be charged for both invocations.

I've been thinking about worker-to-worker calls a bit, but primarily from the perspective of layering. Let's say you had a worker performing JWT authentication, then a bunch of scripts producing responses. At the moment, I'd need to duplicate the auth code in each downstream worker script, and redeploy them all when the auth code changes. I guess I'm just thinking of a "router" invocation, and you could handle all the responses in one script. But that does mean that updates to any of the response paths all need to be bundled together, which "feels" more complicated than it needs to be.

Oh boy guys, I hate to tell you this, but Workers Unbound pricing -- like Lambda -- is based on wall time, not CPU time.

On another topic, if worker 1 was calling worker 2 and had absolutely nothing else to do other than pass the response back to the client, then I could see a case to be made for handover between workers - releasing whatever invocation cost the first worker (some RAM?) had. This would allow the first worker (if unbound) to stop billing whilst the second does work, and allow for jed's target above.

FWIW, the thinking here is that we wanted to have pricing that could be directly compared to Lambda. If we charged on CPU time, then we'd have to charge more than what Lambda charges for wall time, and people would incorrectly believe that Workers was more expensive. 😕

Might have been a failure of me in misreading the announcements (and I'm not actually in the Unbound beta, so I'm not totally clued up on it), but for whatever reason, that is not the impression I had in my head.

I think it might depend on whether CF want to encourage micro workers, if we're charged for both workers, I'll combine as much as I can into one worker

i dunno, kinda seems like an opportunity to differentiate, highlighting that lambda charges you for literally just waiting.

I understand the argument here for comparing pricing against Lambda, but just as a devil's argument, it does make comparing timings against Bundled next to impossible. And possibly, users are more likely to upgrade from the Bundled plan than they are to come direct from Lambda?

ie, imagine if in 2014 lambda had priced based on EC2 wall time so that they were comparable, even though per millisecond lambda is much more expensive. hobbling the offering to match legacy expectations seems like a missed opportunity, though perhaps i'm not the target market (network-bound, not CPU-bound).

this seems like a good candidate for a classic data-driven cloudflare blog post in which you use actual anonymized worker execution data to show how workers is cheaper for 94% of invocations or something.

As an engineer, I hate thinking about pricing in general. So I'm not going to be the one to try to justify the strategy here. 😛

that said this is great feedback which I'll take back to the team when we think about worker-to-worker pricing

@kenton, is there an architectural reason why DOs can only be called from another worker?

Well, something needs to decide what object ID to use. I suppose in theory we could have some common built-in patterns that take it from the URL or a cookie or whatever, but it seemed easier to just have people write code.

much more flexible too

i get that, 🙇 . but (personally) i'd rather write generic HTTP code that i know (setting urls, headers, etc) than proprietary stub runtime code, given how cumbersome it is to set up bindings and propagate

env

, etc. (though i suppose stub re-use requires stateful runtime integration.)

My $0.02, I would expect to be billed for two invocations. Each worker might also be on different plan, so it would be easier to understand/follow. I do care about pricing and how the plan change for specific worker might affect the bill, so I am really interested how this will work out. 🙂

FYI if you ever are looking for worker-to-worker guinea pigs we (Outsmartly) would beta that in a heartbeat, especially if the perf impact was close to negligible. We tried [ab]using DOs solely for the purpose of being able to separately update isolated nanoservices, which we badly need for our fairly unique use case, but the Worker DO fetch latency was too high (totally understandable since it was/is so new)

hmmm, we haven't tried to use DO-to-DO calls yet, but I assumed it was possible already (otherwise why do we need all the binding machinery). Oops!

And yes, I'd strongly prefer to split them as much as possible ... but with 30 script limit it becomes problematic fast. Especially when you multiply "service" X "project" X "test\prod\previous" etc

(OTOH I understand you're trying to avoid having to keep thousands of isolates in memory... maybe it's possible to load more than one worker for the same user account per isolate?)

I do believe I have some broken DO situation.. any requests that interact with the specific one just keep connecting (even not getting timeouts) Is there anyone who could check it with me? I can share details in DM

I guess I can share it with you @User and you may escalate it if needed, gonna DM you