A few months ago we released a new way for people to run serverless Javascript called Cloudflare Workers. We believe Workers is the fastest way to execute serverless functions.
If it is truly the fastest, and it is comparable in price, it should be how every team deploys all of their serverless infrastructure. So I set out to see just how fast Worker execution is and prove it.
tl;dr Workers is much faster than Lambda and Lambda@Edge:
This is a chart showing what percentage of requests to each service were faster than a given number of ms. It is based on thousands of tests from all around the world, evenly sampled over the past 12 hours. At the 95th percentile, Workers is 441% faster than a Lambda function, and 192% faster than Lambda@Edge.
The functions being tested simply return the current time. All three scripts are available on Github. The testing is being done by a service called Catchpoint which has hundreds of testing locations around the world.
This is every test ran in the last hour, with results over 1500ms filtered out:
You can immediately see that Worker results are tightly clustered around the x-axis, Continue reading
If you followed part one, I have an environment setup where I can write Typescript with tests and deploy to the Cloudflare Edge with npm run upload
. For this post, I want to take one of the Worker Recipes further.
I'm going to build a mini HTTP request routing and handling framework, then use it to build a gateway to multiple cryptocurrency API providers. My point here is that in a single file, with no dependencies, you can quickly build pretty sophisticated logic and deploy fast and easily to the Edge. Furthermore, using modern Typescript with async/await and the rich type structure, you also write clean, async code.
OK, here we go...
My API will look like this:
Verb | Path | Description |
---|---|---|
GET | /api/ping |
Check the Worker is up |
GET | /api/all/spot/:symbol |
Aggregate the responses from all our configured gateways |
GET | /api/race/spot/:symbol |
Return the response of the provider who responds fastest |
GET | /api/direct/:exchange/spot/:symbol |
Pass through the request to the gateway. E.g. gdax or bitfinex |
OK, this is Typescript, I get interfaces and I'm going to use them. Here's my ultra-mini-http-routing framework definition:
export interface IRouter {
route(req: RequestContextBase): IRouteHandler;
}
/**
* A route
*/
export interface IRoute Continue reading
In preparation for Chrome’s Not Secure flag, which will update the indicator to show Not Secure when a site is not accessed over https, we wanted people to be able to test whether their site would pass. If you read our previous blog post about the existing misconceptions around using https, and preparing your site, you may have noticed a small fiddle, allowing you to test which sites will be deemed “Secure”. In preparation for the blog post itself, one of our PMs approached me asking for help making this fiddle come to life. It was a simple ask: we need an endpoint which runs logic to see if a given domain will automatically redirect to https.
The logic and requirements turned out to be very simple:
Make a serverless API endpoint
Input: domain (e.g. example.com)
Output: “secure” / “not secure”
Logic:
if http://example.com redirects to https://example.com
Return “secure”
Else
Return “not secure”
One additional requirement here was that we needed to follow redirects all the way; sites often redirect to http://www.example.com first, and only then redirect to https. That is an additional line of code I was prepared to handle.
I’ve done some Continue reading
Less than one month from today, on July 23, Google will start prominently labeling any site loaded in Chrome without HTTPS as "Not Secure".
When we wrote about Google’s plans back in February, the percent of sites loaded over HTTPS clocked in at 69.7%. Just one year prior to that only 52.5% of sites were loaded using SSL/TLS—the encryption protocol behind HTTPS—so tremendous progress has been made.
Unfortunately, quite a few Continue reading
Cloudflare Workers allows you to quickly deploy Javascript code to our 150+ data centers around the world and execute very close to your end-user. The edit/compile/debug story is already pretty amazing using the Workers IDE with integrated Chrome Dev Tools. However, for those hankering for some Typescript and an IDE with static analysis, autocomplete and that jazz, follow along to see one way to set up a Typescript project with Webstorm and npm run upload your code straight to the edge.
My environment looks like this:
You'll also need a Cloudflare domain and to activate Workers on it.
I'll be using cryptoserviceworker.com
I'll also use Yeoman to build our initial scaffolding. Install it with npm install yo -g
Let's start with a minimal node app with a "hello world" class and a test.
mkdir cryptoserviceworker && cd cryptoserviceworker
npm install generator-node-typescript -g
yo node-typescript
That generator creates the following directory structure:
drwxr-xr-x 16 steve staff 512 Jun 18 20:40 .
drwxr-xr-x 10 steve staff 320 Jun 18 20:35 ..
-rw-r--r-- 1 steve staff 197 Jun 18 20:40 .editorconfig
-rw-r--r-- 1 steve staff Continue reading
The drafting of the new EU Copyright Directive was never going to be an easy task. As has been seen over the years, policy discussions involving digital service providers and the intellectual property rights community are often polarizing, and middle ground can be difficult to find. However, the existing legal framework – which dates from 2001 - needed a refresh, in order to take account of the new online environment in which user-generated content is a key feature, while acknowledging the challenges that authors face and their need for fair remuneration.
Unfortunately, as is now so often the case in Brussels, the new law is being drafted with a small set of large Internet companies in mind. This blinkered approach to rule-making frequently results in unintended and negative consequences for other parts of the Internet ecosystem, and indeed for end users, many of whom are often unaware that such policies are being created.
The draft copyright proposal has been undergoing EU Parliamentary and Council scrutiny since it was tabled by the European Commission in 2016, and it has been heavily criticised by civil society organisations, numerous industry associations, renowned academics and Continue reading
A brief introduction to bundling your Service Worker scripts.
Photo by Joyce Romero / Unsplash
// The simplest Service Worker: A passthrough script
addEventListener('fetch', event => {
event.respondWith(fetch(event.request))
})
The code above is simple and sweet: when a request comes into one of Cloudflare’s data centers, passthrough to the origin server. There is absolutely no need for us to introduce any complex tooling or dependencies. Nevertheless, introduce we will! The problem is, once your script grows even just a little bit, you’ll be tempted to use JavaScript’s fancy new module system. However, in doing so, you’ll have a little bit of trouble uploading your script via our API (we only accept a single JS file).
Throughout this post, we’ll use contrived examples, shaky metaphors, and questionably accurate weather predictions to explain how to bundle your Service Worker with Webpack.
Let’s just say Webpack is a module bundler. That is, if you have code in multiple files, and you tie them together like this:
// Import the CoolSocks class from dresser.js
import { CoolSocks } from './dresser'
import { FancyShoes } from './closet'
Then you can tell webpack to follow all of those Continue reading
Our Workers platform can be used for a ton of useful purposes: for A/B (multivariate) testing, storage bucket authentication, coalescing responses from multiple APIs, and more. But Workers can also be put to use beyond "HTTP middleware": a Worker can effectively be a web application in its own right. Given the rise of 'chatbots', we can also build a Slack app using Cloudflare Workers, with no servers required (well, at least not yours!).
We're going to build a Slack bot (as an external webhook) for fetching the latest stock prices.
This Worker could also be adapted to fetch open issues from GitHub's API; to discover what movie to watch after work; anything with a REST API you can make query against.
Nevertheless, our "stock prices bot":
/stocks MSFT
as a shorthand.Using the cache allows you to improve your bot's response times across all invocations of your Worker. It's also polite Continue reading
Images courtesty of DroneDeploy
When we launched Workers a few months ago, much of the focus was on use cases surrounding websites running on origins that needed extra oomph. With Workers you can easily take a site, introduce a raft of personalization capabilities, A/B test changes or even aggregate a set of API responses around a range of services. In short by layering in Cloudflare Workers we can take origin websites and do transformational things.
One of the joys of a platform, is that you never know where you are going to see the next use case. Enter DroneDeploy
DroneDeploy is a cloud platform that makes it easy to collect and analyze drone imagery and data. Simply install DroneDeploy on your mobile device and connect to a DJI drone. DroneDeploy flies the drone, collects the imagery, then stitches the photos into maps.
The maps can show things like crop conditions & stress, construction project progress, or even thermal temperature ranges across vast solar farms or for search and rescue situations.
Using plant health algorithms applied to drone-generated maps, growers can pinpoint crop stress in their fields and stomp out pests, disease, or irrigation issues.
With Thermal Live Map, it’s possible Continue reading
We recently announced Argo Tunnel which allows you to deploy your applications anywhere, even if your webserver is sitting behind a NAT or firewall. Now, with support for load balancing, you can spread the traffic across your tunnels.
Argo Tunnel allows you to expose your web server to the internet without having to open routes in your firewall or setup dedicated routes. Your servers stay safe inside your infrastructure. All you need to do is install cloudflared (our open source agent) and point it to your server. cloudflared will establish secure connections to our global network and securely forward requests to your service. Since cloudflared initializes the connection, you don't need to open a hole in your firewall or create a complex routing policy. Think of it as a lightweight GRE tunnel from Cloudflare to your server.
CC BY-NC-ND 2.0 image by Carey Lyons
If you are running a simple service as a proof of concept or for local development, a single Argo Tunnel can be enough. For real-world deployments though, you almost always want multiple instances of your service running on seperate machines, availability zones, or even countries. Cloudflare’s Continue reading
Photo by NESA by Makers / Unsplash
At Cloudflare, we believe that getting new products and features into the hands of customers as soon as possible is the best way to get great feedback. The thing about releasing products early and often is that sometimes they might not be initially ready for your entire user base. You might want to provide access to only particular sets of customers that may be: power users, those who have expressed interest participating in a beta, or customers in need of a new feature the most.
As I have been meeting with many of the users who were in our own Workers beta program, I’ve seen (somewhat unsurprisingly) that many of our users share the same belief that they should be getting feedback from their own users early and often.
However, I was surprised to learn about the difficulty that many beta program members had in creating the necessary controls to quickly and securely gate new or deprecated features when testing and releasing updates.
Below are some ideas and recipes I’ve seen implemented inside of Cloudflare Workers to ensure the appropriate customers have access to the correct features.
First, a brief Continue reading
Photo by Patrick Tomasso / Unsplash
Are you based in Boston, London, or New York? There's a lot going on this month from the London Internet Summit to Developer Week New York and additional meetups in Boston and New York. Drop by our events and connect with the Cloudflare community.
Photo by The Opte Project / Originally from the English Wikipedia; description page is/was here.]
Tuesday, June 12: 6:00 pm - 8:00 pm
Location: Drift - 222 Berkley St, 6th Floor Boston, MA 02116
Join us at Drift HQ for a panel discussion on user experience, developer experience, and integration, featuring Elias Torres from Drift and Connor Peshek and Ollie Hsieh from Cloudflare.
The panelists will speak about their experiences developing user-facing applications, best practices they learned in the process, the integration of the Drift app and the Cloudflare Apps platform, and future platform features.
View Event Details & Register Here »
Photo by Luca Micheli / Unsplash
Thursday, June 14: 9:00 am - 6:00 pm
Location: The Tobacco Dock - Wapping Ln, Continue reading
In case you haven’t heard yet, Cloudflare launched a privacy-first DNS resolver service on April 1st. It was no joke! The service, which was our first consumer-focused service, supports emerging DNS standards such as DNS over HTTPS:443 and TLS:853 in addition to traditional protocols over UDP:53 and TCP:53, all in one easy to remember address: 1.1.1.1.
As it was mentioned in the original blog post, our policy is to never, ever write client IP addresses to disk and wipe all logs within 24 hours. Still, the exceptionally privacy-conscious folks might not want to reveal their IP address to the resolver at all, and we respect that. This is why we are launching a Tor hidden service for our resolver at dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion and accessible via tor.cloudflare-dns.com.
NOTE: the hidden resolver is still an experimental service and should not be used in production or for other critical uses until it is more tested.
Imagine an alternative Internet where, in order to connect to www.cloudflare.com, instead of delegating the task of finding a path to our servers to your internet provider, you had to go through the following Continue reading
Photo of Indian Spices, by Joe mon bkk. Wikimedia Commons, CC BY-SA 4.0.
Share your Cloudflare Workers recipes with the Cloudflare Community. Developers in Cloudflare’s community each bring a unique perspective that would yield use cases our core team could never have imagined. That is why we invite you to share Workers recipes that are useful in your own work, life, or hobby.
We’ve created a new tag “Recipe Exchange” in the Workers section of the Cloudflare Community Forum. We invite you to share your work, borrow / get inspired by the work of others, and upvote useful recipes written by others in the community.
Recipe Exchange in Cloudflare Community
We will be highlighting select interesting and/or popular recipes (with author permission) in the coming months right here in this blog.
Cloudflare Workers let you run JavaScript in Cloudflare’s hundreds of data centers around the world. Using a Worker, you can modify your site’s HTTP requests and responses, make parallel requests, or generate responses from the edge. Cloudflare Workers has been in open beta phase since February 1st. Read more about the launch in this blog post.
Today we’re excited to announce the official GA of Rocket Loader, our JavaScript optimisation feature that will prioritise getting your content in front of your visitors faster than ever before with improved Mobile device support. In tests on www.cloudflare.com we saw reduction of 45% (almost 1 second) in First Contentful Paint times on our pages for visitors.
We initially launched Rocket Loader as a beta in June 2011, to asynchronously load a website’s JavaScript to dramatically improve the page load time. Since then, hundreds of thousands of our customers have benefited from a one-click option to boost the speed of your content.
With this release, we’ve vastly improved and streamlined Rocket Loader so that it works in conjunction with mobile & desktop browsers to prioritise what matters most when loading a webpage: your content.
To put it very simplistically - load time is a measure of when the browser has finished loading the document (HTML) and all assets referenced by that document.
When you clicked to visit this blog post, did you wait for the spinning wheel on your browser tab to start reading this content? You Continue reading
On May 31, 2018 we had a 17 minute outage on our 1.1.1.1 resolver service; this was our doing and not the result of an attack.
Cloudflare is protected from attacks by the Gatebot DDoS mitigation pipeline. Gatebot performs hundreds of mitigations a day, shielding our infrastructure and our customers from L3/L4 and L7 attacks. Here is a chart of a count of daily Gatebot actions this year:
In the past, we have blogged about our systems:
Today, things didn't go as planned.
Cloudflare’s network is large, handles many different types of traffic and mitigates different types of known and not-yet-seen attacks. The Gatebot pipeline manages this complexity in three separate stages:
The benign-sounding "reactive automation" part is actually the most complicated stage in the pipeline. We expected that from the start, which is why we implemented this stage using a custom Functional Reactive Programming (FRP) framework. If you want to know more about it, see the talk and the presentation.
At 29-05-2018 08:09:45 UTC, BGPMon (A very well known BGP monitoring system to detect prefix hijacks, route leaks and instability) detected a possible BGP hijack of 1.1.1.0/24 prefix. Cloudflare Inc has been announcing this prefix from AS 13335 since 1st April 2018 after signing an initial 5-year research agreement with APNIC Research and Development (Labs) to offer DNS services.
Shanghai Anchang Network Security Technology Co., Ltd. (AS58879) started announcing 1.1.1.0/24 at 08:09:45 UTC, which is normally announced by Cloudflare (AS13335). The possible hijack lasted only for less than 2min. The last announcement of 1.1.1.0/24 was made at 08:10:27 UTC. The BGPlay screenshot of 1.1.1.0/24 is given below:
Anchang Network (AS58879) peers with China Telecom (AS4809), PCCW Global (AS3491), Cogent Communications (AS174), NTT America, Inc. (AS2914), LG DACOM Corporation (AS3786), KINX (AS9286) and Hurricane Electric LLC (AS6939). Unfortunately, Hurricane Electric (AS6939) allowed the announcement of 1.1.1.0/24 originating from Anchang Network (AS58879). Apparently, all other peers blocked this announcement. NTT (AS2914) and Cogent (AS174) are also MANRS Participants and actively filter prefixes.
Dan Goodin (Security Editor at Ars Technica, who extensively covers malware, computer espionage, botnets, and hardware hacking) reached Continue reading
Baseball season is well underway, and to celebrate, we're excited to introduce the Cloudflare All-Stars Fantasy League: a group of fictitious sports teams that revolve around some of Cloudflare’s most championed products and services. Their mission? To help build a better Internet.
Cloudflare HQ is located just a block away from the San Francisco Giants Stadium. Each time there's a home game, crowds of people walk past Cloudflare's large 2nd street windows and peer in to the office space. The looks in their eyes scream: "Cloudflare! Teach me about your products while giving me something visually stimulating to look at!"
They asked. We listened.
The design team saw a creative opportunity, seized it, and hit it out of the park. Inspired by the highly stylized sports badges and emblems of some real-life sports teams, we applied this visual style to our own team badges. We had a lot of fun coming up with the team names, as well as figuring out which visuals to use for each.
For the next few months, the Cloudflare All-Stars teams will be showcased within the large Cloudflare HQ windows facing 2nd street and en route to Giants Stadium. Feel free to Continue reading
With more and more platforms taking the necessary precautions against DDoS attacks like integrating DDoS mitigation services and increasing bandwidth at weak points, Layer 3 and 4 attacks are just not as effective anymore. For Cloudflare, we have fully automated Layer 3/4 based protections with our internal platform, Gatebot. In the last 6 months we have seen a large upward trend of Layer 7 based DDoS attacks. The key difference to these attacks is they are no longer focused on using huge payloads (volumetric attacks), but based on Requests per Second to exhaust server resources (CPU, Disk and Memory). On a regular basis we see attacks that are over 1 million requests per second. The graph below shows the number of Layer 7 attacks Cloudflare has monitored, which is trending up. On average seeing around 160 attacks a day, with some days spiking up to over 1000 attacks.
A year ago, Cloudflare released Rate Limiting and it is proving to be a hugely effective tool for customers to protect their web applications and APIs from all sorts of attacks, from “low and slow” DDoS attacks, through to bot-based attacks, such as credential stuffing and content scraping. We’re pleased about the Continue reading