[grx]

While I really like the idea of creating more complex policies at the edge, please remember that Cloudflare Workers are a vendor lock-in. If you proxy your servers with Cloudflare and use their API for more than simple request handling, you rely on their good will to stay online and keep the functionality you outsourced to their Worker API.

[kentonv]

(I'm the tech lead / architect of Cloudflare Workers.)

CF Workers is based on the Service Workers API, which is a W3C standard that has existed in browsers for some time. The only real vendor-specific additions we've made are flags to turn on/off other Cloudflare features; most people don't actually use those flags. So, even today, a worker you write for Cloudflare can potentially be moved to run in the browser with minimal code changes. (Of course, not all scripts are safe to run in the browser, e.g. access control checks.)

Unfortunately, many competing edge compute and "serverless" products have chosen to invent their own, proprietary APIs, rather than use a standard. My sincere hope is that this will change, and in the future, we'll see a convergence on Service Workers. It fits this use case very well, and it's already a standard.

More generally, I think the future is in code that can seamlessly move around, between your servers, client browsers, "the edge", even other people's servers, running wherever it's most useful, perhaps without the developer even needing to think about it. There's far less value in a closed platform with immobile code. And in any case, we aim to win by building a better (larger, faster, less-expensive) network, not by trapping people.

[grx]

Thank you for the reply!

> CF Workers is based on the Service Workers API, which is a W3C standard that has existed in browsers for some time.

> Unfortunately, many competing edge compute and "serverless" products have chosen to invent their own, proprietary APIs, rather than use a standard. My sincere hope is that this will change, and in the future, we'll see a convergence on Service Workers. It fits this use case very well, and it's already a standard.

That's really nice to hear. After the fallout the Github acquisition produced the last days one cannot stress enough how important standardized APIs are for migration operations. I know that vendor lock-ins are profitable business models, but I feel like the damage it does to flexible architectures and data-owning produces more costs in the long run.

> While Cloudflare does use V8, we do not use Node.js

Was this ever an option? Did you consider using other languages besides JavaScript? Like Python or Elixir?

> And in any case, we aim to win by building a better (larger, faster, less-expensive) network, not by trapping people.

Even though I agree with you (as written above) I wonder how Cloudflare aims to do this. To me, it seems like Cloudflare does have way too much websites behind their services. Given that Cloudflare has a history with policing [DS] customers, trust is also an essential feature I'd give top priority. I would therefore argue that decentralization should also be a feature for resilient networks, though it's difficult to implement in your case.

Btw, does Cloudflare have any serious competitors besides CDN providers?

Thanks again for your reply, very interested in your expertise!

[DS] https://blog.cloudflare.com/why-we-terminated-daily-stormer/

[kentonv]

> Was this ever an option? Did you consider using other languages besides JavaScript? Like Python or Elixir?

I answered a lot of these sorts of questions in the original announcement blog post:

https://blog.cloudflare.com/introducing-cloudflare-workers/

The short version is, edge compute calls for an architecture that scales to extremely large numbers of tenants per machine, since every customer wants their code to run in every location. Giving each tenant a whole process does not scale. But we also need secure isolation. So using a JavaScript engine -- built for multi-tenant-per-process secure sandboxing, fast start time, and low overhead -- is pretty much the only reasonable option.

> Cloudflare has a history with policing [DS] customers,

(Disclaimer: My opinions, I don't speak for my employer.)

With respect, I think the history shows the opposite of what you say. Cloudflare has a history of steadfastly refusing to police content, even in the face of intense public pressure to do so, including major press articles essentially calling us Nazi sympathizers. The incident you reference is the only time Cloudflare has ever terminated a customer for objectionable content, and it came with a lengthy explanation from the CEO explaining why he thinks this is dangerous and does not want to do it again. Other cloud infrastructure companies terminate customers like this all the time and don't say anything public about it, so it generates no press.

If you don't believe tech company CEOs should be making decisions about what people can and can't say on the internet, then Cloudflare is your ally, not your enemy.

> I would therefore argue that decentralization should also be a feature for resilient networks, though it's difficult to implement in your case.

There's network decentralization and there's business decentralization. Cloudflare's whole product is network decentralization, on a technical level. But I think what you're arguing for here is business decentralization -- avoiding giving too much power to any one business entity. On that note, keep in mind that Apple, Google, Amazon, Microsoft, and Facebook are each around 100x the size of Cloudflare on most business metrics.

> Btw, does Cloudflare have any serious competitors besides CDN providers?

Not sure I understand this question. CDN is a core part of our product, and of course all our competitors are also CDN providers. Why exclude them?