3 ms·

They are complex, expensive, locked in, partially closed source, and not nearly close to complete solutions. It’s a shiny thing, but at the cost of so much DX

They are complex, expensive, locked in, partially closed source, and not nearly close to complete solutions. It’s a shiny thing, but at the cost of so much DX and optionality which is a worrying general trend with edge stuff.

ZephyrBlu 4y ago
In what way are they more complex than doing it yourself and not complete solutions? Platform risk always exists, but in this case it seems pretty minimal. Cloudflare's solutions are not anything that can't be easily replaced, the value of them is that they are integrated with the rest of Cloudflare's platform and run on the edge. What do you mean by loss of control? Cloudflare has local dev in their Wrangler tool. I'm not sure how testing/scripting is affected here since the main difference is the deployment target.
- nwienert 4y ago
  DurableObjects? It's a totally arbitrary API that's non portable and definitely not easily replaced. And once you opt out of db there's a lot less reason for the whole thing.
  - lucasyvas 4y ago
    Counterpoint - every API is non-portable in the beginning. All it takes is a killer app - for example, S3. I'm on the apprehensive side, but optimistic. Let the early adopters give it a shot so the rest of us can see how worth it it is.
willtemperley 4y ago
They have open sourced the workers runtime to alleviate lock-in fears: https://blog.cloudflare.com/workerd-open-source-workers-runtime/ https://blog.cloudflare.com/workerd-open-source-workers-runt...
- nwienert 4y ago
  Still though: > As hinted above, the full Cloudflare Workers service involves a lot of technology beyond workerd itself, including additional security, deployment mechanisms, orchestration, and so much more. workerd itself is a portion of our runtime codebase, which is itself a small (albeit critical) piece of the overall Cloudflare Workers service.
  - kentonv 4y ago
    The parts we released are the parts you'd need to host your app on other typical cloud hosting services in a typical way (e.g. using kubernetes), which should address lock-in concerns. The parts we did not release are the parts that would only really be useful for building your own hosting service to compete with Cloudflare. These parts would not be particularly useful to someone who merely wants to run their own code -- in fact, they'd be excessively difficult to operate for that use case. This is on par with other services, e.g. my understanding is Deno Deploy has not released this part of their code either.
    - nwienert 4y ago
      I get it, but it means you end up with the arbitrary and limited API that you’d mostly only use for the benefits at the edge, except now you aren’t at the edge and still have all the limitations.

ZephyrBlu 4y ago

In what way are they more complex than doing it yourself and not complete solutions? Platform risk always exists, but in this case it seems pretty minimal. Cloudflare's solutions are not anything that can't be easily replaced, the value of them is that they are integrated with the rest of Cloudflare's platform and run on the edge. What do you mean by loss of control? Cloudflare has local dev in their Wrangler tool. I'm not sure how testing/scripting is affected here since the main difference is the deployment target.

nwienert 4y ago
DurableObjects? It's a totally arbitrary API that's non portable and definitely not easily replaced. And once you opt out of db there's a lot less reason for the whole thing.
- lucasyvas 4y ago
  Counterpoint - every API is non-portable in the beginning. All it takes is a killer app - for example, S3. I'm on the apprehensive side, but optimistic. Let the early adopters give it a shot so the rest of us can see how worth it it is.

willtemperley 4y ago

They have open sourced the workers runtime to alleviate lock-in fears: https://blog.cloudflare.com/workerd-open-source-workers-runtime/ https://blog.cloudflare.com/workerd-open-source-workers-runt...

nwienert 4y ago
Still though: > As hinted above, the full Cloudflare Workers service involves a lot of technology beyond workerd itself, including additional security, deployment mechanisms, orchestration, and so much more. workerd itself is a portion of our runtime codebase, which is itself a small (albeit critical) piece of the overall Cloudflare Workers service.
- kentonv 4y ago
  The parts we released are the parts you'd need to host your app on other typical cloud hosting services in a typical way (e.g. using kubernetes), which should address lock-in concerns. The parts we did not release are the parts that would only really be useful for building your own hosting service to compete with Cloudflare. These parts would not be particularly useful to someone who merely wants to run their own code -- in fact, they'd be excessively difficult to operate for that use case. This is on par with other services, e.g. my understanding is Deno Deploy has not released this part of their code either.
  - nwienert 4y ago
    I get it, but it means you end up with the arbitrary and limited API that you’d mostly only use for the benefits at the edge, except now you aren’t at the edge and still have all the limitations.