
Announcing workers.dev - yarapavan
https://blog.cloudflare.com/announcing-workers-dev/
======
zbruhnke
Wow Cloudflare just continues to do big things over and over, I'm continually
impressed by the amount of stuff they churn out.

Sort of shocking Amazon or Microsoft have not yet acquired them given where
the markets seem to be going

~~~
ilovecaching
They blog a lot, yes, but CF is a CDN. It doesn’t matter how fancy the
technology is if they have less pops or poor targeting.

CF blog is a marketing tool, and a lot of their claims are inflated or are
capturing a hype train.

~~~
aboutruby
> Cloudflare provides DNS services to 12 million websites, adding
> approximately 20,000 new customers every day.

[https://en.wikipedia.org/wiki/Cloudflare](https://en.wikipedia.org/wiki/Cloudflare)

> Roughly five percent to 10 percent of web traffic now goes through
> CloudFlare

[https://www.wired.com/story/cloudflare-spectrum-iot-
protecti...](https://www.wired.com/story/cloudflare-spectrum-iot-protection/)
(April 2018)

> 10 trillion requests per month, which is nearly 10 percent of all Internet
> requests for more than 2.5 billion people worldwide

[https://www.cloudflare.com/press-releases/2017/cloudflare-
gr...](https://www.cloudflare.com/press-releases/2017/cloudflare-grows-
enterprise-business-more-than-80-percent-year-over-year-amid-significant-
product-rollouts/) (2017)

~~~
ilovecaching
Do you know how many pops CF has compared to Akamai?

~~~
Godel_unicode
Number of PoPs would be a pretty weak metric for a CDN, even if that's all
they were.

~~~
ilovecaching
Number of pops is of course critical to a CDN both in providing more
availability in a more diverse set of locations, but also in terms of
providing a larger backbone and more capacity to protect again attacks and
spikes.

------
sytse
Great to see Cloudflare doubling down on this
[https://www.cloudflare.com/products/cloudflare-
workers/](https://www.cloudflare.com/products/cloudflare-workers/)

BTW If anyone at Cloudflare is interested in doing the work of making GitLab
Serverless
[https://about.gitlab.com/product/serverless/](https://about.gitlab.com/product/serverless/)
compatible with this we're all ears.

~~~
kentonv
Hey sytse, long time no see!

We're definitely interested in these integrations, but our engineering team is
still pretty small and doesn't have the bandwidth... yet.

On that note (for others reading): We're hiring for the Workers team in
Austin, SF, and London.
[https://www.cloudflare.com/careers/](https://www.cloudflare.com/careers/)

~~~
eikenberry
If you ever decide to put together remote teams be sure to announce it. It
looks like you are doing interesting work, but I'm not interested in moving to
any of those cities (and I'm probably not alone).

------
btown
Workers are amazing! Because they have a trivial startup time and cost
compared to lambdas, you can do crazy things like proxies with deep rewriting
of content, etc. Have a SaaS that you use on a subdomain of your site, and
wish you could inject code or a tag manager for analytics? Route the whole
subdomain through Cloudflare and rewrite body tags on HTML, or intercept other
requests in transit, you can deploy this in minutes. Build custom image
proxies and change cache times dynamically. Build your own round robin
systems. Possibilities are endless.

~~~
eeeeeeeeeeeee
Are you comparing them to basic AWS lambda or lambda@edge? It seems like CF
workers are similar to edge functions where you can modify request/response.

------
driverdan
Admin was already taken. I tried to get root but someone else managed to
confirm it before me. I settled for ww.workers.dev

If anyone from Cloudflare is reading this you should consider blacklisting
undesirable subdomains.

~~~
kentonv
We have such a blacklist in our actual implementation but it didn't find its
way into this reservation page. We won't actually be letting people use those
names.

~~~
captn3m0
For people who're only looking to reserve one subdomain - this might cause an
issue. They might think they got `website.workers.dev` when they would have
been equally happy with `awesomewebsite.workers.dev`.

------
christophilus
This sounds cool and makes me want to fiddle with it, but I can’t think of any
use-cases. What kinds of things would you use this for? It can’t connect to a
db, except over some REST-like interface, presumably, as it’s just a vanilla
v8 worker. Right? And using v8 for compute alone seems a bit of a bad fit. So
I’m genuinely curious what the use-case is.

~~~
MuffinFlavored
I wish HackerNews had a way to save comments so I could flag this and come
back to it in a few days when answers are more fleshed out so I can learn. Any
ideas?

~~~
ajnin
Open the comment in a separate tab, come back some time later, hit F5.

~~~
tinus_hn
Or bookmark them

------
aseipp
Workers are pretty neat. I've been using them as a mechanism for serving
private Wasabi/Backblaze B2 buckets publicly, ideally so I can host project
assets with more predictable costs. This is a very practical and useful case
for workers, IMO -- it stops unintended outbound egress from origins, and
gives better routing -- both B2 and Wasabi peer with CloudFlare to waive any
applicable egress fees. So I basically pay a flat $5/month + B2/Wasabi storage
costs (approx $5/mo/TB) and zero egress, more or less.

Overall it's worked pretty well; it's also useful for doing things like
setting up fully 'virtual' domains when using an object store, e.g. set a
CNAME for 'foo.bar.com' to 'example.com' and then write a worker that just
intercepts every `foo.bar.com` request and routes appropriately. This has
worked surprisingly nicely. For example, I host one of my recent projects
under [https://riscv.ls0f.pw/](https://riscv.ls0f.pw/) but this subdomain
doesn't really "exist" beyond being a CNAME for example.com; it's just routed
directly to a B2 bucket subpath, in the background.

At the moment I'm working on a mechanism of automating my worker deployments
using GitHub Actions and seeing how writing them in OCaml/BuckleScript goes (a
much more tedious process), but overall it's pretty neat and useful for
writing quick routing glue and whatnot.

If anyone from the CloudFlare team is reading this, probably the most
important feature I'm looking forward to is resource bindings for
cryptographic keys, to be used with the WebCrypto API, so plaintext keys are
not visible directly in the worker source code. Is there any ETA on when this
might be GA? In my case it's the most important feature currently missing, and
it's really crucial for a lot of practical use cases.

EDIT: also, another really useful feature (for me), but admittedly maybe
niche, would be "atomic-compare-and-update worker script", i.e. I want to
submit a JavaScript file to the API and only update the worker iff the new
source code is not equal to the existing source code. The reasoning here is
that I currently download the worker script and 'diff' it against the new one
as a test, and only upload if they're actually different. I could simply re-
upload every time but I'm not sure if this invalidates any 'hot' worker
instances that are already running. Perhaps the upload API can simply be
extended with new return codes to indicate this...

~~~
kentonv
> the most important feature I'm looking forward to is resource bindings for
> cryptographic keys,

Given the specificity of your request, I'm guessing you're aware that this
feature already unofficially exists, with unlisted-but-googlable
documentation. :) As long as you always deploy workers via the API -- never
the UI -- then it's safe to use the feature now. If you accidentally edit your
script in the UI, the secret bindings might be dropped, since the UI doesn't
understand them yet.

> I could simply re-upload every time but I'm not sure if this invalidates any
> 'hot' worker instances that are already running.

Good news: If you upload exactly the same script, your live workers won't be
restarted. This is a side effect of the fact that we use a content-addressable
store for scripts. (Similarly, if you go to cloudflareworkers.com and enter
the exact same script twice, you'll notice the resulting URL is the same.)

Are you actually observing non-negligible cold start times, though? Usually
the cold start time is so low that you can't really tell when it happens.

~~~
aseipp
Yes, I did find the google-able documentation, but I wasn't sure if the API
worked or not, or it was just a temporary vision of the future, etc -- I guess
I simply didn't try. :) Perhaps once my GH Actions Workflow is figured out I
can migrate to this, and open source it (though it's tied up with my OCaml
code at the moment...)

> Are you actually observing non-negligible cold start times, though? Usually
> the cold start time is so low that you can't really tell when it happens.

Honestly, no, it was just something I realized when writing my workflows --
that I don't know from the API how to tell if a worker is "up to date or not"
other than downloading and comparing. All of my tests have been exceedingly
simple (for now) so it was more just a cautious pre-optimization to make sure
I didn't tank something later on a script unrelated to the one I was working
on (my workflows upload _all_ scripts across domains during CI, iff they
changed).

Oh! Here's one more feature request, though: atomic route/filter updates for
scripts would be really nice. Right now I kind of iterate through them and
match/delete/update them one by one, because overlapping routes cause errors.
This means actually doing an insert or update or create is a bit complicated
-- you need to actually grab the list of _existing_ routes up front and match
IDs with the corresponding route paths, before you can determine what to do
(if it already exists, update, if it no longer exists, delete, otherwise,
insert, etc)

But it would be a huge simplification if I could say "Atomically replace the
current routes with this set of routes all at once". I'm not sure how easy
this is on your end, though. Now that I think of it, I guess I can just
immediately wipe and insert a whole new set, though, since it's not like the
current solution is atomic anyway!

~~~
kentonv
Yeah, we should have had the routing table be one unit all along. We plan to
change it to work that way soon and deprecate the one-route-at-a-time API.

------
davidjnelson
Workers are awesome. They are so innovative in a truly transformative way. It
will be exciting when/if the cpu time gets extended so this can be used for
server side rendering of user interfaces, such as with react.

I think my favorite use case at the moment is to use them as a fault tolerant
highly available proxy solution. So you could have mydomain.com/blog be served
by a microservice that is separate from your primary monolithic app.

~~~
hombre_fatal
Another idea: use them to inflate response times to a consistent XXXms for
code that might have timing attack vulns.

~~~
davidjnelson
That’s a cool idea. I hadn’t thought of using them to build security tools.

------
7ewis
I'm confused as to what this is. From what I can tell, it's a Lambda
competitor?

I 'reserved' a domain, but haven't received an email yet.

~~~
skrebbel
Yep, it's a Lambda competitor.

Basically it lets you run JS code on every request, much like Lambda.
Differences:

1\. It's JS but not Node.JS - You write against the service worker API and
they run it in a vanilla V8. You'll want to webpack your stuff together or
something like that.

2\. Because it's V8 and not Node, they can run many customers in the same
process (as safely as multiple sites can coexist in Chrome tabs), and
therefore it's cheaper than Lambda.

3\. It runs on the cloudflare edge nodes, i.e. close to the user, instead of
some AWS region on the other side of the world, so latency can be lower. _Can
be_ , because for many (most?) use cases you'll still need to call some API
somewhere else, eating up most latency wins you might make. They do also have
a distributed KV store that might help you address this, however.

~~~
xxgreg
> as safely as multiple sites can coexist in Chrome tabs

Chrome tabs usually run in different processes. It sounds like Cloudflare is
using JS isolates within the same process to run many customers.

This sounds scary to me. For security, the Chrome team assumes that any code
running in the same process has access to the whole address space of that
process due to all of the recent speculative execution issues
(Spectre/Meltdown).

I've seen comments on HN say that this isn't a problem for cloudflare because
they do special things with all of JS timing APIs and a few others to
mitigate.

Will be interesting if they are able to make this secure. Millisecond cold
startup times will be amazing for development.

~~~
skrebbel
> This sounds scary to me.

Well, maybe I'm wrong :-) my relationship with CloudFlare ends at me being a
customer, there is a significant chance that my impression of how Workers (or
its security setup) works is wrong. If you want to be sure, ask CF.

~~~
xxgreg
In the conclusion of a recent Spectre paper published by a number of Google
security researchers they write:

"The community has assumed for decades that programming language security
enforced with static and dynamic checks could guarantee confidentiality
between computations in the same address space. Our work has discovered there
are numerous vulnerabilities in today’s languages that when run on today’s
CPUs allow construction of the universal read gadget, which completely
destroys language-enforced confidentiality"

CloudFlare believes this doesn't apply to them and that they have created
defences which allow them to run multiple customers' code in the same address
space without leaking memory. I think the burden of proof is on CloudFlare,
and I'm yet to see them actually publish any information about this.

------
doughj3
Did anyone else notice the "The Network is the Computer™" slogan on
workers.dev? I didn't see any footnotes, is this something Cloudflare now
owns?

~~~
robbiet480
Quick search shows Oracle abandoned the mark August 22, 2011 (serial 77646689)
and Cloudflare filed for it August 27, 2018 (serial 88094654).

------
captn3m0
For a nice easter egg, try double clicking on the page.

~~~
jamieweb
Noticed this when double clicking a word to highlight it - at first I thought
it was one of those badly designed sites where you literally can't select
anything and then it selects everything at once. But no, it's a fancy night
mode, very good job Cloudflare! :)

------
gist
> As a part of Google’s TLD launch program, we were lucky enough to obtain
> workers.dev

This is not 'luck'. You pay the $11,500 fee and with a domain like this you
would most likely get it. Many domains are available at the highest fee
(previous post). The only way you would need 'luck' is if more than one person
wanted this and beat you out. With this particular domain this is unlikely.

For example as of right now (way past launch) all of the following are still
open at the highest rate:

digital.dev

bitcoins.dev (bitcoin.dev is taken already)

php.dev

sql.dev

Honestly knowing a bit about this they could have waited and gone in at the
lower tiers.

Also the singular is open worker.dev and as a best practice they probably
should have bought that (edit: also).

~~~
CydeWeys
WHOIS on workers.dev shows that it was registered a couple weeks ago. They
didn't get it today.

Also: [https://newgtlds.icann.org/en/announcements-and-
media/announ...](https://newgtlds.icann.org/en/announcements-and-
media/announcement-10apr14-en)

------
CharlesW
As someone new to serverless, are there ways for Cloudflare Workers to
authenticate against a specific web app/SPA in cases where the app doesn't
require user login/authentication to work? Or is that effectively impossible
in that case?

~~~
zackbloom
What sort of authentication? Are you trying to ensure that only your webapp
hits your backend (which in this case is implemented in Workers)? That's
generally impossible on the web, as all the code in the browser used to hit it
is accessible to visitors.

~~~
CharlesW
> _Are you trying to ensure that only your webapp hits your backend…? That 's
> generally impossible on the web…_

Yes, and thank you.

------
cow9
> Though we fully utilize Workers, no Workers were harmed in the making of
> this site.

------
bogons
spending 11 grand on a domain name is a great use of funds

