Are you familiar with the Go programming language and looking for a job in San Francisco or London? Then think about applying to CloudFlare. We're looking for people with experience writing Go in both locations.
CC BY-SA 2.0 by Yuko Honda (cropped, resized)
CloudFlare uses Go extensively to build our service and we need to people to build and maintain those systems. We've written a complete DNS server in Go, our Railgun service is all Go and we're moving more and more systems to Go programs.
We've recently written about our open source Red October Go project for securing secrets, and open-sourced our CFSSL Go-based PKI package. Go is now making its way into our data pipeline and be used for processing huge amounts of data.
We even have a Go-specific section on our GitHub.
If you're interested in working in Go on a high-performance global network like CloudFlare, send us an email.
Not into Go? We're hiring for all sorts of other positions and technologies.
We’re pleased to introduce a new CloudFlare App: Tinfoil Security. Tinfoil Security is a service designed to find possible web application vulnerabilities.
Security is central to CloudFlare's service. Our security features operate at the network level to identify and block malicious traffic from ever reaching your website or application. However, even with that protection in place, it’s still worth fixing problems at the application layer as well.
Tinfoil Security helps website owners learn about possible vulnerabilities in their applications by scanning for vulnerabilities, tests all access points, and providing step-by-step introductions on eliminating threats if found.
Their developer-focused reports can be tied into continuous integration lifecycle with API hooks for kicking off new scans after changes are made.
Tinfoil offers several price points, including a free plan that checks for XSS (Cross-Site Scripting) concerns. The Tinfoil app is a quick and easy addition to your CloudFlare service. Take a look!
As of today, there are only about 2 million websites that support HTTPS. That's a shamefully low number. Two things are about to happen that we at CloudFlare are hopeful will begin to change that and make everyone love locks (at least on the web!).
CC BY 2.0 by Gregg Tavares
First, Google just announced that they will begin taking into account whether a site supports HTTPS connections in their ranking algorithm. This means that if you care about SEO then ensuring your site supports HTTPS should be a top priority. Kudos to Google to giving webmasters a big incentive to add SSL to their sites.
Second, at CloudFlare we've cleared one of the last major technical hurdle before making SSL available for every one of our customers -- even free customers. One of the challenges we had was ensuring we still had the flexibility to move traffic to sites dynamically between the servers that make up our network. While we can do this easily when traffic is over an HTTP connection, when a connection uses HTTPS we need to ensure that the correct certificates are in place and loaded into memory Continue reading
CC BY 2.0 from Brian Snelson
I'm pleased to announce that CloudFlare now supports WebSockets. The ability to protect and accelerate WebSockets has been one of our most requested features. As of today, CloudFlare is rolling out WebSocket support for any Enterprise customer, and a limited set of CloudFlare Business customers. Over the coming months, we expect to extend support to all Business and Pro customers.
We're rolling out WebSockets slowly because it presents a new set of challenges. The story below chronicles the challenges of supporting WebSockets, and what we’ve done to overcome them.
Before diving into WebSockets, it's important to understand HTTP—the traditional protocol of the web. HTTP supports a number of different methods by which a request can be sent to a server. When you click on a traditional link you are sending a GET request to a web server. The web server receives the request, then sends a response.
When you submit a web form (such as when you're giving your username and password when logging into an account) you use another HTTP method called POST, but the interaction is functionally the same. Your browser (called the ‘client’) sends data to Continue reading
One of the services that CloudFlare provides to paying customers is called Polish. Polish automatically recompresses images cached by CloudFlare to ensure that they are as small as possible and can be delivered to web browsers as quickly as possible.
We've recently rolled out a new version of Polish that uses updated techniques (and was completely rewritten from a collection of programs into a single executable written in Go). As part of that rewrite we looked at the performance of the recently released mozjpeg 2.0 project for JPEG compression.
To get a sense of its performance (both in terms of compression and in terms of CPU usage) when compared to libjpeg-turbo I randomly selected 10,000 JPEG images (totaling 2,564,135,285 bytes for an average image size of about 256KB) cached by CloudFlare and recompressed them using the jpegtran program provided by libjpeg-turbo 1.3.1 and mozjpeg 2.0. The exact command used in both cases was:
jpegtran -outfile out.jpg -optimise -copy none in.jpg
Of the 10,000 images in cache, mozjpeg 2.0 failed to make 691 of them any smaller compared with 3,471 for libjpeg-turbo. So mozjpeg 2.0 was significantly better at recompressing images.
On average Continue reading
With the World Cup at an end, so too is our latest round of data center expansion. Following deployments in Madrid, Milan and São Paulo, we are thrilled to announce our 28th data center in Medellin, Colombia. Most of Colombia’s 22 million Internet users are now mere milliseconds away from a CloudFlare data center.
Our deployment in Medellin is launched in partnership with Internexa, operators of the largest terrestrial communications network (IP backbone) in Latin America. Internexa operates over 28,000 km of fibre crossing seven countries in the continent. Our partnership was formed over a shared vision to build a better Internet—in this case, by localizing access to content within the region. Today, it is estimated that as much as 80% of content accessed in Latin America comes from overseas. It is with great pride that, as of now, all 2 million sites using CloudFlare are available locally over Internexa’s IP backbone. Let’s just say we’ve taken a bite out of this percentage (and latency)!
If your Internet service provider (ISP) is not connected to Internexa, Continue reading
This was an internal email that I sent to the CloudFlare team about how we are not afraid to throw away old code. We thought it was worth sharing with a wider audience.
Date: Thu, 10 Jul 2014 10:24:21 +0100 Subject: Courage to change things From: John Graham-Cumming To: Everyone Folks, At the Q3 planning meeting I started by making some remarks about how much code we are changing at CloudFlare. I understand that there were audio problems and people may not have heard these clearly, so I'm just going to reiterate them in writing. One of the things that CloudFlare is being brave about is looking at old code and deciding to rewrite it. Lots of companies live with legacy code and build on it and it eventuallybecomes a maintenance nightmare and slows the company down. Over the last year we've made major strides in rewriting parts of our code base so that they are faster, more maintainable, and easier to enhance. There are many parts of the Q3 roadmap that include replacing old parts of our stack. This is incredibly important as it enables us to be more agile and more stable in future. We should feel good Continue reading
In the coming weeks, connectivity to CloudFlare in Australia is going to a new level. As part of CloudFlare’s ongoing upgrades program, we established connections to three new Internet exchanges: the Megaport Internet exchanges in Sydney, Brisbane, and Melbourne. These connections doubled the number of Australian Internet exchanges we reach and marked the first exchanges outside of Sydney that Cloudflare participates in.
When two ISPs peer, they agree to exchange traffic directly between each other rather than sending it a third party. By doing this, both partners avoid congested paths between transit providers, and they avoid paying to ship traffic—it's win-win!
What peering exchanges mean for CloudFlare is that we can significantly increase our service performance to users on ISPs that peer with us. Take Australia for example, for users who are currently on ISPs peering at Megaport, instead of CloudFlare sending traffic to the transit providers of those ISPs, we can now route the traffic directly to them. The result is lower latency, and traffic taking paths that are often less congested.
Low latency is crucial for internet speed due to the nature of TCP, the fundamental protocol on which the internet is built. TCP operates Continue reading