It all comes down to the speed of light. It always does. The speed of light limits the latency possible between someone using the Internet and the application they are accessing. It doesn’t matter if they are walking down the street hailing a car using a ride-sharing app, sitting in an office accessing a SaaS application on the web, or if their wearable device is reporting health information over WiFi. The speed of light is everywhere.
When you can’t fight the speed of light you only have one possible solution: move closer to where the end users are. In simplistic terms, that’s what Cloudflare has done by building its network of 117 data centers around the world. We’ve cut the latency between users and servers by moving closer.
The Missing Link
But to date all we’ve moved closer are things like SSL handshakes, WAF processing of requests and caching of content. All those things help make Internet applications faster and safer, but there’s a huge missing component… code.
The code that makes Internet applications work is still sequestered in servers and cloud services around the world. And there are only a limited number of such locations even for large cloud providers. There have really only been two significant places to run code until now: on a server distant from an end user and on the end user’s device. Accessing a SaaS application consists of code running on your web browser and on a remote server. A wearable device contains code that reports information to server in the cloud. A mobile app runs on your phone and accesses an API somewhere on the web.
Cloudflare Workers is about creating a third place where code can run: neither on the device nor in the backend server. Workers run close enough to end users that the latency is low, but are updateable with the speed of server code. Servers typically have much more CPU and memory than devices but are located far from them. Workers have the CPU and memory resources of servers but are located close enough (latency wise) to devices that they significantly augment the capabilities of end user devices.
We believe a whole class of applications will take advantage of this three tier approach: on device, in network, on server.
We considered exposing traditional code/configuration languages like the NGINX conf, or the Varnish Configuration Language, but they are much too restrictive to really unleash the power of code at the edge.
Cloudflare is incredibly configurable and controllable. We have a rich dashboard with per URI configuration of practically everything, but there’s nothing like code. And code turns Cloudflare from a service to a platform.
Cloudflare’s other great strength is the speed with which configuration can be updated globally. If you make a configuration change (click a button in the UI to enable IPv6, add or remove a DNS record, add a server to your load balancing configuration, enable a WAF rule, change a rate limiting setting, etc.) it is rolled out and operational worldwide in seconds.
The same goes for code. Developers are able to update their code in seconds worldwide and have multiple versions available for test and deployment. And the rich, interactive development environment means that developers can write and test code before deployment and then upload it to make it instantly available.
This we believe is game-changing because developers won’t need to worry about where code runs or the latency to end users. They’ll be able to put easily updated code near end users effortlessly.
We can’t wait to see what people build.
Kenton Varda, who led the Cloudflare Workers development, has put together a detailed blog post explaining how they work and the decisions around language, runtime, and more: with examples.