If you truly want to be impressed by Cloudflare, interview with them. Every employee knows the process is deliberate, thoughtful, and diverse in taking the time to get to know a candidate while the candidate gets to know Cloudflare. It is humbling to realize that any employee interviewing has also passed through this challenging process. It all starts with a phone call, as most interviews do, and the process is fairly standard until you reach the onsite, when things begin to deviate from the norm.

I arrived for my onsite interview and was greeted by the front desk team with such enthusiasm as they smiled, laughed amongst each other, and jammed to Hall & Oates. Right away, I felt relieved, comfortable, and even more so, excited. I interviewed with seven employees that day, as I answered different questions about myself, asked them anything from “How would you describe Cloudflare to your grandmother?” to “What is a DDoS attack?”, and left knowing a great deal about the Internet and the company. The interview felt more like an open classroom with encouraging professors and less like a small, sterile examination room. I left the office energetic, a rare feeling after the usual grueling onsite [to which] I had become accustomed. Weeks later after starting my new job at Cloudflare, I realized that the onsite interview perfectly mimics the learning environment and leadership style of Cloudflare co-founders, Matthew Prince and Michelle Zatlyn.

After hearing that I had been moved on to the next stage, I was able to speak with the Head of People, Janet Van Huysse. The thing I remember most from my conversation with Janet is talking about weaknesses. Janet asked me the daunting question, “What’s your biggest weakness?” adding, “but a true weakness, not just something that can be spun into a strength”. I answered truthfully and we moved on. This struck me as very real, a genuine conversation between two people getting to know each other rather than feeling like I was under a microscope. In the past, most interviews involving that question were dragged on as the interviewee is split between being honest and wanting to sound competent and this was not that case. Despite her chaotic schedule, Janet was intentional about trying to get to know me. I still look back at that conversation as the turning point in knowing I was “all-in” for Cloudflare.

Me (front and center) and some of my colleagues on the Recruiting Team

The last step in the interview process was a final call. Cloudflare gives candidates the unique opportunity to interview a member of their executive team as a last stage. This stage is essentially a confirmation on both ends that working at Cloudflare is the best fit for the candidate and for the company. I was told that my final call was with Matthew Prince, the CEO and Co-Founder of Cloudflare. I had only once spoken to a CEO of a 90+ sized company and thought that was a huge deal. Now I was going to speak with a CEO of a company nearly nine times as large. So yes, you could say I was nervous.

Looking back, I should not have been nervous at all. My phone call with Matthew felt like a conversation with one of my former college professors, empathetic and enlightening. The first thing he did was apologize for calling me three minutes late. During our conversation, I learned about the origins of Cloudflare, Matthew’s background, and his hopes for the future of the company. He gave me the opportunity to ask him any questions I may have and by the end of our conversation, I felt highly confident that I was a good fit for Cloudflare and vice versa.

Throughout this blog post I have referenced aspects of school life to describe my interview experience. Cloudflare is changing the game when it comes to hiring because they are converting the stale, uncomfortable process into a learning process facilitated by approachable, nonjudgmental teachers. This process is representative of the overall culture - keep asking questions, keep being curious, keep learning new things and above all, be empathetic to those that do so in return. To further prove so, the entire first week of working for Cloudflare is spent in a classroom at orientation. My new peers and I spent five days learning about internet safety, the inner workings of Cloudflare, diversity and inclusion initiatives, and how we all fit together. I previously stated, if you want to truly be impressed by Cloudflare, interview with them – but I’d like to take that a step further: if you want to learn and grow as a person, interview with Cloudflare.

That’s what happened to me just a few short weeks ago when I joined Cloudflare. The task: to create a light-up version of our Data Center map – we’re talking more than a hundred LEDs tied to the deployment state of each and every Cloudflare data center. This map will be a part of our booths, so it has to be able to travel; meaning we have to consider physical shipping and the ability to update the data when the map is away from the office. And the fun part – we are debuting it at SF Developer Week in late February (I even get to give a talk about it!) That gave me one week of software time in our San Francisco office, and a little over two and a half in the Austin office with the physical materials.

What the final LEDs will look like on a map of the world.

So what does this have to do with Serverless? Well, let’s think about where and how this map will need to operate: This will be going to expo halls and conferences, and we want it to update to show our most current data center statuses for at least that event, if not updating once a day. But we don’t need to stay connected to the information store constantly-- nor should we expect to, over conference or expo WiFi.

The data stored about each data center has two distinct categories; data relevant to the data center itself, and data about how that data center should be rendered on the map. These are relatively simple data structures, however: for a data center, we want to store what city the data center is in, the latitude and longitude, and the status. We arbitrarily assign an ID integer to each data center, which we'll use to match this data with the data in the other store. We’re not going to pick and choose which data centers we want; just pull them all down and let the microcontroller figure out how to display them.

Speaking of, this is where the data store relevant to the display comes in. LEDs are on strands numbered 0-7, and are represented by an LED numbered 0-63. We need to store the ID of the data center we created for the first store, the strand number, and the LED number in the strand.

Both of these sets of data can be stored in a key-value store, with the ID number as the key and a JSON object representing either the data center or its representative LED on the map as the value. Because of this, coupled with the fact that we do not need to search or index this data, we decided to use Workers KV data stores to keep this information.

We needed two APIs around the data centers, and we needed them fast– both in the more immediate sense of having only a few weeks to complete the project, and in the sense that we needed the data to download relatively quickly over non-ideal internet situations. We also know this map will be traveling all over the world– we'd need the API to work and have at least a decent latency no matter where the map was geographically.

This is where the hundreds of LEDs comes in handy– each one represents a data center that we could deploy serverless Workers to. We can deploy the API to the data center before we leave from the comfort of the office, and it'd be ready for us when we hit the conference floor. Workers also, unsurprisingly, work really well with Workers KV data stores; allowing us to rapidly develop APIs around our data.

In the end, we ended up with this architecture diagram; 2 Workers KV data stores, and 2 serverless Workers; all of which can be deployed across the world in order to make sure the physical map has the updated data every time we head to a new show.

In the next post in this series, we'll take a look at the physical architecture of the sign:

We'll also take a look at the system we built that uses the architecture laid out in this post that consumes this data and turns it into an LED map – so keep an eye out for it next month!

Interested in deploying a Cloudflare Worker without setting up a domain on Cloudflare? We’re making it easier to get started building serverless applications with custom subdomains on workers.dev. If you’re already a Cloudflare customer, you can add Workers to your existing website here.

Reserve a workers.dev subdomain

We're withholding answers until the start of the new year, to give you a chance to solve them without spoilers. Before we reveal the answers; if you manage to solve them, we'll be giving the first 5 people to get the answers right some Cloudflare swag. Fill out your answers and details using this form so we know where to send it.

Have fun!

UPDATE: This quiz is now closed. Thank you to everyone who's played. We have received many responses, 15 of which got all the answers right; we will shortly be sending out some swag to those who got the answers right.

NOTE: Hints, now followed with solutions, are below the questions, avoid scrolling too far if you want to avoid any spoilers.

Client says hello, as follows:

00000c07ac01784f437dbfc70800450000f2560140004006db58ac1020c843c7f80cd1f701bbc8b2af3449b598758018102a72a700000101080a675bce16787abd8716030100b9010000b503035c1ea569d5f64df3d8630de8bdddd1152e75f528ae577d2436949ce8deb7108600004400ffc02cc02bc024c023c00ac009c008c030c02fc028c027c014c013c012009f009e006b0067003900330016009d009c003d003c0035002f000a00af00ae008d008c008b010000480000000b000900000663666c2e7265000a00080006001700180019000b00020100000d0012001004010201050106010403020305030603000500050100000000001200000017000052305655494338795157524c656d6443436c5246574651675430346754456c4f52564d674e434242546b51674e513d3d

[Raw puzzle without text wrap]

A user has an authenticator device to generate one time passwords for logins to their banking website. The implementation contains a fatal flaw.

At the following times, the following codes are generated (all in GMT/UTC):

• Friday, 21 December 2018 16:29:28 - 084342

• Saturday, 22 December 2018 13:11:53 - 411907

• Tuesday, 25 December 2018 12:15:03 - 617041

What code will be generated at precisely midnight of the 1st of January 2019?

At Cloudflare, we just setup RPKI: we signed a few hundred prefixes in order to reduce route leaks. But some of the prefixes hide a secret message. Find the ROAs that look different, decode the word!

This challenge has 3 hints, as follows:

• Challenge is based on a network capture

• https://blog.cloudflare.com/encrypted-sni/

• What's weird about the Frame?

The Time-Based One-Time Password Algorithm is described in RFC 6238, which was based of RFC4226 (providing an algorithm for HOTP). The TOTP algorithm requires input of two important parameters, the time and a shared secret - could one be missing?

The implementation used to generate the TOTP codes for the challenge uses SHA-1 as a digest algorithm.

Note: This challenge will no longer be valid after mid-January 2019.

This challenge has 4 hints, as follows:

• Hint #0: Four or six? Probably six.

• Hint #1: If only there was a way of listing only our IPs!

• Hint #2: What is the only part of the ROA where we can hide information into

• Hint #3: Subtract the reserve, the char will show itself

If you prefer video form, someone has created a YouTube video of the how to solve the problems, else the written solutions are below:

The string was (mostly) a capture from Wireshark of a Client Hello frame in TLS 1.2 handshake; as such, it reveals the Server Name where the connection is intended to go; in this case cfl.re.

There is a string suffixed to this hex stream which shouldn't be there; it's a base64 encoded string 




R0VUIC8yQWRLemdCClRFWFQgT04gTElORVMgNCBBTkQgNQ==. Decoding this string reveals:

GET /2AdKzgBTEXT ON LINES 4 AND 5

Accordingly; https://cfl.re/2AdKzgB redirects to https://www.cloudflare.com/robots.txt; on lines 4 and 5 is the phrase: "Dear robot be nice".

The GET request would obviously ordinarily not be appended to the Client Hello like this; however SNI information would be. You can find more about the work Cloudflare is doing to encrypt such information, so attackers cannot see which site you're visiting, in the following post: Encrypting SNI: Fixing One of the Core Internet Bugs

For this part, I'm going to use the pyotp library to demonstrate how the challenge is set-up:

>>> import pyotp>>> totp = pyotp.TOTP('')>>> print totp.at(1545409768)084342>>> print totp.at(1545484313)411907>>> print totp.at(1545740103)617041

Note that the argument to the TOTP function is set to an empty string, this means that there is no secret in place; and the one time passwords are generated solely from a hash of the time. Accordingly, a TOTP with the timestamp generated at midnight on New Year is 301554.

Whilst this may seem like a somewhat incredulous position for a developer to end up in - searching GitHub, I was even able to find implementations that used the default secret (base32secret3232) for all users wanting to authenticate to a website. This means that any other user's One Time Password is valid for any other account, and the secret could likely be breached fairly easily (as it isn't randomly generated).

Cloudflare can only generate ROAs based on their prefixes. The IPv6 prefixes are listed here: https://cloudflare.com/ips-v6.

Using any RPKI validated prefix list (https://rpki.cloudflare.com/rpki.json, or using the GUI of the RIPE’s RPKI Validator), test out our IPv6 prefixes. Some of them will appear coming from Reserved ASNs for Private Use:

• 2803:f800:cfcf:cfcf:cfcf:cfcf:cfcf:1 - B

• 2803:f800:cfcf:cfcf:cfcf:cfcf:cfcf:2 - R

• 2803:f800:cfcf:cfcf:cfcf:cfcf:cfcf:3 - A

• 2803:f800:cfcf:cfcf:cfcf:cfcf:cfcf:4 - V

• 2803:f800:cfcf:cfcf:cfcf:cfcf:cfcf:5 - O

Subtract 4200000000, it will give you one byte for each character of the secret word.

Repeat until the word is decoded.

Interested in helping build a better internet and drive security online? Cloudflare is hiring.

If you've not heard of Lorem Ipsum, it's an extract from a latin poem that designers use as placeholder text when designing the layout of a document. There are generators all over the web that will spit out as much text as you need.

Source: Wikipedia

Of course, the web being the web that we all love, there are also endless parodies of Lorem Ipsum. You can generate Hodor Ipsum, Cat Ipsum and Hipster Ipsum. I have a new, undisputed favourite: Bob Ross Ipsum.

Not growing up in the U.S., I hadn't come across the lovable, calm, serene and beautiful human that is Bob Ross. If you haven't spent 30 mins watching him paint a landscape, you should do that now. He built a following as host of the TV show “The Joy of Painting” which ran on the U.S. PBS channel from 1983-1994. He became famous for his relaxed approach to painting and his catch phrases like “Happy Little Trees”

Here's a sneak peek of the sort of language you'll hear. I feel better already!

Remember how free clouds are. They just lay around in the sky all day long. These things happen automatically. All you have to do is just let them happen. There are no mistakes. You can fix anything that happens. Volunteering your time; it pays you and your whole community fantastic dividends. You create the dream - then you bring it into your world. You can do anything here - the only prerequisite is that it makes you happy. A tree needs to be your friend if you're going to paint him. Nice little clouds playing around in the sky. Pretend you're water. Just floating without any effort. Having a good day. Nature is so fantastic, enjoy it. Let it make you happy.

OK, so it turned out the distressed engineer always uses Bob Ross Ipsum when he's building UIs. But the site was down!

My guess is the site got popular enough that the VPS wasn't worth paying, or the hosting provider didn't appreciate the traffic. As a well-trained Cloudflarian, my initial response was:

OK Step 1, stand on the shoulders of giants. Has anyone open sourced a Bob Ross Lorem Ipsum Generator?

$npm search "bob ross"
NAME                      | DESCRIPTION          | AUTHOR          | DATE       | VERSION  | KEYWORDS       
postcss-bob-ross-palette  | Bring a little Bob…  | =jonathantneal  | 2015-12-01 | 1.0.1    | postcss css pos
bob-ross                  | Bob Ross Color…      | =azz            | 2017-02-14 | 1.0.0    | Bob Ross Color 
hubot-ross                | A hubot script to…   | =tcrammond      | 2015-03-31 | 1.0.1    | hubot hubot scr
bob-ross-lipsum           | Phrases from Bob…    | =forresto       | 2016-01-15 | 1.1.1    | lorem ipsum

Of course they have! And the code is delightfully simple:

function getPhrase () {
  return phrases[Math.floor(Math.random()*phrases.length)]
}

function getPhrases (length) {
  if (!length) length = 1
  var happyPhrases = []
  for (var i=0; i<length; i++) {
    happyPhrases.push(getPhrase())
  }
  return happyPhrases.join(' ')
}

// Compiled by http://www.bobrosslipsum.com/ 2016 January
var phrases = [...elided for clarity...]

Assuming we've registered a domain and put it on Cloudflare, let's see how quickly can we get a globally distributed, highly available API running in 150+ data centers, to generate some Bob Ross Lorem Ipsum.

I'm going to:

1. Launch workers

2. Confirm I get console output

3. Put a test response

4. Paste in my code to generate Bob Ross Lorem Ipsum

5. Test it out

6. Add a route

7. Save*

8. Request it in the browser

* This pushes it to 150+ data centers... no biggie.

So it takes about 90 secs to build a basic Worker serving dynamically generated text from the Edge. It blows me away just how productive you can be with Cloudflare Workers. With a few clicks, we have code deployed to 150+ data centers and within 10ms of 90% of the world's Internet population. And it's fast.

The more I use it, the more it reminds of Heroku, and how ease-of-deployment and the developer experience really drove adoption of that platform.

OK, so generating dynamic text is OK for an MVP, it would be nice if we at least had a UI and some options. You can use Webpack to bundle resources in your Workers, but I wanted this app to be as simple as possible, so I created a basic HTML page to capture some options, included my HTML as a string, and served it from the root of my Worker. The full code listing is on  Github.

const ui = '...basic html page...';

async function handleRequest(request) {

    let url = new URL(request.url);
    //Serve the UI
    if (url.pathname === "/" ) {
        let init = { "status" : 200 , "headers" : { 'Content-Type': 'text/html' } };
        return new Response(ui, init);
    }

    let phraseCount = Math.min(parseInt(url.searchParams.get("phrases") || 100), 10000);
    let newLine = Math.min(parseInt(url.searchParams.get("newline") || 0), 10000);

    let phraseArr = getPhrasesArr(phraseCount);
    if (newLine > 0) {
        phraseArr = breakLines(phraseArr, newLine);
    }
    return new Response(phraseArr.join(''));
}

The team is now unblocked. Development can continue. Here's the full version in action. You can play with it live at: https://www.bobrossloremipsum.com

Want to join a rocketship? I’m hiring in Austin and San Francisco

Cloudflare’s mission is to help build a better Internet. To do that we operate datacenters across the globe. By having datacenters close to end user we provide a fast, secure experience for everyone. Today I’d like to talk about our datacenters in Africa and our plans to serve a population of 1.2 billion people over 58 countries.

Internet penetration in developed countries skyrocketed since the 2000s, Internet usage is growing rapidly across Africa. We are seeing a 4% to 7% increase in traffic month on month. As of July 2018, we have 8 datacenters on the African Continent:

• Angola

• Djibouti

• Egypt

• Kenya

• Mauritius

• Three in South Africa

While we see changes on the horizon, the majority of Internet content providers are located in North America and Western Europe. This means that only the billion people living in those areas close to the content they are trying to reach. When it comes to Africa, submarine cables will usually bring back the packets to Europe to hubs like Marseille, Paris, London, Lisbon and sometimes Frankfurt or Amsterdam, adding precious milliseconds, slowing down communications.

By setting up datacenters on the African continent, Cloudflare is able to serve content locally, increasing download speed in the region, improving the end-user experience, and ultimately increasing Internet usage.

We wondered if the Internet usage increased when we set-up a datacenter in a region which was previously not well served.

It was surprising to see a fast growth in the following months in each of the countries we turn on our equipment. We took into account bandwidth and also quantity of information exchanged. The increase in bandwidth usually leads to an increase in usage.

Bandwidth is the maximum rate information can be transferred over a link. The interpretation of maximum depends on the type of transmission.

The explanation why the rate is dependent on latency comes from the TCP protocol specification on which run most of the web applications. Every transmission ends with an acknowledgement, to determine if the data was correctly received. The next transmission will begin after the sender receives the acknowledgement. This means while the acknowledgement is transmitting, nothing is actually being received. The difference of data received over time is the transfer rate.

This is summarized in the following diagram:

With the most common algorithms, the amount of data sent before an acknowledgment increases until an error appears. Any link will drop packets: whether there is a transmission issue (wireless and perturbations) or a processing issue (router dropping packets to reduce load). This contributes never reaching the maximum bandwidth of a link. This is why above 80 milliseconds latency, performances start to worsen drastically. Coast to coast in the USA is around 70 milliseconds. Paris to London is 10 milliseconds. Satellites connections implement proxies to allow sustainable throughput despite 600 milliseconds round-time-trip.

The explanation is behavioral. If an Internet connection is slow and frustrating, chances are we will use it only if we are forced to. While getting access to the content immediately, people are likely to fetch more content and click on links.

The following chart shows the growth of requests from a country after every datacenter turn up. Traffic is normalized on the latest value (July 2018).

Djibouti shows the biggest increase in traffic after the launch.

For the rest of the continent, we are seeing a steady increase in delivered traffic over the last four years.

Overall, Sierra Leone is the country which grew the most at around 8% per month. At the opposite scale, Algeria only increased its traffic by 2% per month. The mean of all those countries is 6.2% per month, which is also the Internet traffic growth of South Africa.

In comparison to Europe, North America, it will take, at the current rate, 4 years and 3 months for Africa to reach today’s traffic levels of those two continents. However, if Europe, North America keeps its current 4% growth rate, then the African continent will take approximately eight to twelve years to catch up.

Please note these estimations are not perfectly representative as Cloudflare only see a part of the Internet and the numbers also includes our growing base of customers.

The units on the vertical axis represent the growth based on the initial ratio between Europe/USA/Canada and Africa.

We analyzed the latencies between Europe and African IP addresses that hit our edge. On the following Demer map from Vasco Asturiano, the area of the country is exponentially proportional to the response time in milliseconds.

All the coastal Africa is well connected with submarines cables. The only exception is Eritrea, where the main provider (EriTel) which uses two satellite providers for its outbound links.

The island of Saint Helena is on the path of the future SAex cable, but the only connection at the moment for its 5000 inhabitants is through satellite, causing a latency of 600ms.Central African Republic also uses satellite or connections through Cameroon.

On average a packet round trip from Northern Africa to Europe will take around 50-100ms while a round trip from the South will take 250ms.

Regarding inter-African routing, Africa has only a limited number of cities where interconnection happens successfully: Johannesburg in South Africa, Nairobi in Kenya, and Djibouti with datacenters and internet exchange points. The rest of the continent is mostly split between providers which will interconnect in Europe or Asia. Chances are, a user in Cameroon talking to a user in Ghana will likely go through Paris.

Using RIPE Atlas, we are able to show inter-provider routing usually happens in Europe. Only one traceroute showed packets being exchanged in South Africa.

Traceroute to two Ghana Atlas probes from other Atlas Probes

To Ghana only via Europe

To Ghana with one through South Africa

Cloudflare and many network operators are using extensively RIPE Atlas to determine performance and troubleshoot issues. If you want to help us improve Internet quality in Africa, become a probe host here.

What you may be wondering is: what are the countries in Europe that route the African traffic? We are using an anycast network ; when a user fetch a website on Cloudflare, the packets will take the shortest path seen by the router to reach its destination. In telecommunications, the shortest path does necessarily mean geographical proximity. The selection metric of a path usually involve cost and performance.

An anycast address will have the same metric everywhere on our side. This mean a service provider having links to London and Paris will see our IP addresses originating from London datacenter and Paris datacenter. The choice between the two will only be depending on metrics set by the provider: will it cost more to reach London?

Cloudflare has a significant number of points of presence to be able to show small metric differences. Due to the density of its network in Europe, it is common to have datacenters one hop away from each others (London and Paris, Paris and Amsterdam). Our analysis of the next-hop will show a provider’s preference.

In the case of Africa, a provider can rent capacity on submarine cable to a city, for instance Lisbon, Paris, London. Ideally, the provider wants to maximize the resources it can obtain without adding more hops (costlier).

Paris, London, Amsterdam and Frankfurt have a lot of content providers and interconnections options, the differences are going to be on the content. One major bias will be the language: France will have more francophone content hosted in Parisian datacenters, it also helps running operations to if both parties speak French.

As an example case: if Paris is chosen, for the content that can only be found in London, another provider will carry the packets to London from Paris, adding one hop to the path, reducing preference. We will see the landing point in Paris.

Why isn’t the provider getting a link to London? On thing to know is any Internet link has a flat rate price plus a variable rate based on consumption.

Bandwidth within major European cities is among the cheapest in the world. The flat rate for submarine capacity is high, as a result, the quantity of content that is available from London for cheaper than Paris has to make up the difference.

If you are interested to know more about the costs of bandwidth around the world, check out this article by Nitin Rao.

The following map represents the most common Cloudflare datacenter reached for each country. The countries filled with color are where Cloudflare datacenters are. The border color indicates the destination country.

As aforementioned, we can notice most of the French-speaking countries will tend to go towards our datacenter in Paris. South Africa remains well connected with its neighbors.

Previously, we mentioned there are some content providers in South Africa and Djibouti. We took a look at the popular news and banking websites.

Over the top 200 origins of the websites (Alexa ranking) for African countries in 2017, only 42 were attached to an African country and only 10 among those were serving non-education/government content (news websites, banks).They were located mostly in South Africa and Zimbabwe.

We also took a look at our 10 millions zones behind Cloudflare. The ones that are using Afrinic IPs are hosted in the following countries:

Only four countries out of sixty four are using IPv6 in a measurable way. Egypt (1%), Kenya (2%), Gabon (2%) and Zimbabwe (9%). In each of these countries we found that only one provider that deployed IPv6 at any significant scale. Since the beginning of the year, IPv6 usage in Egypt has doubled. In Gabon, a major provider rolled IPv6 at the end of December 2017.

As Mathieu Paonessa from Group Vivendi Afrique told us, “Gabon went from 0% to 2% IPv6 in only 9 months, following the opening of our CanalBox Gabon FTTH service.”

The timeline is similar with a small ISP in Kenya and has been increasing steadily. We can maybe hope they double their IPv6 usage by the end of 2018.

Compared to the rest of the world, Belgium is still ahead with 37%, followed by India at 35%. Most European countries are above 10%. USA is 22% and Canada is 15%.

One explanation for the small number of deployments is the size of the remaining IPv4 pool of addresses.

As of July 2018, there were 36,245 /24 available (approximately 9.2 millions IPs). The total Afrinic size is 6 /8 (approximately 100 millions IPs). 9% are left.

The following graphs shows the allocations and usage of each /24 in the Afrinic allocations.

This is the Hilbert graph of Afrinic IPv4 exhaustion. It was inspired by Ben Cartwright-Cox’s blog post and used masscan and ipv4-heatmap.

Prefix

Announced (yellow) vs Available (green) vs Reserved (red)

Response to ICMP (blue = low reply, red = all reply)

41.0.0.0/8

102.0.0.0/8

105.0.0.0/8

154.0.0.0/8

196.0.0.0/8

197.0.0.0/8

We notice that even if allocated, some blocks remain dark. 102.0.0.0/8 remains the range with the most IP space left in the world.

Africa is the largest continent on earth, yet it is very lagging behind on Internet connectivity and traffic levels. Historically it's been entirely relying on its European interconnections. However we predict that its traffic will outgrow EU and US by 2027. This will be enabled by the fast deployment of local content, IPv6, and alternative submarine cables.

We are working on deploying even more points of presence in Africa and increasing our current capacity in the existing ones. Fifteen new locations in the African continent are part of our global expansion plans. These include: Algeria (Algiers), Cameroon (Yaoundé), Congo (Kinshasa), Côte d’Ivoire (Abidjan), Egypt (Alexandria), Ghana (Accra), Kenya (Nairobi), La Réunion (Sainte-Marie), Madagascar (Antananarivo), Morocco (Casablanca), Nigeria (Lagos), Tanzania (Dar es Salaam), Tunisia (Tunis), Uganda (Kampala), and Zimbabwe (Harare)

Header image source

Tweet #CloudflareAllStars

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 swing by on your way to the next Giants game, snap a pic and share with your fans.

You can also show the teams support by Tweeting out their hashtag, along with the images provided for each. Go Team Internet!

Tweet #DDoSDefendersThe Distributed Denial of Service (DDoS) Defenders are strong and undefeated. They have a flawless record of batting away malicious DDoS attacks that target millions of websites and APIs around the globe. (see DDoS Protection) #DDoSDefenders

Tweet #AthenianProjectAthenasTeam Athenas is the team for the people: they ensure that U.S. State, County, and Municipal election websites stay online for free, no matter what kind of gnarly pitches get thrown their way. (see Athenian Project) #AthenianProjectAthenas

Tweet #ArgoArgonautsThe Argo Argonauts know how to throw the fastest pitches for routing your traffic across the Internet. (see Argo Smart Routing). #ArgoArgonauts

Tweet #WAFMasonsThe Web Application Firewall (WAF) Masons are the firefighters of the Internet — there is no fire too big for this team to put out. (See Web Application Firewall) #WAFMasons

Tweet #WorkersBeesThe Workers Bees are the efficient go-getter team that can help you do the impossible on the Edge! These workers can help get anything done from detecting malicious bots to filtering logic at the Edge. (See Workers) #WorkersBees

Tweet #StreamRapidsThe Stream Rapids are up to bat and ready to knock fast and speedy video hits out of the park, and across the Internet! (see Stream) #StreamRapids

Tweet #CDNPacketsThe CDN Packets are a team of fast & strong International players — with over 150 teammates (data centers) around the world, they guarantee web content gets delivered safely and as fast as possible. (See Cloudflare CDN) #CDNPackets

Tweet #DNSResolversThe DNS Resolvers are here to lead the way to anywhere you want to go on the Internet! They're the fastest in the game and they're out to keep you (and your data) safe and private through the journey. (See 1.1.1.1) #DNSResolvers

Brought to you by the Cloudflare Brand Design team ?

Jess, Kari, London, Drew & Jenny

On 10th of April 1814, almost one hundred thousand troops fought the battle of Toulouse in Southern France. The war had ended on April 6th. Messengers delivering news of Napoleon Is abdication and the end of the war wouldn’t reach Toulouse until April 12th.

The issue was not the lack of a rapid communication system in France, it just hadn’t expanded far enough yet. France had an elaborate semaphore system. Arranged all around the French countryside were buildings with mechanical flags which could be rotated to transmit specific characters to the next station in line. When the following station showed the same flag positions as this one, you knew the letter was acknowledged, and you could show the next character. This system allowed roughly one character to be transmitted per minute, with the start of a message moving down the line at almost 900 miles per hour. It wouldn’t expand to Toulouse until 1834 however, twenty years after the Napoleonic battle.

Cappy Telegraph System

It’s should be no secret that money motivates. Stock trading presents one of the most obvious uses of fast long-distance communication. If you can find out about a ship sinking or a higher than expected earnings call before other traders, you can buy or sell the right stocks and make a fortune.

In France, it was strictly forbidden to use the semaphore system for anything other than government business however. Being such a public method of communication, it wasn’t really possible for an enterprising investor to ‘slip in’ a message without discovery. The ‘Blanc brothers’ figured out one method however. They discovered they could bribe the operator to include one extra bit of information, the “Error - cancel last transmitted symbol” control character with a message. If an operative spotted that symbol, they knew it was time to buy.

Semaphore had several advantages over an electric telegraph. For one, there were no lines to cut, making it easier to defend during war. Ultimately though, its slow speed, need for stations every ten miles or so, and complete worthlessness at night and in bad weather made its time on this earth limited.

Ships crossing the Atlantic were never particularly fast. We American’s didn’t learn of the end of our own revolution at the Treaty of Versailles until October 22nd, almost two months after it had been signed. The news came from a ship “thirty-six days out of london”.

Anyone who could move faster could make money. At the end of the American Civil War, Jim Fisk chartered high speed ships to speed to London and short Confederate Bonds before the news could reach the British market. He made a fortune.

It wasn’t long before high speed clipper ships were making the trip with mail and news in twelve or thirteen days regularly. Even then though, there was fierce competition among newspapers to get the information first. New York newspapers like the Herald and the Tribune banded together to form the New York Associated Press (now known just as the Associated Press) to pay for a boat to meet these ships 50 miles off shore. The latest headlines were sent back to shore via pigeon or the growing telegraph system.

Most of the technology used by the morse code telegraph system was built to satisfy the demands of the finance industry.

The first financial indicator was a pointer which sat above the gold exchange in New York. In our era of complex technology, the pointer system has the refreshing quality of being very simple. An operator in the exchange had a button which turned a motor. The longer he held the button down, the further the motor spun, changing the indication. This system had no explicit source of ‘feedback’, beyond the operator watching the indicator and letting go of his button when it looked right.

Soon, other exchanges were clamoring for a similar indicator. Their motors were wired to those of the Gold Exchange. This did not form a particularly reliable system. Numerous boys had to run from site to site, resetting the indicators when they came out of sync from that at the Gold Exchange.

I am crushed for want of means. My stockings all want to see my mother, and my hat is hoary from age.

— Samuel Morse, in his diary

This same technology formed the basis for the original ticker tape machines. A printing telegraph from this era communicated using a system of pulses over a wire. Each pulse would move the print head one ‘step’ on a racheting wheel. Each step would align a different character with the paper to be printed on. A longer pulse over the wire would energize an electromagnet enough to stamp the paper into the print head. Missing a single pulse though would send the printer out of alignment creating a 19th century version of Mojibake.

It was Thomas Edison who invented the ‘automatic rewinder’, which allowed the machines to be synchronized remotely. The first system used a screw drive. If you moved the print head through three full revolutions without printing anything, you would reach the end of the screw and it would stop actually rotating at a known character, aligning the printers. Printing an actual character would reset the screw. A later system of Edisons used the polarity of the wire to reset the system. If you flipped the polarity on the wire, switching negative and positive, the head would continue to turn in response to pulses, but it would stop at a predefined character, allowing you to ‘reset’ any of the printers which may have come out of alignment. This was actually a big enough problem that there is an entire US Patent Classification devoted to ‘Union Devices’ (178/41).

It will therefore be understood from the above explanation that the impression of any given character upon the type-wheel may be produced upon the paper by an operator stations at a distant point, ... simply by transmitting the proper number of electrical impulses of short duration by means of a properly-constructed circuit-breaker, which will cause the type-wheel to revolve without sensibly affecting the impression device. When the desired character is brought opposite the impression-lever the duration of the final current is prolonged, and the electro-magnet becomes fully magnetized, and therefore an impression of the letter or character upon the paper is produced.

— Thomas A. Edison, Patent for the Printing Telegraph 1870

Ticker tape machines used their own vocabulary:

IBM 4S 651/4

Meant 400 shares of IBM had just been sold for $65.25 per share (stocks were priced using fractions, not decimal numbers).

Ticker tape machines delivered a continuous stream of quotes while the market was open. The great accumulation of used ticker tape led to the famous ‘Ticker Tape parades’, where thousands of pounds of the tape would be thrown from windows on Wall Street. Today we still have ticker tape parades, but not the tape itself, the paper is bought specifically to be thrown out the window.

What’s the best way to share the stock ticker tape with a room full of traders? The early solution was a chalkboard where relevant stock trades could be written and updated throughout the day. Men were also employed to read the ticker and remember the numbers, ready to recall the most recent prices when asked.

A better solution came from the Trans-Lux company in 1939 however. They devised a printer which would print on translucent paper. The numbers could then be projected onto a screen from the rear, creating the first large stock ticker everyone could read.

Trans-lux Projection Stock Ticker

This was improved through the creation of the Trans-Lux Jet. The Jet was a continuous tape composed of flippable cards. One side of each card was a bright color while the other was black. As each card passed by a row of electrically-controlled pneumatic jets, some were flipped, writing out a message which would pass along the display just as modern stock tickers do. The system would be controlled using a shift register which would read in the stock quotes and translate them into pneumatic pulses.

The key issue with a stock ticker is you have to be around when a trade of stock you care about is printed. If you miss it, you have to search back through hundreds of feet of tape to get the most recent price. If you couldn’t find the price, the next best option was a call to the trading floor in New York. What traders needed was a way of looking up the most recent quote for any given stock.

In 1960 Jack Scantlin released the Quotron, the first computerized solution. Each brokerage office would become host to a Quotron ‘main unit’, which was a reasonably sized ‘computer’ equipped with a magnetic tape write head and a separate magnetic tape read head. The tape would continually feed while the market was open, the write head keeping track of the current stock trades coming in over the stock ticker lines. When it was time to read a stock value, the tape would be unspooled between the two heads falling into a bucket. This would allow the read head to find the latest value of the stock even as the write head continued to store trades.

Quotron Keypad

Each desk would be equipped with a keypad / printer combination unit which allowed a trader to enter a stock symbol and have the latest quote print onto a slip of paper. A printer was used because electronic displays were too expensive. In the words of engineer Howard Beckwith:

We considered video displays, but the electronics to form characters was too expensive then. I also considered the “Charactron tube” developed by Convair in San Diego that I had used at another company . . . but this also was too expensive, so we looked at the possibility of developing our own printer. As I remember it, I had run across the paper we used in the printer through a project at Electronic Control Systems where I worked prior to joining Scantlin. The paper came in widths of about six inches, and had to be sliced . . . I know Jack Scantlin and I spent hours in the classified and other directories and on the phone finding plastic for the tape tank, motors to drive the tape, pushbuttons, someone to make the desk unit case, and some company that would slice the tape. After we proved the paper could be exposed with a Xenon flash tube, we set out to devise a way to project the image of characters chosen by binary numbers stored in the shift register. The next Monday morning Jack came in with the idea of the print wheel, which worked beautifully.

The main ‘computer’ in each office was primitive by our standards. For one, it didn’t include a microprocessor. It was a hardwired combination of a shift register and some comparison and control logic. The desk units were connected with a 52-wire cable, giving each button on each unit its own wire. This was necessary because they units contained no logic themselves, their printing and button handling logic is all handled in the main computer.

When a broker in the office selected an exchange, entered a stock symbol, and requested a last price on his desk unit, the symbol would be stored in relays in the main unit, and the playback sprocket would begin driving the tape backwards over a read head at about ten feet per second, dumping the tape into the bin between the two heads (market data would continue to be recorded during the read operation). The tape data from the tracks for the selected exchange would be read into a shift register, and when the desired stock symbol was recognized, the register contents would be “frozen,” and the symbol and price would be shifted out and printed on the desk unit.

Only a single broker could use the system at a time:

If no desk units were in use, the main unit supplied power to all desk units in the office, and the exchange buttons on each unit were lit. When any broker pressed a lit button, the main unit disconnected the other desk units, and waited for the request from the selected desk unit. The desk unit buttons were directly connected to the main unit via the cable, and the main unit contained the logic to decode the request. It would then search the tape, as described above, and when it had an answer ready, would start the desk unit paper drive motor, count clock pulses from the desk unit (starting, for each character, when it detected an extra-large, beginning-of-wheel gap between pulses), and transmit a signal to operate the desk unit flash tube at the right time to print each character.

The Quotron system provided a vast improvement over a chalk board, but it was far from perfect. For one, it was limited to the information available over the ticker tape lines, which didn’t include information like the stocks volume, earnings, and dividends. A challenger named Ultronics created a system which used a similar hardwired digital computer, but with a drum memory rather than a magnetic tape.

Drum Memory

The logic was advanced enough to allow the system to calculate volume, high and low for each stock as the data was stored. Rather than store one of these expensive memory units in every brokerage, Ultronics had centralized locations around the US which were connected to brokerages and each other using 1000 bps Dataphone lines.

This system notably used a form of packet addressing, possibly for the first time ever. When each stock quote was returned it included the address of the terminal which had made the request. That terminal was able to identify the responses meant for it based on that address, allowing all the terminals to be connected to the same line.

At one time during system checkout we had a very elusive problem which we couldn’t pin down. In looking over the programs, we realized that the symptoms we were seeing could occur if an unconditional jump instruction failed to jump. We therefore asked CDC whether they had any indication that that instruction occasionally misbehaved. The reply was, “Oh, no. That’s one of the more reliable instructions,” This was our first indication that commands could be ordered by reliability.

— Montgomery Phister, Jr. 1989

Facing competition from the Ultronics quote computers, it was time for Jack Scantlin’s team to create something even more powerful. What they created was the Quotron II. The Quotron II was powered by magnetic core memory, an early form of random-access memory which allowed them to read and store any stock’s value in any order. Unfortunately there wasn’t actually enough memory. They had 24K of memory to store 3000 securities.

One stock sold for over $1000; some securities traded in 32nds of a dollar; the prices to be stored included the previous day’s close, and the day’s open, high, low, and last, together with the total number of shares traded-the volume. Clearly we’d need 15 bits for each price (ten for the $1000, five for the 32nds), or 75 bits for the five prices alone. Then we’d need another 20 for a four-letter stock symbol, and at least another 12 for the volume. That added up to 107 bits (nine words per stock, or 27,000 words for 3000 stocks) in a format that didn’t fit conveniently into 12-bit words.

Their solution was to store most of the stocks in a compressed format. Each stocks previous closing price was stored in 11 bits, and store the other four values as six bit increments from that number. Any stocks priced over $256, stocks which used fractions smaller than eighths, and too large increments, were stored in a separate overflow memory area.

The Quotron II system was connected to several remote sites using eight Dataphone lines which provided a total bandwidth of 16 kbps.

The fundamental system worked by having one 160A computer read stock prices from a punch tape (using about 5000 feet of tape a day) into the common memory. A second 160A responded to quote requests over the Dataphone lines. The remote offices were connected to bankers office using teletype lines which could transmit up to 100 words-per-minute where a device would forward the messages to the requesting terminal.

It’s somewhat comforting to learn that hack solutions are nothing new:

Once the system was in operation, we had our share of troubles. One mysterious system failure had the effect of cutting off service to all customers in the St. Louis area. Investigation revealed that something was occasionally turning off some 160A memory bits which enabled service to that region. The problem was “solved” for a time by installing a patch which periodically reinstated those bits, just in case.

The system was also notable for introducing the +/- tick to represent if a stock had gone up or down since the last trade. It also added some helpful calculated quantities such as the average price change of all NYSE stocks.

The story of Quotron II showcases the value of preparing for things to go wrong even if you’re not exactly sure how they will, and graceful degradation:

Jack Scantlin was worried about this situation, and had installed a feature in the Quotron program which discarded these common-memory programs, thus making more room for exceptions, when the market went haywire. On the day President Kennedy was assassinated, Jack remembers sitting in his office in Los Angeles watching features disappear until brokers could get nothing but last prices.

Those of us who worked on Quotron II didn’t use today’s labels. Multiprogramming, multiprocessor, packet, timesharing-we didn’t think in those terms, and most of us had never even heard them. But we did believe we were breaking new ground; and, as I mentioned earlier, it was that conviction more than any other factor that made the work fascinating, and the time fly.

It’s valuable to remember that as easy as this system might be to create with modern technology, it was a tremendous challenge at the time. “Most of us lived Quotron 12 to 14 hour days, six and a half days a week; but the weeks flew by, and before we turned around twice, five years were gone...”

Anyone who has ever been involved with the demonstration of an on-line process knows what happens next. With everyone crowded around to watch, the previously infallible gear or program begins to fall apart with a spectacular display of recalcitrance. Well so it went. We set the stage, everyone held their breath, and then the first query we keyed in proceeded to pull down the whole software structure.

NASDAQ Terminal

Feeling pressure from the SEC to link all the nation’s securities markets, the National Association of Securities Dealers decided to build an ‘automated quotation service’ for their stocks. Unlike a stock ticker, which provides the price of the last trade of a stock, the purpose of the NASDAQ system was to allow traders to advertise the prices they would accept to other traders. This was extremely valuable, as before the creation of this system, it was left to each trader to strike a deal with their fellow stock brokers, a very different system than the roughly ‘single-price-for-all’ system we have today.

The NASDAQ system was powered by two Univac 1108 computers for redundancy. The central system in Connecticut was connected to regional centers in Atlanta, Chicago, New York and San Francisco where requests were aggregated and disseminated. As of December 1975 there was 20,000 miles of dedicated telephone lines connecting the regional centers to 642 brokerage offices.

Each NASDAQ terminal was composed of a CRT screen and dedicated keyboard. A request for a stock would return the currently available bid and ask price of each ‘market maker’ around the country. The market makers where the centers where stock purchases were aggregated and a price set. The trader could quickly see where the best price was available, and call the market maker to execute his trade. Similarly, the market makers could use the terminal units to update their quotations and transmit the latest values. This type of detailed ‘per-market-maker’ information is actually still a part of the NASDAQ system, but it’s only accessible to paying members.

One thing this system didn’t do is support trading via computer, without calling the money maker on the phone (the AQ in NASDAQ actually stands for ‘Automated Quotations’, no stock purchasing capability was originally intended). This became a problem on Black Monday in 1987 when the stock market lost almost a quarter of its value in a single day. During the collapse, many money makers couldn’t keep up with the selling demand, leaving many small investors facing big loses with no way to sell.

In response the NASDAQ created the Small Order Execution System which allowed small orders of a thousand shares or less to be traded automatically. The theory was these small trades didn’t require the man-to-man blustering and bargaining which was necessary for large-scale trading. Eventually this was phased out, in favor of the nearly all computerized trading based system we have today.

Today over three trillion dollars worth of stocks are traded every month on computerized stock exchanges. The stocks being traded represent over forty billion dollars worth of corporate value. With the right credentials and backing it’s possible to gain or lose billions of dollars in minutes.

These markets make it possible for both the average citizen and billion dollar funds to invest in thousands of companies. In turn, it allows those companies to raise the money they need to (hopefully) grow.

Our next post in this series is on the history of digital communication before the Internet came along. Subscribe to be notified of its release.

/* Hide period after author */ .post-header .meta a { border-right: 5px solid white; margin-right: -5px; position: relative; } /* Post */ body { background-color: white; } pre, code { font-size: inherit; line-height: inherit; } section.primary-content { line-height: 1.6; color: black; } blockquote { padding-bottom: 1.5em; padding-top: 1em; font-style: italic; font-size: 1.2rem; } blockquote.pull-quote-centered { font-size: 1.2em; text-align: center; max-width: 100%; margin-left: auto; margin-right: auto; } blockquote blockquote { margin-left: 1em; padding-left: 1em; border-left: 5px solid rgba(0, 0, 0, 0.2); padding-bottom: 0.5em; padding-top: 0.5em; margin-bottom: 0.5em; margin-top: 0.5em; } p.attribution { color: #666; font-size: 1em; padding-bottom: 1em; } a code.year { text-decoration: underline; } figure.standard { margin: 2em 0; }

CloudFlare turns 5 years old this September. It's been an amazing ride since our launch. Before we launched at TechCrunch Disrupt on September 27, 2010, we'd signed up about 1,000 beta customers. It took us nine months to get those first customers. (By comparison, today we typically sign up 1,000 customers every 3 hours.)

Those first beta customers were instrumental. They put up with us when we were had only one data center (in Chicago). They put up with us as we brought traffic online in our next facilities in Ashburn, Virginia and San Jose, California — and had the routing challenges that came along with running a distributed network for the first time. They sent us bug reports, provided us feature requests, and were instrumental to building the foundation that grew into what is CloudFlare today.

When we launched, we wanted to feature their stories and experience about CloudFlare so we had them submit their stories by video. Here's the video we included as part of our launch presentation.

I'm proud of the fact that more than 80% of those original 1,000 customers are still using CloudFlare five years later.

As we get ready to celebrate our fifth birthday, we wanted to reach out to our customers again — now well over two million of you. Our ask is the same as the first time: make a short video and tell us what you love about CloudFlare.

We'll put together a montage of some of the videos as part of our birthday celebration. And, for the users who send us the best submissions, we'll fly you to San Francisco and put you up to be a part of our birthday celebration on Thursday, September 24th.

Thank you for helping us build CloudFlare over the last five years. We look forward to watching your videos, hearing your stories about CloudFlare, and celebrating our fifth birthday together in about a month. Until then, stay tuned for a number of announcements over the coming weeks. We're pretty sure we'll be able to top our birthday surprises of years past.

Visit our video submissions page for instructions on how to enter.

The following is a guest blog post by Michael Tomko, Production Director at The Able Few. Michael has been using CloudFlare for a number of his projects for the last few years.

A few years ago, amidst the final crunch of a project deadline, a friend and former colleague looked me directly in the eye and said, "It's like I don't even know how to build a website anymore." He was of course referring to the combination of configuration, tuning, testing, and other tedious tasks that are necessary to deploy an otherwise simple website in a world of CMS's, responsive images, and web fonts. That comment has stuck with me ever since because as a developer I often find it very difficult to stand up to the pressure of having to use the latest libraries and techniques, optimized to the hilt, just to do something very rudimentary.

Flash-forward to the night of September 30th...Having just finished watching The Voice — the TV was turned up way louder than usual — my wife and I found ourselves under siege by the roar of TV news personalities bickering about the imminent government shutdown. This obviously led to us discussing what the shutdown really meant and many comments about how ridiculous it all seemed.

I suddenly remembered the silly, single-serve websites like Is It Christmas or Is Mitt Romney The President and the idea popped into my head to see if there were any for the  #shutdown. A few minutes later, I Instagrammed a screenshot of the Hover.com results for "isthegovernmentopen.com" showing that it was in fact available. This immediately led to a smattering of "Do It!" comments and the normal "You're Insane" glare from my wife, so of course I had to go for it.

There was a big part of me though that wasn't going to do it. I really didn’t think that the typical giant "NO" was going to make it worth the time and if I was going to buy yet ANOTHER domain, it had to be worth it. That's when I re-stumbled upon this amazing, near-perfect loop of President Obama being locked out in the White House rose garden.

You see, I have a few other "giant GIF" website— Bummersauce.com and HowMuchIsMoney.com — which were created to be the perfect one-liner response to someone complaining on social media, and this GIF of the President was the absolute best response to people posting comments about the shutdown. Plus, I think that it brought a fairly unique sense of bipartisan levity to the situation.

But, this is where I had to make myself comfortable with hitting the "Easy Button", so-to-speak, and to not waste a bunch of time over-engineering the thing. I didn't need a CMS. I didn't need any special fonts. I just needed a single HTML file, a few lines of CSS, and the GIF.

Within something like 30 minutes from the time that my initial Instagram went up, I had acquired the domain, built the site, run 2 simple commands to publish it to GitHub Pages, and had it on CloudFlare's worldwide CDN. IsTheGovernmentOpen.com was built and out the door in a matter of minutes.

Originally, I thought that it would get a few hundred hits and be passed around by my friends here in St. Louis. But, by time that I went to bed that night, it already had 3,500 page views. I woke up to another 3,000 and something like 7,000 came in just during my morning commute. Immediately I knew that this was bigger than I could have expected and I was basically waiting for GitHub to call and tell me that they were shutting me/it down.

Well, about 11:30am UTC New York Magazine included the site in their government shutdown liveblog and traffic soared to something like 1200 concurrent users — and stayed that way for over 6 hours. But GitHub never called and the site stayed up.

Throughout the first two days, IsTheGovernmentOpen.com survived being simultaneously linked to by NY Magazine, Mashable, The Verge, Pophangover, the Harvard Nieman Lab, Vice, and nearly every funny GIF site imaginable, two separate posts staying on the front page of Reddit for almost 24 hours, being shared on Facebook 5,177 times, and over 3,969 tweets from many highly influential Twitter users, including Anonymous.

Up until this week, CloudFlare had been the simple DNS provider and no-assembly-required CDN that I would use to keep my annual event's site up on commodity servers, the go-to recommendation for our clients when setting up DNS for their projects, and the cool suggestion as a starting place for my peers if they were complaining about issues with their site's performance. But, throughout the onslaught that IsTheGovernmentOpen.com threw at my free CloudFlare and GitHub accounts this week, this is where I truly realized the power of CloudFlare.

It sort of felt like that scene from X-Men 2 movie when Jean Grey turned into the Phoenix to save the rest of the X-Men from being swallowed by a giant tidal wave. CloudFlare quite literally had my back and they were taking quite a punch on my behalf.

All in all, this site never would have happened if CloudFlare — and GitHub — didn't provide such simple-to-use services that were also worth using, even on the free tier. Not only did they provide a very snappy and robust experience for my users but they also kept the site up for the entire duration of giant traffic spikes.

At The Able Few, pretty much none of our projects are just simple single-serve, GIF-based websites. In fact, we don’t really even build websites at all. Working with many early-stage startups — like Fizziology, Click With Me Now, and Tunespeak — we build a lot of very complicated and seemingly never-been-done-before type of applications. It is NOT our desire to spend time setting up and maintaining the things that CloudFlare provides with just a few clicks. And, if time is money, then CloudFlare basically pays you to use their service. I like that.

If you haven't yet signed up for an account, you can be up and running in a matter of minutes and will immediately see a benefit, but if you already have an account, well then you probably know what I'm talking about.

Today Google celebrated the birthday of Bob Moog, the creator of the Moog keyboard, with an interactive doodle. If you haven't played with it, it's pretty cool. Check out, for example, this version of the Legend of Zelda theme music composed with today's doodle.

The top result when you search for Moog on Google is MoogMusic.com. The site celebrates Bob Moog's legacy and sells versions of his keyboards and other devices (including a pretty sweet iPhoneapp). Google contacted the site owners to give them notice that there was going to be a doodle four days ago. The only catch, they had to keep the information strictly confidential until the doodle went live in Australia (the first region to see new doodles every day). Oh, and, by the way, Google noted, they should prepare for a crushing load of traffic to their website.

That presented a bit of a conundrum. Moog Music turned to their web developers, a technically savvy shop called PurpleCat.net. The site was designed to handle half a million hits a day, so the team at PurpleCat spent the next threedays making several improvements to the site to increase its capacity. They migrated the site to new hardware, secured a dedicated gigabit port, migrated the mysql database to its own server, upgraded the backend of the site replacing Apache with NGINX and added layers of caching and optimizations. Needless to say, it was a busy three days for the PurpleCat team while they did all the upgrades to prepare for the traffic surge. The site, however, was on a single virtual private server (VPS) with limited resources and it didn't make sense to upgrade the whole infrastructure for a one-day spike in traffic.

As soon as the doodle went live in Australia and the embargo was lifted, PurpleCat called us at CloudFlare and explained what was about to happen. We were happy to help having had a lot of experience dealing with floods of traffic from events like these. The MoogMusic.com site went live behind CloudFlare and we saw the trafficbegin to rise.

Things were ok at first, but as the sun rose in Asia, errors started to be returned from the stressed MoogMusic.com VPS. CloudFlare's Always Online technology kicked in and served cached versions of the page, but the dynamic portions were at times inaccessible and the pages loaded slowly as our servers waited for a response or timeout from the backend. It wasn't ideal.

We knew we could help even more, so our support team worked with the folks at PurpleCat to setup Page Rules for the MoogMusic.com site. While some of the site is dynamic, large portions are relatively static. That meant a Page Rule could define the static portions -- like the front page and a history of Moog's legacy -- and instruct CloudFlare to Cache Everything, even the HTML. That means we will serve all requests to the pages that match the rule from our infrastructure without any requests getting sent to the VPS.

The results were dramatic. Approximately 92% of requests that would have previously hit the VPS were instead fielded directly by CloudFlare. We also reduced bandwidth needed to serve the requests to MoogMusic.com by more than 90%. With all the static requests offloaded to CloudFlare, the VPS had plenty of capacity to return the dynamic, uncachable HTML of the site.

MoogMusic.com is currently averaging more than 100 requests per second. (What's pretty incredible is that's less than 1/1,000th of CloudFlare's overall load.) The VPS is doing more traffic every 15 minutes than the VPS it's running on is designed to handle over 24 hours. Peter from PurpleCat sent us a nice post thanking us for our help. He also shared the following with John on our team:

your ceo will like this.we built a separate server to just serve this page up:

http://190-2.purplecat.net/

But thanks to cloudflare, we never had to put it up.

He's right, I do love that. And so does everyone else at CloudFlare. It's exactly why our whole team comes to work every day excited to solve what seem like impossible challenges... like scaling a single VPS to deal with the traffic from the Google doodle.

Last week CloudFlare received a call from the team at The Pumpkin Lady. They are currently preparing for their busiest week of the year and were looking to CloudFlare to help with their increase in traffic.As you may tell, pumpkinlady.com is a website dedicated to pumpkin carving. A talented woman has created a thriving business by offering pumpkin carving patterns to people all over the world. This online business has a global audience, attracting its largest audience from Europe.

Each year, as households look for carving inspiration, The Pumpkin Lady has to handle a large increase in traffic. October is their busiest month, typically seeing 15 times more traffic compared to the rest of the year.This year, The Pumpkin Lady started to use CloudFlare. They heard about us through our partnership with WP Total Cache. Here's what happened, in their own words, after they installed CloudFlare.

From pumpkinlady.com:I've been ecstatic over great purchases before...you know, the ones that you run out and tell all your friends about, the ones that make your day a little brighter...When I signed up with CloudFlare, however, it was more of a Quad Vente White Mocha caffeine buzz combined with Rocks You Like a Hurricane blaring to the point of speaker distortion all the while praying that there are no police around because I can't keep my foot of the gas" type of experience!Our website has been around for 13 years now and traffic has been steadily growing since year one. Along with growth, however, come the pains of greater bandwidth and CPU usage. Last year we had to make two server moves during the peak of our season to accommodate the increase in resource consumption. All in all we ended up with a drastic increase in server expenses just for September and October, not to mention the lost sales during the down time. Our business is seasonal, so that means we only have to deal with this level of traffic and resource usage for a couple of months a year. In addition to the increased server costs, we also had to invest hours of manpower to move the site back to a shared hosting environment once the traffic died down.

I was determined to set up our infrastructure this year in a way that would prevent us from having to move from the shared hosting environment. Fortunately, I came across CloudFlare. In the month of October alone, CloudFlare has saved us about 1.54 Terabytes...not Gigabytes...Terabytes! The bandwidth alone was enough to blow my mind, but I was floored when I saw the amount of requests that were saved. Out of 140,851,468 requests in the past 30 days, CloudFlare saved us 136,604,571 requests.In short, CloudFlare has provided us with the resource savings that we needed to stay in a shared hosting environment. CloudFlare is truly one of the best investments we have ever made...anyone who has not taken advantage of this company's great service is definitely missing out.

Jack Berberette ~ Vice-President ~ The Pumpkin Lady, Inc._I'm the Pumpkin Lady's hubby ~ She's the artist, I just handle the techie stuff.The Pumpkin Lady is a Pro customer which costs $20 per month. The service has saved them hundreds of dollars during this busy time. The layer of security and expanded capacity let's their team focus on delivering an awesome experience to their customers.With a week until All Hallow's Eve, if you are looking for pumpkin carving inspiration, I encourage you to check out The Pumpkin Lady. It will be online throughout the holiday!_

Fun and Games

CloudFlare Apps already cover a wide range of services: live chat, web analytics, affiliate links, and too many to list. These tools make your website better, and we support that wholeheartedly. (More coming next week!)

But after a bit of mindless fun around the office last week, we decided to lighten up a bit. This week was focused on making our website owner customers smile -- and their website visitors, too. Why the smiles?

Browser Blaster, a game you can put on your CloudFlare-powered website with a click...andthen have your visitors "blast" your website, one element at a time. (If they know your secret code!)

We didn't write Browser Blaster. The credit goes to Erik Rothoff Andersson, the young Swedish developer whose simple riff on a classic video game captivated us.

We reached out to Erik with the idea of making the game a CloudFlare App, and he thought it sounded great. We're sharing the majority of the $0.99/month revenue from Browser Blaster with Erik. Despite his generous open-source license, we enjoyed finding a way to reward inspired coding -- and we hope you feel the same.

You can try Browser Blaster on the app detail page.

We started with Erik's code, and then folks here did some nifty work, adding awesome sauce wherever possible.

1. We made Browser Blaster easy to add to your CloudFlare powered site: turn on the App, for $0.99/month.

2. Browser Blaster only shows up if your visitor knows the code. By default, the code is the classic Konami code. But we added a twist: record your own secret code. If you don't want to hide the magic, you can set Browser Blaster to Automatic Mode, visible to every site visitor at the top left.

3. We made it easy for your players to Tweet and Facebook Like your site in the game.

4. We put the game on our global content delivery network (CDN) and made sure it loads after the rest of your site. No performance hit, for guilt-free gaming!

Go turn it on and start your visitors smiling.

P.S. For those keeping track, we've got a great bunch of services lined up for next week, now that we've played our game. Stay tuned here or just watch www.cloudflare.com/apps.

www.browserblaster.com will also lead you straight to the CloudFlare App.

CloudFlare sits in front of tens of thousands of websites. In the last month, nearly 5% of the Internet's visitors passed through our network at least once. As a result, we get some sense of what's on these visitors' minds as they search for sites. The news of Osama bin Laden's death last night caused us to investigate what searches people were running that led them to a CloudFlare-powered site. As news began to trickle out on Twitter, the percentage of searches that included the term "Osama" increased.

Before President Obama addressed the world, approximately 1.5% of searches we saw included the word "Osama" as people scoured the web for information. That was up from statistically 0% of searches we see that had included "Osama" over the previous 24-hour period. There was a second peak in search traffic just after President Obama finished speaking. The graph above shows the spike in search traffic for "Osama" as well as the more steady stream of searches for "Obama" over the same period.

The pranks included wrapping Lee's desk in parcel paper, packaging Ian's desk in bubble wrap, controlling Sri's computer remotely with a foot and making my desk look like it just stepped into a flurry of sticky notes. It was a fun way to start everyone's day. Thanks Matthieu!

And then, after all the fun died down, it was Matthieu's turn to be pranked. Jason did a switch-and-bait on his keyboard that made it difficult to type in French. Jason removed the windows key that Matthieu uses to make accents when writing in French. Quel plaisir!

The stakes have been raised for next year. The planning is already underway.

Today is Groundhog Day: the day on which a groundhog (named Phil) crawls out of his hole in Punxsutawney, PA and either sees his shadow, meaning we're in for six more weeks of winter, or does not, in which case it will be an early spring. Phil's official keeper is the Punxsutawney Groundhog Club. As you'd expect, the Club has a website: www.groundhog.org.

The site gets a consistent stream of visitors during the year, but every February 2 it gets slammed.

This year, the 125th Anniversary of the Groundhog Day tradition, the Punxsutawney Groundhog Club turned to CloudFlare's free service to help keep its site online during their spike in traffic. To get a sense of the volume, below is the Analytics page for the site which shows over 2.2 million page views over the last 24 hours, spiking at nearly 300,000 per hour this morning.

We're happy to report that CloudFlare did not disappoint Phil or his loyal following. In spite of the Club's backend server crashing at one point, CloudFlare's Always Online feature kept the site online throughout the day and helped substantially decrease the server load. As Glenn Kelly, who helps administer the groundhog.org site just wrote us:

Yesterday afternoon our server experienced an outage due to increased traffic. If CloudFlare were not in place, the entire website would have been offline.

CloudFlare even kept the contents of the site available when the Club took it down for scheduled maintenance late last night. In the end, even with an enormous flood of traffic, according to Glenn there was "zero downtime." And, all the while, CloudFlare's global network helped make the site about 40% faster for visitors worldwide.

Best of all, since Phil did not see his shadow, it looks like it will be an early Spring. The entire team of CloudFlare is proud to have been a little part of bringing that news to the world.