One of the great benefits of the Internet has been its ability to empower activists and journalists in repressive societies to organize, communicate, and simply find each other. Ten years ago today, Cloudflare launched Project Galileo, a program which today provides security services, at no cost, to more than 2,600 independent journalists and nonprofit organizations around the world supporting human rights, democracy, and local communities. You can read last week’s blog and Radar dashboard that provide a snapshot of what public interest organizations experience on a daily basis when it comes to keeping their websites online.

We’ve admitted before that Project Galileo was born out of a mistake, but it's worth reminding ourselves. In 2014, when Cloudflare was a much smaller company with a smaller network, our free service did not include DDoS mitigation. If a free customer came under a withering attack, we would stop proxying traffic to protect our own network. It just made sense.

One evening, a site that was using us came under a significant DDoS attack, exhausting Cloudflare resources. After pulling up the site and seeing Cyrillic writing and pictures of men with guns, the young engineer on call followed the playbook. He pushed a button and sent all the attack traffic to the site’s origin, effectively kicking it off the Internet.

This was in 2014, during Russia’s first invasion into Ukraine, when Russia invaded Crimea. What the engineer did not know was that he had just kicked off an independent Ukrainian newspaper that was covering the attack and the invasions. The newspaper had tried to pay for services with a credit card but failed because Russia had targeted Ukraine’s financial infrastructure, taking banking institutions offline. It wasn’t the engineer’s fault. He had no reason to know that the site was important, and no alternative playbook to follow.

After that incident, we vowed to never let an organization that was serving such an important purpose go offline simply because they couldn’t pay for services. And so the idea for Project Galileo was born.

Although the idea of providing free security services was straightforward, figuring out which organizations are important enough to deserve such services was not. We know we can’t build a better Internet alone – it’s why Cloudflare’s mission is to help build a better Internet. So with Project Galileo, we sought the assistance of a group of civil society organizations to partner with us and help identify the organizations that need our protection.

Repression of ideas that were threatening to authority hardly started with DDoS attacks or the invention of the Internet. We named the effort Project Galileo after the story of Galileo Galilei. Galileo was persecuted in the 1600s for publishing a book concluding that the Earth was not at the center of the universe, but that the Earth orbits the sun. After Galileo was labeled a heretic, his book was banned and his ideas were suppressed for more than 100 years.

Four hundred years after Galileo, we see attempts to suppress the online voices of journalists and human rights workers who might challenge the status quo. We’re proud of the fact that through Project Galileo, we keep so many of those voices online.

Ten years after the launch of Project Galileo, Cloudflare has changed a lot. Our network has grown from data centers in fewer than 30 cities in 2014 to a network that runs in 320 cities and more than 120 countries. We’ve massively expanded our product suite to include whole new lines of products, including a full set of Zero Trust services and a developer suite that enables developers to build a wide range of applications, including AI applications, on our network.

As Cloudflare has grown, so has Project Galileo. We have more than quadrupled the number of entities we protect in the last five years, from 600 at Project Galileo’s five-year anniversary to more than 2,600 today, located in 111 different countries. We’ve expanded from our original 14 civil society partners to 54 today. Our partners span countries, continents, and subject matter areas, sharing their expertise on organizations that would benefit from cybersecurity assistance.

When we expand our product offerings, we routinely ask whether new services would be valuable to the journalists, humanitarian groups, and nonprofits that benefit from Project Galileo. After Cloudflare launched our Zero Trust offering, we announced that we would offer those services for free to participants in Project Galileo to protect themselves against threats like data loss and malware. After Cloudflare acquired Area 1, we announced that we would offer Cloudflare’s email security products for free to the same participants.

We’ve tried to make our products easy for a small organization to use, building a Social Impact Portal and a Zero Trust roadmap for civil society and at-risk communities. Cloudflare’s teams also help participants onboard and troubleshoot when they face challenges.

On June 6, we celebrated Project Galileo’s 10-year anniversary with partners from government, civil society, and industry at an event in Washington, DC. We used the opportunity to talk about the future of the Internet, and how we can all work together to protect and advance the free and open Internet.

For humanitarian organizations with few resources, the types of services offered under Project Galileo can be life changing. At our Project Galileo event, we heard the story of a small French nonprofit that lost 17 years of data after being targeted by ransomware. Our resources help organizations defend themselves not only against nation states determined to take them offline, but also against common ransomware and phishing attacks.

During our event, the President of the National Endowment for Democracy (NED) told the story of traveling in the Western Balkans where the struggle for an independent media is palpable. NED is a strong supporter of media outlets across the region. But those media outlets come under frequent cyber attacks that have incapacitated their websites. As described by Damon Wilson:

Those attacks prevent news from reaching the public, where information is very much something that is used and weaponized against communities across Bosnia. And this was precisely the case with one of our partners, Buka. It's a news outlet that's based in Banja Luka and Republika Srpska. And while I was there, I met with some of our partners from Banja Luka who had been physically beaten up and intimidated. There's a crackdown on civil society, new restrictions and laws against them. But for Buka, it was a little bit of a different scenario because earlier this year they suffered a DDoS attack, during which their server servers were overwhelmed by up to 700 million page requests. And the sheer volume suggests the attackers had significant resources, making it a particularly severe threat.

But by onboarding Buka into Project Galileo, we were able to help them restore their site’s functionality, and now Buka’s website is equipped to withstand even the most sophisticated attacks, ensuring that their critical reporting continues uninterrupted, exactly at the time when the Republic gets Covid, Republika Srpska government is looking to close and restrict independent civic voices in that part of Bosnia.

And this is just one example. Last week, traveling in Bosnia, of the numerous NED partners who've benefited from Cloudflare's Project Galileo since NED became a partner in 2019, it's profound to the efficacy of our partners’ work. It effectively ensures that bad actors can't silence the voices and the work of democracy advocates and independent media around the world.

Our work with Project Galileo highlights the power of the partnerships that we’ve built, not only with civil society, but with government and industry partners as well. By working together, we can expand protections for the many at-risk organizations that need cybersecurity assistance. Cybersecurity is a team sport.

In 2023, one of our Project Galileo partners, the CyberPeace Institute, approached us about doing even more to help protect nonprofit organizations against phishing attacks. The CyberPeace Institute collaborates with its partners to reduce the harms from cyberattacks on people’s lives worldwide and provide them assistance. CyberPeace also analyzes cyberattacks to expose their societal impact, to demonstrate how international laws and norms are being violated, and to advance responsible behavior in cyberspace.

CyberPeace realized that there was an opportunity to document attacks against civil society groups and improve the ecosystem for everyone. Many development and humanitarian organizations are small, with limited staff and little cybersecurity experience. They can easily fall prey to common cyber attacks – like phishing – designed to access their systems or steal their data. If they manage to use tools effectively to defend themselves, they do not typically report on the information about the attacks they see.  

CyberPeace proposed to help onboard development and humanitarian organizations to Cloudflare services through their CyberPeace Builders program and analyze the phishing campaigns targeting those organizations. The substantive insights and information gained from that work could then be fed to other civil society organizations as real time security alerts. Cloudflare worked with CyberPeace to develop the new approach, enabling their volunteers to onboard organizations in their network to Area 1 tools and their analysts to access threat indicators from the collective organizations onboarded.  

Government can play an important role in helping protect civil society from cyberattacks as well. Since the Summit for Democracy last year, Cloudflare has been working closely with the Joint Cyber Defense Collaborative (JCDC), which is run by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), on their High-Risk Communities initiative. Earlier this year, JCDC launched a web page outlining cybersecurity resources for civil society communities facing digital security threats because of their work. The effort includes tools and services that nonprofits can use to secure themselves online, including those offered under Project Galileo.

In many ways, the creation of Project Galileo altered the trajectory of the company. Project Galileo cemented the idea that protecting and keeping important organizations online, regardless of whether they could pay us, was part of Cloudflare’s DNA. It pushed us to innovate to improve security not only for the large enterprises that pay us, but for the small organizations doing good for the world that cannot afford to pay for the latest technological innovation. It gave us our mission – to help build a better Internet – and a standard to live up to and measure ourselves against.

To meet that standard, we routinely reach out to offer our services to important organizations in need. In 2022, after Russia’s invasion of Ukraine, Cloudflare jumped in to offer services to Ukrainian critical infrastructure facing a barrage of cyberattacks and have continued providing them services ever since. At our Project Galileo event, the State Department’s Special Envoy and Coordinator for Digital Freedom read an email she’d received from Ukraine’s Deputy Foreign Minister and Chief Digital Transformation officer of Ukraine the night before:

It is absolutely definite that Cloudflare services provide a vital layer of cybersecurity within the Ukrainian segment of cyberspace. Numerous DDoS attacks are directed at state electronic services, fintech, official information sources. So if there was no Cloudflare as a proven protection against DDoS attacks, it would have serious consequences causing chaos, especially when these attacks are synchronized by the enemy in parallel with kinetic attacks.

We’ve launched sections of Cloudflare Radar designed to use Cloudflare’s network to help civil society monitor Internet outages and disruptions, as well as route hijacks and other traffic anomalies. We’ve participated in the Freedom Online Coalition’s Task Force on Internet Shutdowns.

Project Galileo also helped pave the way for a variety of Cloudflare projects to provide other at-risk populations free services. These programs include:

• Athenian Project: Launched in 2017, the Athenian Project is Cloudflare’s program to protect election-related domains for state and local governments so that citizens have reliable access to information on voter registration, polling places, and the reporting of election results.

• Cloudflare for Campaigns: Launched in 2020, Cloudflare for Campaigns helps secure US political candidates’ election websites and internal data while also ensuring site reliability during peak traffic periods. The program is run in partnership with Defending Digital Campaigns.

• Project Pangea: Launched in 2021, Project Pangea is a program to provide secure, performant and reliable access to the Internet for community networks that support underserved communities.

• Project Safekeeping: Launched in 2022, Project Safekeeping supports at-risk critical infrastructure entities in Australia, Japan, Germany, Portugal, and the UK by providing Zero Trust and application security solutions.

• Project Cybersafe Schools: Launched in 2023, Project Cybersafe Schools equips small public school districts in the US with Zero Trust services, including email protection and DNS filtering.

• Project Secure Health: Launched on June 10, 2024, Project Secure Health provides security tools to Australia’s general practitioner clinics to safeguard patient data and counter challenges such as data breaches, ransomware attacks, phishing scams, and insider threats.

The world has only gotten more complicated since we first launched Project Galileo in 2014. We face real challenges ranging from malicious cyber actors targeting critical infrastructure, to election interference, to data theft. Governments have responded with increasingly aggressive attempts to control aspects of the Internet. At our recent celebration of Project Galileo, we lamented the thirteenth consecutive year of decline of global Internet freedom, as documented by our Project Galileo partner Freedom House.

But one thing has not changed. We continue to believe the single, global Internet is a miracle that we should all be fighting for. We sometimes forget that the Internet is an incredibly radical concept. The world somehow came together over the last 40 years, agreed on a set of standards, and then made it so that a collection of networks could all exchange data. And that miracle that is the Internet has brought incredible opportunities for the voices of civil society to be heard, to help extend their impact, to spread their message, and to keep them connected.

Connecting everyone online in a permissionless way comes with real harms and real risks. But we need to be surgical as we address those challenges. We need to partner to find solutions that preserve the open Internet, much as we do with projects like Project Galileo. Even if we are at a moment of democratic decline, continuing to defend the open, interoperable Internet preserves space and capacity for a future in which the Internet can also fuel greater freedom.

Cloudflare launched on September 27, 2010. This week we'll celebrate our 12th birthday. As has become our tradition, we'll be announcing a series of products that we think of as our gifts back to the Internet. In previous years, these have included products and initiatives like Universal SSL, Cloudflare Workers, our Zero Markup Registrar, the Bandwidth Alliance, and R2 — our zero egress fee object store — which went GA last week.

We're really excited for what we'll be announcing this year and hope to surprise and delight all of you over the course of the week with the products and features we believe live up to our mission of helping build a better Internet.

While this will be our 12th Birthday Week of product announcements, for the last two years, as the cofounders of the company, we've also taken this time as an opportunity to write a letter publicly reflecting on the previous year and what's on our minds as we go into the year ahead.

Since our last birthday, it's been a tale of two halves of a very different year. At the end of 2021 and into the first two months of 2022, COVID infection rates were falling globally, effective vaccines were getting rolled out, and the world seemed to be returning to a sense of pre-pandemic normalcy.

Internally, we were starting to meet again in person with colleagues and customers. We'd weathered an unprecedented increase in traffic across our network caused by the pandemic and, with a few bumps along the way, used the challenges we'd faced through that time to rebuild our architecture to be more stable and reliable for the long term. We both felt optimistic for the future.

Then, on February 24, Russia invaded Ukraine. While we were fortunate to not have team members working from Russia, Ukraine, or Belarus, we have many employees with families in the region and six offices within a train ride of the front lines. We watched in real time as Internet traffic patterns across Ukraine shifted, a disturbing reflection of what was happening on the ground as cities were bombed and families fled.

At the same time, Russia ratcheted up their efforts to censor their country's Internet of all non-Russia media. While we had seen some Internet restrictions in Russia over the years, historically Russian citizens were generally able to freely access nearly any resources online. The dramatically increased censorship marked an extreme change in policy and the first time a country of any scale had tried to go from a generally open Internet to one that was fully censored.

But, even as the war continues to rage, there is reason for optimism. In spite of a significant increase in censorship inside Russia, physical links to the rest of the world being cut in Ukraine, cyber attacks targeting Ukrainian infrastructure, and Russian forces actively rerouting BGP in invaded regions, by and large the Internet has continued to flow. As John Gilmore once famously said: "The Internet sees censorship as damage and routes around it."

The private sector and governments around the world came together to help support Ukraine and render Russian cyberattacks largely moot. Our team provided our services for free to government, financial services, media, and civil society organizations that came under cyber attack, ensuring they stayed online. As the physical Internet links were severed in the country, our network teams worked to route traffic through every possible path to ensure not only could news from outside Ukraine get in but, equally importantly, pictures and news of the war could get out.

Those pictures and news of what is happening inside Ukraine continue to galvanize support. The Ukrainian government continues to function in spite of withering cyber attacks. Voices inside Russia pushing back against the regime are increasingly being heard. And ordinary Russian citizens have increasingly turned to services like Cloudflare's 1.1.1.1 App to see uncensored news, in record numbers.

Our efforts to keep the Internet on in Russia led the Putin regime to officially sanction one of us (Matthew) — a sign we took that we were making a positive impact. Today we estimate approximately 5% of all households in the country are continuing to access the uncensored Internet using our 1.1.1.1 App, and that number continues to grow.

2022 was not the first year in which the Internet became a battleground, but to us, it does feel like a turning point. In the last twelve months, we've seen more countries shut down Internet access than in any previous year. Sometimes this is just a misguided and ineffectual effort to keep students from cheating on national exams. Unfortunately, increasingly, it's about repressive regimes attempting to assert control.

As we write this, the Iranian government is attempting to silence protests in the country through broad Internet censorship. While some may suggest this is business as usual, in fact it is not. The Internet and the broad set of news and opinions it brings have generally been available in places like Iran and Russia, and we shouldn't accept that full censorship in them is the de facto status quo.

And these efforts to reign in the Internet are unfortunately not limited to Iran and Russia. Even in the liberal, democratic corners of Western Europe, incidents in which court ordered blocking at the infrastructure layer resulting in massive overblocking spiked dramatically over the last year. Those cases will set a dangerous precedent that a single court in a single country can block access to wide swaths of the Internet.

While it may seem ok to Austrians for an Austrian court to enforce Austrian values for an issue within Austria, if any country's courts can block content at the core Internet infrastructure level even when it results in the blocking of unrelated sites then it will have a global impact. And, inherently, it will open the door for Afghanistan, Albania, Algeria, Andorra, Angola, Antigua, Argentina, Armenia, Australia, and Azerbaijan to do the same. And that's just the countries that start with the letter A. If these precedents are upheld then the Internet risks falling to the lowest common denominator of what's globally acceptable.

The magic of the early Internet was that it was permissionless. Cloudflare was founded to counter an old and very different threat to that magic than we face today. Early in Cloudflare's history, we used to get asked who we were competing against. We have never thought the answer was Akamai or EdgeCast. While, from a business perspective, we always thought of our business as replacing the vast catalog of Cisco's hardware boxes with scalable services, that transition seemed inevitable. Instead, the existential competitor we faced was a threat to the permissionless Internet itself: Facebook.

If you find your eyebrow raised as you read that, know you're not alone. It was the universal reaction we’d get whenever we said that back in 2010, and it remains the universal reaction we get when we say it today. But it has always rung true. In 2010, when Cloudflare launched, it was getting so difficult to be online — between spam, hackers, DDoS, reliability, and performance issues — that many people, organizations, and businesses gave up on the web and sought a safe space in Facebook's walled garden.

If the challenges of being online weren't solved in some other way, there was real risk that Facebook would, effectively, become the Internet. The magic of the Internet was that anyone with an idea could put it online and, if it resonated, thrive without having to pass through a gatekeeper. It seemed wrong to us that if those trends continued you'd have to effectively get Facebook's permission just be online. Preserving the permissionless Internet was a big part of what motivated us to start Cloudflare.

So we set out to help solve the problems of cyberattacks, outages, and other performance challenges making sure that the Internet we believed in could continue to thrive. We built a global network able to mitigate the largest DDoS attacks easily, and to make anything connected to the Internet faster, more secure, and more reliable. We created tools to make it easy for developers to build and maintain new platforms, with the ability to deploy serverless code in an instant across the globe. We developed new ways for our customers to protect their internal systems from attack with Zero Trust services. And we made it all as widely available as possible, constantly striving to provide accessible tools not only to the Fortune 1000 but also to the small businesses, nonprofits, and developers with ideas about how to build something new, creative, and good for the world.

It's not dissimilar to the story of another disruptive tech company that began a few years before we did. Shopify has been a long time Cloudflare customer using a number of our services, including our Workers developer platform. Their unofficial rallying cry of "arming the rebels" has always resonated with us.

In many ways, Shopify is to Amazon.com as Cloudflare is to Facebook. Both of the former providing the key infrastructure you need to innovate and then getting out of your way, both of the latter building a walled garden from which they can ultimately extract maximum rents.

Shopify framing their customers as the rebels taking on the Empire of Amazon is, of course, a reference to Star Wars and so it may not be surprising that we often talk internally about the Star Wars movies as a metaphor for the history of the Internet: past, present, and maybe future.

The first movie, Episode IV, was titled "A New Hope." The plot of that movie feels a lot like how the world experienced the Internet for the 40 years prior to 2016. There was this magical thing called the Force, and it was controlled by these incredible people called Jedi. Except instead of the Force it was the Internet and instead of Jedi it was programmers and network engineers.

It's easy to forget that it's the stuff of not-too-long-ago science fiction that you could have a device in your pocket that could access the sum of all human knowledge. And yet, there are now more smartphones in active use than humans on Earth. Neither of us feel all that old, yet we both grew up in a time when if you had an opinion and wanted to get it out to a broad audience you had to write it up, send it in as a letter to the editor, and hope that it would get published.

Today in the world of Twitter and TikTok that is almost unimaginably quaint. The Internet blew that all up, just as Luke blew up the Death Star, and it's hard to overstate how much that disrupted every traditional source of power and control.

But after Episode IV came Episode V: “The Empire Strikes Back.” And make no mistake, the traditional centers of control are working hard to find ways to control the Internet. While we think the shift came somewhere around 2016, it feels like in 2022 the Empire has discovered the rebel base on Hoth and the AT-ATs are closing in.

Episode V is a pretty dark movie. Spoiler alert for the small percentage of you who may not have seen it, but the hero realizes his mortal enemy is his father, loses his hand, his rogue friend is encased in carbonite, and the girl he likes sold into slug slavery shortly after she declares her love for not him but the about-to-be-carbonite-encased friend. But it's also the best movie because the stakes are so high.

The stakes are high for the Internet too, and we believe it's important for us to engage on the hard technology and policy issues. The next several years will be challenging as we rebuild the legacy protocols of the Internet to be more private and secure by design, so they can accommodate what the Internet has become, and wrestle with hard policy issues around respecting local laws and norms on a network that is inherently global. The team at Cloudflare comes to work every day appreciating the challenges and importance of what we need to help do to live up to our mission.

Our mission is to help build a better Internet, and we are proud that more than 20% of the web and 30% of the Fortune 1,000 relies on Cloudflare to be fast, reliable, secure, efficient, and private for whatever they are doing online. Throughout the year we have Innovation Weeks usually dedicated to new products to sell to our customers. But, during our Birthday Week, we give back with products and initiatives that aren’t designed to generate revenue, but instead we provide them because they improve the fundamentals of how the Internet works.

And so this year we'll be launching new services and partnerships to make the best security practices more affordable and bring them more easily to an increasingly mobile world. We're helping developers access more resources they need to deliver the next generation of applications. And we're launching privacy-preserving alternatives to widely used services because we believe a better Internet is a more private Internet.

We're not ready to declare that it's time for the Ewoks to start dancing, but we are proud of our continued innovation and the thoughtfulness of our team as we navigate these challenging times. Although the global economy continues to provide uncertain headwinds as we head into the new year, we are confident we have the plan and the team that will make us successful.

Thank you to our team, our customers, and our investors. Happy 12th birthday to Cloudflare. And, as always: we're just getting started.

This week we celebrate Cloudflare's birthday. We launched the company 11 years ago tomorrow: September 27, 2010. It has been our tradition, since our first birthday, to use this week to launch innovative new products that we think of as our gift back to the Internet.

Since going public, it's also been an opportunity for us to update our Annual Founders' Letter and share what's on our mind. Recently we've been thinking about three things: team, the Internet, and innovation.

When anyone asks us the key to Cloudflare's success, we always say the same thing: the team we've been able to attract to help us achieve our mission of helping build a better Internet. In the last year we've had more than 250,000 people apply to work for us and extended offers to less than one half of one percent of them. We continue to attract great people.

It's incredible to realize that more than half of Cloudflare's team today started since March 13, 2020, when we closed all our physical offices due to the pandemic. In the last several months, as we've started to see a light at the end of the COVID tunnel, we've been hosting what we called Summer Socials with our team. Getting together outside, often over a picnic lunch, it's been fun to meet face-to-face people we'd only video conferenced with before. And even more fun to watch people from across the team get to know each other outside the confines of a Brady Bunch-like on-screen box.

As a company that was very much a work-from-office culture before the pandemic, we were terrified of what would happen to our culture when we switched to fully remote work. Eighteen months into this forced experiment on a new way of working we're happy to report: it's working. Really well.

It turns out what we all suspected is in fact true. Culture has little to do with fun offices, plentiful snacks, or adjustable desks. Instead, for us, it starts with hiring people who are relentlessly curious and, at the same time, empathetic. Curious people want to learn. Empathetic people love to teach. And if you put a group of them together, whether in a swanky office or on Zoom, great things will happen.

As we come out the other side of COVID, we have an opportunity to help build a better way to work. It would be naive to insist that we go back to the way we did things before. We've been more productive, and on average our team has been happier in their jobs, than any time in the company's history. At the same time, we know there can be considerable value in coming together in person to solve hard problems, brainstorm about the future, and build relationships that make the company stronger.

We don't have all the answers on what the future of work looks like, but we've begun to formulate a place to start our experiments as people come back. We hope we can use the times we get together as ways to better collaborate and learn. But, at the same time, give our team the flexibility to work how and wherever they are the most productive.

Cloudflare's mission is to help build a better Internet. We always capitalize the I in Internet, in spite of what the AP style guide has said since 2016, because it's a proper noun, we believe there is and only should be one, and we have an enduring respect for what a miracle it is that it exists.

Right around the same time that the AP started to say that you needn't capitalize the I in Internet anymore, something seemed to change. The world shifted from seeing the Internet and what it enabled as an irreproachable good to a source of great danger.

We've watched the same thing. Since 2016 it's often felt like a connection to the Internet only brings cyberattacks, toxic social media, threats to democracy, increasing polarization, and a declining disdainful discourse.

We have real challenges ahead as some of the technologies that ride on top of the Internet have broken down traditional gatekeepers without sufficient concern for addressing the harms they previously protected against. But, at the same time, the Internet itself remains a miracle.

A mere 11 years before Cloudflare's founding, long distance phone calls still cost a fortune, sharing a photograph with someone in another country took weeks, and the idea that you could access the sum total of human knowledge from a device in your pocket was beyond even the fantasies of science fiction.

The last 18 months of the pandemic have reaffirmed our faith in the miracle that is the Internet. Imagine just how much worse it would have been had the pandemic happened just 11 years ago, let alone 22. The Internet allowed many of us to continue to work, connect with our loved ones, exercise our creativity, and stay connected to the world.

We're proud of what we've done to live up to our mission and help build a better Internet during this time. And, as we come out the other side, we will continue to engage with policy makers to address the new harms an interconnected world has brought while preserving the miracle that is the Internet itself.

The Internet may seem static, but it is not. 11 years ago, watching a video online was an exercise in frustration. Today, it seems almost automatic that you can push play on your TV and access nearly any movie ever made instantly. That's possible because the Internet isn't static; it gets better through innovation.

At Cloudflare, we're optimized to catalyze exactly that innovation. It starts with our mission: to help build a better Internet. The word "help" is important, because we know we can't do it alone. So, wherever we can, we work with others across the Internet ecosystem to push it forward and make it better.

Sometimes people outside the company are surprised by the products we build. In fact, predicting our roadmap is pretty easy. We look at all the steps that are required to load a web page, send an email, stream a video, login to a workstation, or anything else you do online and ask: can we make that more secure, more reliable, or faster?

What's exciting is that the pace at which the Internet is getting better is accelerating. And, in turn, the pace at which we are able to launch innovative new products is accelerating along with it. As the Internet grows and acquires more capabilities, we believe we will continue to grow with it. An investment in Cloudflare is, fundamentally, we feel an investment in the Internet itself.

And so, this week, we have an incredible series of announcements that are designed to help build a better Internet. We're entering a new area to close one of the last network security risks that we haven't historically protected our customers from, driving down costs of core cloud services, pushing the boundary of our network to our customers' doorsteps, and investing in new technologies that may someday disrupt the web as we know it today.

Thank you to our team, our customers, and our investors. Happy 11th birthday to Cloudflare. And, even as we pick up steam, we continue to believe: we're just getting started.

This is the story of how we decided to work with Google to build Signed Exchanges support at Cloudflare. But, more generally, it's also a story of how Cloudflare thinks about building disruptive new products and how we've built an organization designed around continuous innovation and long-term thinking.

The story starts with me pretty freaked out. In May 2015, Facebook had announced a new format for the web called Instant Articles. The format allowed publishers to package up their pages and serve them directly from Facebook's infrastructure. This was a threat to Google, so the company responded in October with Accelerated Mobile Pages (AMP). The idea was generally the same as Facebook's but using Google's infrastructure.

As a general Internet user, if these initiatives were successful they were pretty scary. The end game was that the entirety of the web would effectively be slurped into Facebook and Google's infrastructure.

But as the cofounder and CEO of Cloudflare, this presented an even more immediate risk. If everyone moved their infrastructure to Facebook and Google, there wasn't much left for us to do. Our mission is to help build a better Internet, but we've always assumed there would be an Internet. If Facebook and Google were successful, there was real risk there would just be Facebook and Google.

That said, the rationale behind these initiatives was compelling. While they ended with giving Facebook and Google much more control, they started by trying to solve a real problem. The web was designed with the assumption that the devices connecting to it would be on a fixed, wired connection. As more of the web moved to being accessed over wireless, battery-powered, relatively low-power devices, many of the assumptions of the web were holding back its performance.

This is particularly true in the developing world. While a failed connection can happen anywhere, the further you get from where content is hosted, the more likely it is to happen. Facebook and Google both reasoned that if they could package up the web and serve complete copies of pages from their infrastructure, which spanned the developing world, they could significantly increase the usability of the web in areas where there was still an opportunity for Internet usage to grow. Again, this is a laudable goal. But, if successful, the results would have been dreadful for the Internet as we know it.

So that's why I was freaked out. In our management meetings at Cloudflare I'd walk through how this was a risk to the Internet and our business, and we needed to come up with a strategy to address it. Everyone on our team listened and agreed but ultimately and reasonably said: that's in the future, and we have immediate priorities of things our customers need, so we'll need to wait until next quarter to prioritize it.

That's all correct, and probably the right decision if you are forced to make one, but it's also how companies end up getting disrupted. So, in 2016, we decided to fund a small team led by Dane Knecht, Cloudflare’s founding product manager, to set up a sort of skunkworks team in Austin, TX. The idea was to give the team space away from headquarters, so it could work on strategic projects with a long payoff time horizon.

Today, Dane's team is known as the Emerging Technologies & Incubation (ETI) team. It was where products like Cloudflare for Teams, 1.1.1.1, and Workers were first dreamed up and prototyped. And it remains critical to how Cloudflare continues to be so innovative. Austin, since 2016, has also grown from a small skunkworks outpost to what will, before the end of this year, be our largest office. That office now houses members from every Cloudflare team, not just ETI. But, in some ways, it all started with trying to figure out how we should respond to Instant Articles and AMP.

We met with both Facebook and Google. Facebook's view of the world was entirely centered around their app, and didn't leave much room for partners. Google, on the other hand, was born out of the open web and still ultimately wanted to foster it. While there has been a lot of criticism of AMP, much of which we discussed with them directly, it's important to acknowledge that it started from a noble goal: to make the web faster and easier to use for those with limited Internet resources.

We built a number of products to extend the AMP ecosystem and make it more open. Viewed on their own, those products have not been successes. But they catalyzed a number of other innovations. For instance, building a third party AMP cache on Cloudflare required a more programmable network. That directly resulted in us prototyping a number of different serverless computing strategies and finally settling on Workers. In fact, many of the AMP products we built were the first products built using Workers.

Part of the magic of our ETI team is that they are constantly trying new things. They’re set up differently, in order to take lots of "shots on goal." Some won't work, in which case we want them to fail fast. And, even for those that don't, we are always learning, collaborating, and innovating. That's how you create a culture of innovation that produces products at the rate we do at Cloudflare.

Importantly also, working with the AMP team at Google helped us better collaborate on ideas around Internet performance. Cloudflare's mission is to "help build a better Internet." It's not to "build a better Internet." The word "help" is essential and something I'll always correct if I hear someone leave it out. The Internet is inherently a collection of networks, and also a collection of work from a number of people and organizations. Innovation doesn't happen in a vacuum but is catalyzed by collaboration and open standards. Working with other great companies who are aligned with democratizing performance optimization technology and speeding up the Internet is how we believe we can make significant and meaningful leaps in terms of performance.

And that's what Signed Exchanges have the opportunity to be. They take the best parts of AMP — in terms of allowing pages to be preloaded to render almost instantly — but give back control over the content to the individual publishers. They don't require you to exclusively use Google's infrastructure and are extensible well beyond just traffic originating from search results. And they make the web incredibly fast and more accessible even in those areas where Internet access is slow or expensive.

We're proud of the part we played in bringing this new technology to the Internet. We're excited to see how people use it to build faster services available more broadly. And the ETI team is back at work looking over the innovation horizon and continuously asking the question: what's next?

Cloudflare launched on September 27, 2010 — 10 years ago today. Stopping to look back over the last 10 years is challenging in some ways because so much of who we are has changed radically. A decade ago when we launched we had a few thousand websites using us, our tiny office was above a nail salon in Palo Alto, our team could be counted on less than two hands, and our data center locations on one hand.

Outside our first office in Palo Alto in 2010. Photo by Ray Rothrock.

As the company grew, it would have been easy to stick with accelerating and protecting developers and small business websites and not see the broader picture. But, as this year has shown with crystal clarity, we all depend on the Internet for many aspects of our lives: for access to public information and services, to getting work done, for staying in touch with friends and loved ones, and, increasingly, for educating our children, ordering groceries, learning the latest dance moves, and so many other things. The Internet underpins much of what we do every day, and Cloudflare’s mission to help build a better Internet seems more and more important every day.

Over time Cloudflare has gone from an idea on a piece of paper to one of the largest networks in the world that powers millions of customers. Because we made our network to be flexible and programmable, what we’ve been able to do with it has expanded over time as well. Today we secure the Internet end-to-end — from companies’ infrastructure to individuals seeking a faster, more secure, more private connection. Our programmable, global network is at the core of everything we have been able to achieve so far.

This is also the approximate one-year anniversary of Cloudflare going public. At the time, we wrote our first founders' letter to the potential investors. We thought it made sense on this day, which we think of as our birthday, to reflect on the last year, as well as the last 10 years, and start a tradition of updating our original founders' letter on September 27th every year.

Ringing the bell to go public on the NYSE on September 13, 2019.

It's been quite a year for our business. Since our IPO, we've seen record expansion of new customers. That growth has come both from expanding our existing customers as well as winning new business from new customers.

The percentage of the Fortune 1,000 that pay for one or more of Cloudflare's services rose from 10% when we went public to more than 16% today. Across the web as a whole, according to W3Techs' data, over the last year Cloudflare has grown from 10.1% of the top 10 million websites using our services to 14.5% using them today. (Amazon CloudFront, in second place based on the number of websites they serve, grew from 0.8% to 0.9% over the same period.)

Every year to celebrate our birthday we've made it a tradition to launch products that surprise the market with new ways to expand how anyone can use our network. We think of them as gifts back to the Internet. Three years ago, for instance, we launched our edge computing platform called Workers. Today, just three years later, hundreds of thousands of developers are using Workers to build applications, many of which we believe would be impossible to build on any other platform.

This year we're once again launching a series of products to extend Cloudflare's capabilities and hopefully surprise and delight the Internet. One that we're especially excited about brings a new data model to Workers, allowing even more sophisticated applications to be built on the platform.

It is impossible to reflect on the last year and not see the impact of the COVID-19 pandemic on our business, our customers, our employees, as well our friends, colleagues, and loved ones in the greater community. It's heartening to think that for more than half of Cloudflare’s life as a public company our team has worked remote.

2020 was meant to be an Olympic year, but COVID-19 stopped that, like much else, from happening. Eight years ago, when Cloudflare was just two, the creator of the World Wide Web, Tim Berners-Lee, sent a message from the opening ceremony of the 2012 Olympics. That message read “This is for everyone” and the idea that the Internet is for all of us continues to be a key part of Cloudflare's ethos today.

When we started Cloudflare we wanted to democratize what we thought were technologies only available to the richest and most Internet-focused organizations. We saw an opportunity to make available to everyone — from individual developers to small businesses to large corporations — the sorts of speed, protection, and reliability that, at the time, only the likes of Google, Amazon, and Facebook could afford.

Over 10 years we’ve consistently rolled out the latest technologies, typically ahead of the rest of the industry, to everyone. And in doing so we’ve attracted employees, individuals, developers, customers to our platform. The Internet is for everyone and we’ve shown that a business can be very successful when we aim to serve everyone — large and small.

Something Steve Jobs said back in 1988 still resonates: “If you want to make a revolution, you've got to raise the lowest common denominator in every single machine." Although we aren’t selling machines, we think that’s right: democratizing features matters.

Just look at the scourge of DDoS attacks. Why should DDoS attack mitigation be expensive when it’s a plague on companies large and small? It shouldn’t, and we optimized our business to make it inexpensive for us and passed that on to our customers through Unmetered DDoS Mitigation — another feature we rolled out to celebrate our Birthday Week three years ago.

In 2014, also during Birthday Week, we launched Universal SSL, making encryption — something that had been expensive and difficult — free for all Cloudflare customers. The week we launched it we doubled the size of the encrypted web. Let’s Encrypt followed shortly after and, together, we’ve brought encryption to more than 90% of the web and made the little padlock in your browser something everyone can afford and should expect.

Percent of the web served over HTTPS as reported by Google.

In January of this year, we rolled out Cloudflare for Teams. The product was designed to replace the legacy VPNs and firewalls that were increasingly anachronistic as work moved to the cloud. Little did we know how much COVID-19 would accelerate their obsolescence and make Cloudflare for Teams essential.

Both of us sat on call after call in mid-March with at first small, then increasingly mid-sized, and eventually large and even governmental organizations who reached out to us looking for a way to survive as their teams shifted to working from home and their legacy hardware couldn't keep up. We made the decision to sacrifice short term profits in order to help businesses large and small get through this crisis by making Cloudflare for Teams free through September.

As we said during our Q1 earnings call, the superheros of this crisis are the medical professionals and scientists who are taking care of the sick and looking for a cure to the disease. But the faithful sidekick throughout has been the Internet. And, as one of the guardians of the Internet, we're proud of helping ensure it was fast, secure, and reliable around the world when it was needed most. We are proud of how Cloudflare's products could help the businesses continue to get work done during this unprecedented time by leaning even more on the Internet.

Giving back to the Internet is core to who we are, and we do not shy away from a challenge. And there are many challenges ahead. In a little over a month, the United States will hold elections. After the 2016 elections we, along with the rest of the world, were concerned to see technology intended to bring people together instead be used to subvert the democratic process. We decided we needed to do something to help prevent that from happening again.

Three and a half years ago, we launched the Athenian Project to provide free cybersecurity resources to any local, state, or federal officials helping administer elections in the United States. We couldn't have built Cloudflare into the company it is today without a stable government as a foundational platform. And, when that foundation is challenged, we believe it is our duty to lend our resources to defend it.

Today, we're helping secure election infrastructure in more than half of the states in the United States. And, over these last weeks before the election, our team is working around the clock to help ensure the process is fair and not disrupted by cyber attacks.

More challenges lie ahead and we won’t shy away from them. Well intentioned governments around the world are increasingly seeking to regulate the Internet to protect their citizens. While the aims are noble, the risk is creating a patchwork of laws that only the Internet giants can successfully navigate. We believe it is critical for us to engage in the conversations around these regulations and work to help ensure as operating online becomes more complex, we can continue to make the opportunities of the Internet created for us when we started Cloudflare available to future startups and entrepreneurs.

Over the last 10 years, it's been sad to watch some of the optimism around technology seem to fade. The perception of technology companies shifted from their being able to do no wrong to, today, their being able to do no right. And, as we've watched the industry develop, we've sympathized with that shift. Too many tech companies have abused customer data, ignored rules, violated privacy, and not been good citizens to the communities in which they operate and serve.

But we continue to believe what we started Cloudflare believing 10 years ago: the Internet itself is a force for good worth fighting to defend. We need to keep striving to make the Internet itself better — always on, always fast, always secure, always private, and available to everyone.

It's striking to think how much more disruptive the COVID-19 crisis could have been had it struck in 2010 not 2020. The difference today is a better Internet. We're proud of the role we've played in helping build that better Internet.

And, ten years in, we're just getting started.

Before looking forward to the coming week, let’s take a look back at announcements from previous Birthday Weeks.

A year into Cloudflare’s life (in 2011) we launched automatic support for IPv6. This was the first of a long line of announcements that support our goal of making available to everyone the latest technologies. If you’ve been following Cloudflare’s growth you’ll know those include SPDY/HTTP/2, TLS 1.3, QUIC/HTTP/3, DoH and DoT, WebP, … At two years old we celebrated with a timeline of our first two years and the fact that we’d reached 500,000 domains using the service. A year later that number had tripled.

In 2014 we released Universal SSL and gave all our customers SSL certificates. In one go we massively increased the size of the encrypted web and made it free and simple to go from http:// to https://. Other HTTPS related features we’ve rolled out include: Automatic HTTPS Rewrites, Encrypted SNI and our CT Log.

In 2017 we unwrapped a bunch of goodies with Unmetered DDoS Mitigation, our video streaming service, Cloudflare Stream, the ability to control where private SSL keys stored through Geo Key Manager. And, last but not least, our hugely popular serverless platform Cloudflare Workers. It’s hard to believe that it’s been three years since we changed the way people think about serverless with our massively distributed, secure and fast to update platform.

Two years ago Cloudflare became a domain registrar with the launch of our “at cost” service: Cloudflare Registrar. We also announced the Bandwidth Alliance which is designed to reduce or eliminate high cloud egress fees. We rolled out support for QUIC and Cloudflare Workers got a globally distributed key value store: Workers KV.

Which brings us to last year with the launch of WARP Plus to speed up and secure the “last mile” connection between a device and Cloudflare’s network. Browser Insights so that customers can optimize their website’s performance and see how each Cloudflare tool helps.

We greatly enhanced our bot management tools with Bot Defend Mode, and rolled out Workers Sites to bring the power of Workers and Workers KV to entire websites.

Here are some hints about what to expect this year for our 10th anniversary Birthday Week:

• Monday: We’re fundamentally changing how people think about Serverless

If you studied computer science you’ll probably have come across Niklaus Wirth’s book “Algorithms + Data Structures = Programs”. We’re going to start the week with two enhancements to Cloudflare Workers that are fundamentally going to change how people think about serverless. The lambda calculus is a nice theoretical foundation, but it’s Turing machines that won the day. If you want to build large, real programs you need to have algorithms and data structures.

• Tuesday and Wednesday are all about observability. Of an Internet property and of the Internet itself. And they are also about privacy. We’ll roll out new functionality so you can see what’s happening without the need to track people.

• Thursday is security day with a new service to protect the parts of websites and Internet applications that are behind the scenes. And, finally, on Friday it’s all about one click performance improvements that leverage our more than 200 city network to speed up static and dynamic content.

Welcome to Birthday Week 2020!

“Real knowledge is to know the extent of one's ignorance.”― Confucius

Don’t tell our CEO, Matthew Prince, but the first day I interviewed at Cloudflare I had a $9.00 phone in my pocket, a knock-off similar to a Nokia 5140, but the UI was all in Chinese characters—that phone was a fitting symbol for my technical prowess. At that time in my career I could send emails and use Google, but that was about the extent of my tech skill set. The only code I’d ever seen was in the Matrix, Apple computers confused me, and I was working as a philosophy lecturer at The University of California, Santa Cruz. So, you know, I was pretty much the ideal candidate for a deeply technical, Silicon Valley startup.

This was in 2013. I had just returned from two years of Peace Corps service in the far Southwest of China approaching the Himalayan plateau. That experience gave me the confidence to walk into Cloudflare’s office knowing that I would be good for the job despite the gaps in my knowledge. My early training in philosophy plus my Peace Corps service gave me a blueprint for learning and figuring things out when thrown into the deep end (it turns out that I love being thrown into the deep end and learning to swim).

I had no idea that this first meeting with Matthew would eventually lead me back to China, this time riding on the cloud of a fast-growing Silicon Valley tech giant.

Two years earlier, eighty Peace Corps Volunteers and myself landed in the capital of Sichuan province, Chengdu. The vast majority of us, myself included, spoke zero Mandarin and only knew about China from books and a few news snippets here and there. The Chinese staff members that greeted us at the Peace Corps China headquarters on the Sichuan University campus affectionately called us “baby pandas”, because we were cute and fairly incompetent in terms of operating in China.  

Our mission was to help China meet its need for trained men and women—specifically to teach college level students English and train qualified Teachers of English as a foreign language instructors (TEFL instructors). We were also there to promote a better understanding of Americans abroad, and to do our best to gain some understanding of China and its people.

Thus began two years of deep learning and profound personal growth.

When I think about the most important aspects of my time in China, there are three fundamentals that I come back to:

• The importance of learning the language and culture

• The importance of 关系 (guanxi) or personal connections and relationships

• The necessity of being resourceful

The most successful Peace Corps volunteers in my cohort were the ones that learned to speak Mandarin well, understood enough about Chinese culture to operate effectively in their schools and communities, had built important personal and professional relationships, and had figured out how to survive in Southwest China and be useful as English language resources and American cultural liaisons. There was a steep learning curve.

Peace Corps Service in China has four phases more or less. Phase one, Pre Service Training (PST), took place at Sichuan University. We were all living with Chinese host families, taking 8-9 hours of Mandarin class each day, learning about Chinese culture, and being trained as TEFL instructors. It is an intense period of learning against a backdrop of tremendous culture shock, jet lag, and general confusion of how to be an American in Southwest China.

After three months of well taught crash courses, I was sent out to the college where I would spend the next two years of my service. That first night, after I unpacked my bags and took a shower, the reality of my life decisions came crashing down. This was going to be *very* hard. I was alone with millions and millions of Chinese people in remote Sichuan. Phase two was about to begin.

This is Yibin (宜宾), the city I lived in for two years. A small city in China of just 5,000,000 people right on the Yangzi river. Photo taken from the countryside looking towards the center of town.

Getting familiar with the college where I was to spend two years was another steep learning curve. I was introduced to the colleagues I’d be teaching with as well as the school administrators, and, most importantly, I was introduced to my students. I got lucky, the English department at my school was small, and I only had 20-30 students in each of my classes. I met with them 4 times a week for two hours a day, so I had ample time to really get to know them and work with them one-on-one in the classroom, during office hours, and over spicy Sichuan dinners.

Me and a few of my top students.

That first year of service I studied Mandarin as if my life depended on it—because it sort of did. Few people, i.e. my students and colleagues, spoke English in rural Sichuan. As I was able to communicate better in Mandarin, my understanding of the culture grew and so did my relationships with folks at my school and community.

In an effort to understand more about the culture I was living in, I gave myself an education in Chinese philosophy starting with Confucius (孔子) and the Daoist like Laozi (老子) and Zhuangzi (庄子), and I also looked into Buddhism. Since the world’s wisdom traditions contain universal principles that transcend time and culture, these readings gave me subtle insights into the Chinese way of life. I learned that Confucianism is the invisible glue holding much of Chinese society together. And while Confucius spoke to Chinese society and how people ought to act, his contemporary, Laozi, considered the founder of Daoism, spoke to the Chinese soul via the Dao de Jing (道德经).

Apropos of philosophy, one beautiful Chinese proverb I found in my reading goes: “Only those who take leisurely what the rest of the world is concerned about, can be concerned about with the rest of the world takes leisurely”. A calligraphy artist at my school gifted me a piece of work expressing this:

I also learned early on in my service what my students needed: authentic opportunities to express themselves in English, understanding and encouragement, and a solid English text book that employed the latest pedagogical techniques for learning a foreign language. Since my Mandarin was slow going, my students had all sorts of authentic opportunities to speak to me in English. They ended up helping me translate a lot that first year as I navigated my life on campus. As for encouragement, I would often talk to them in my developing and broken Mandarin in front of the class. I messed up words and tones constantly, and they laughed (hard) and then kindly corrected me. In this way, I showed them that learning is all about making mistakes, and that it is fine to get it wrong as you begin. There is no other way to learn a language (or anything else). The last part, providing a solid textbook, would be more tricky.

I received enough training during PST to have some good ideas for teaching English as a foreign language, but I had no experience writing a language textbook. What I ended up doing was replicating the structure of the textbooks I was using to learn Mandarin: a dialogue which incorporates a few new vocab words, a list of those new vocab words, grammar practice using grammatical structures from the dialogue, and then photos of relevant objects or scenes that would allow students to use new vocabulary words to describe the photos using new words and structures. I would record these dialogues and then distribue the audio file to my students so they could hear my pronunciation.

We’d work with this dialogue, vocabulary, and grammar all week, then on Fridays I’d put them in a “language line”. Sort of like speed dating, but they would have to hold a conversation with their classmates around the topic of that week and use the new vocab words. I’d listen in and help guide them. Then at the end of class, we’d form a line and I’d ask each one of them a question individually that they had to answer before they could leave the classroom. This pushed each student into learning so that they could actually speak English confidently to a native English speaker. It was a rewarding project.

My mom sent Halloween candy for my students in October. They were *very* excited.

My students were super smart and diligent, and week after week their English level was going up. I was able to hold natural conversations with them while speaking slow, and my Mandarin was progressing to the point that I could clarify things in Mandarin to aid their English learning. And so I learned how to teach English.

I consider all of the second year of service phase three. It is in that second year that volunteers can do really great work. My language level was high enough to really communicate with my community and explore China more, I had a basic structure for teaching and kept honing it to fit the needs of my students, and I developed a lot of really important relationships with the administrators at my school and other wonderful folks in the area.

Phase four is the return to the US. Something that no one told me about Peace Corps service before I joined is that you actually sign up for three years, not two. And that the third year, the first year back home after service, would be the most challenging by far … readjusting to life in the US, starting up or continuing a career, feeling a million miles behind peers who cranked through two extra years in a work world. All of this while trying to work on one of the most important goals of the Peace Corps—Goal 3—helping Americans better understand China through my experiences. I’m doing this every chance I get. This blog is a part of fulfilling Goal 3.

Me and my good friend, 兵哥, goofing around in the Sichuan countryside after a long bike ride.

My service in China impacted me in profound ways. I have a love and respect for China that was born of close contact with the wonderful people, culture, philosophy, and language I was steeped in. And it gave me a clear experience of my ability to grow and change and acquire new skills swiftly. By the end of my time, I could confidently hold a conversation in Mandarin, I could read sections of Chinese newspapers, I had written an English text book for my students, and I made so many friends. All of that came from slow, diligent, hard work—and finding the necessary resources to get things done for my students in non-obvious ways. I had a clearly outlined experience of what diligence and time can do, and I knew deep in me is the potential to learn, adapt, and grow into almost anything.

Two years of remote Peace Corps work (which, despite being among millions of Chinese people, is often an isolating experience) gave me ample time to reflect on my life. While I find teaching deeply rewarding and I love the study of philosophy, I felt that I needed a different pool to swim in than academia. I thought that the private sector would likely offer the most opportunity, so when I came back to the US, I decided to move to San Francisco and aim for a job in tech. I figured that would be like plunging into the ocean, and I was keen to see where the global economic currents might take me.

In the first few weeks I was back in the US I set up 4-5 informational interviews each week. I spoke to people at Google and Square, folks working in event planning, in finance, in HR, in construction, etc. Then one of my colleagues at the university mentioned that their friend (Matthew) had a tech startup called “Cloudflare” and could maybe use some help writing stuff. I followed up right away.

Despite hours of Googling “What is a Cloudflare?”, I was utterly and completely out of my depth when Matthew explained to me what the company does. Before my interview with him, I had done my homework memorizing definitions for acronyms like CDN, DNS, DDoS, and API, but I didn’t really know what they were. The instructions I received before the interview were to learn a bit about how Cloudflare works, and “Don't wear a suit and tie”. This was a time in Cloudflare history when we had about 60 employees, about 30 data centers, and a bit of duct tape in the office pressing extension cords into the carpet.  

I was intimidated speaking to Matthew the first time. He is an amazingly accomplished and incredibly intelligent person. I checked out his LinkedIn profile, and I didn’t know anything about SPAM, law school, business school, being an entrepreneur, or how the Internet works. The folks in Peace Corps China always talked about being resourceful, so I looked for and found an opportunity to connect with him on a level that I could grasp. Matthew, who has unbelievable credentials and professional accolades, still has “Ski Instructor” on his LinkedIn profile somewhere between “Adjunct Professor of Law” and “Harvard Business School”:

I had just spent all of my time in China aiming to build relationships with my students and other people in my community that were from vastly different backgrounds and trying to find common ground from which to build rapport and trust. I thought, if someone this accomplished keeps their ski instructor experience on their resume, it must have a lot of meaning. I’m glad I followed that intuition because this topic led to a great conversation with Matthew about hometowns, ski trips, and ski equipment, which eventually lead to a conversation about surfing and surfboards, which is right in my wheelhouse. It turned out to be a great interview because we connected over things that we both found important. We found a piece of common ground that didn’t seem obvious at first---part of that being a deep curiosity for how and why things work. Looking back five years, I can say without reservation that finding a way to connect with Matthew that day has had a profoundly positive impact on the course of my life.

When it came time for me to interview with our co-founder, Michelle, she understood that I had a lot to learn about the company, and she took the time to draw out a simplified map of Cloudflare’s network on a yellow legal pad. She drew jagged, little clouds around the world and patiently explained what global caching is, how Anycast networking helps with DDoS attacks, and how DNS is like the phone book of the Internet. I was struck that such a highly intelligent person, HBS grad, co-founder of a major tech firm would take time out of their busy day to do this. I learned later that Michelle is always like this. She is amazing with names, stops to talk to folks in the office whenever she can, and sets a tone of respect, compassion, and understanding at the office. It is inspiring.

I then had a video interview with John Graham-Cumming, our CTO, who was in London. There was no getting away from tech with this interview. So I Googled everything I could about John. I read his book Geek Atlas, I watched his TED Talk, and I looked into his interest in Movie Code. I was ready for this interview. We talked about the Parkes Radio Telescope in Australia, Alan Turing, and about the code in the Matrix (thank you, Neo!). John is a fascinating speaker and a legend in the technology space. He is also kind and patient, and he never made me feel silly for not grasping technical concepts right away.

After 6-7 interviews over the following weeks, the feedback I got was that I was a good culture fit, I was hard-working and smart, but I just didn’t have the technical knowledge to do the job. That feedback seemed spot on, but I wasn’t going to let that hold me back. I knew I could be useful to this company. I knew that if they gave me a shot and threw me into the deep end that I would learn to swim. I knew what I needed to do: learn the language and culture of Silicon Valley, make connections, and be resourceful.

I stood outside of the old Cloudflare office at 665 3rd St. in San Francisco, and I told myself that I have to get in that door. I didn’t know exactly what they are doing in there, but it seemed weird and interesting, and I wanted to be a part of it.

So I started learning. Another returned Peace Corps volunteer that I’d met in the Bay Area sat down with me one weekend and helped me build a simple website from the ground up. In the most basic HTML and CSS, we embedded a video we made about my China experience. On the site I made the background color orange to match the Cloudflare logo and wrote something like, “Check it out Matthew and Michelle, I’m learning how to write code!”, and I sent them the link.

In the following weeks, I sent more follow up emails to Matthew than felt polite. But it worked. Matthew, Michelle, and John took a huge risk on me, and I got an offer to be Cloudflare’s “Writer” (since that was really the only thing that made sense for an academic philosopher to do at a tech firm). They actually gave me business cards that read: Andrew A. Schafer - Writer.

When I accepted the offer via email, Matthew wrote back saying that getting up to speed with Cloudflare was “going to be like drinking from a fire hose”.

On day one, I sat down next to the folks on the Data Team and introduced myself. They all said a quick, polite “hi” and then put their head phones back on immediately and continued to write code. I didn’t learn for a long time that engineers DO NOT like to be interrupted when they are coding. This is a key feature of tech culture.

I spent part of my first week at Cloudflare watching a lot of YouTube videos by Eli the computer guy. He does a great job explaining DNS, the OSI model, basic networking, etc. He even has an older video about Cloudflare, which was super helpful (Thank you, Eli!).

Eli, The Computer Guy

At one point John Graham-Cumming walked past my desk and asked me why I was staring at that man in the orange shirt so much. I turned around and exclaimed, “John, did you know that the Internet has LED lasers that blink on and off BILLIONS of times per second?!” He calmly replied, “yes” and then went about his business. That fact made my mind melt. I had so much to learn.

One of the first things I worked on as Cloudflare’s Writer was some of the PR efforts surrounding Project Galileo, DDoS attack protection for at-risk public interest websites, which I’m still proud of. I worked with our legal team to draft up this blog post, which helped me to understand the implications and power of Cloudflare’s technology in real-world terms.

I worked with Nick Sullivan a whole bunch at the beginning also, which was mystifying. He is already a great writer and he was writing about such complex things. There were times where I was adding punctuation to sentences that made sense grammatically, but I didn’t understand their content. I learned a lot about encryption, and my tech vocabulary grew.

At one point I also helped John Graham-Cumming with a few blogs. John is a published author, so I didn’t really help him write anything, but I did help him bring his posts way down to my level. You can see my influence on this blog post about Shellshock. That day I learned the term “zero day vulnerability”.

In that blog John wrote: “Attackers will also use an ACE vulnerability to upload or run a program that gives them a simple way of controlling the targeted machine. This is often achieved by running a "shell". I read his draft and I asked him, “What is a shell?”. A question, I learned much later, that was highly embarrassing to ask at a tech office. But I didn’t know, and I wanted to know. So we clarified that, “A shell is a command-line where commands can be entered and executed” in the post just in case other tech noobs like myself were trying to follow along. I learned how to be a translator from tech-speak to normal English.

I even researched and wrote a few posts of my own, like this one about Raspberry Pi’s fronted by Cloudflare. I had no idea what a Raspberry Pi was before being asked to write this. Thankfully one of the folks on the Data Team had one and let me borrow it for a photo op. I learned about the inspiring philosophy behind Raspberry Pi and the vibrant community that uses them.

As the official Cloudflare Writer, I was proud of writing the copy for our dashboard. That project was an amazing way for me to get to know a lot of key members of the engineering team and have them teach me exactly how each feature worked. I wrote out what I understood, clarified some points with them, and then made a pull request to get the explanations into the code base for our dashboard.  

If you’ve ever used these help menus—you are welcome! (Note: lots of other Cloudflare team members have kept this updated and expanded.)

Eventually, I became an honorary member of the Data Team. It took some doing, but I learned Python the hard way, and I wrote a Python script that would print my name 100,000 times in the terminal. I crashed my machine when I tried to make it print my name 100,000,000,000,000 times. I learned something about code that day—it can break things.

I ran this code while sitting next to the person who had built Cloudflare’s original database. I did a victory dance when I crashed my laptop I was so proud of myself. That is sort of like me bragging about my backyard badminton skills next to Serena Williams.

I dipped my toes into the language of code, and started to speak that language with the engineers around me. This helped me to learn an important lesson about tech culture: the deeper your technical understanding the greater the respect you receive.

Eventually, I was ready for a new challenge at Cloudflare—talking to our clients.

The first thing I learned in a client facing role at Cloudflare is that Cloudflare is not a widget or a nice-to-have—it is mission critical technology for everyone that uses it. When something goes wrong people are very upset. The second thing I learned in a client facing role at Cloudflare is that the Internet is a fragile little teacup and it runs on human trust—which is astonishing. The combination of those two facts created ample opportunity for me to develop my listening and communication skills.

I started by rereading How to Win Friends and Influence People, by Dale Carnegie and took special note of rule number four, which states, “Be A Good Listener”. I quickly graduated to the philosophy and practice of Nonviolent Communication, by Marshall B. Rosenberg. I ended up taking some NVC courses in San Francisco focused on listening skills in this style. I also took compassion meditation courses via Stanford a few years in a row, which had a profound impact on my ability to empathise with our clients.

While brushing up on and honing these interpersonal skills was helpful, what I learned in a lot of those early meetings with clients was that I need to understand Cloudflare’s technology better. It’s one thing to be able to talk about it, it’s a whole different thing to be able to understand it enough to solve real issues.

I decided to do the “homework” our Solutions Engineering team gives out to their hiring candidates. I had to learn command-line basics, create an origin web server on DigitalOcean, install Ubuntu, configure a firewall, install NGINX, create a simple website from HTML, add an image to that site, set up DNS, and then put Cloudflare in front of it.

I set up my first DNS record in Cloudflare to point to my origin server, and was like “OHHHHHHH SNAP! That is how DNS works! It maps my domain name to the IP address of my server!” Hands on learning makes all the difference.

And I learned that WWW is a subdomain of the apex!! What???

It wouldn't be a legit Cloudflare blog without more code, so here we go. I ended up writing (modifying) this amazing piece of code based on the NGINX HTML welcome page template:

Notice that I added an image:

I’m now a web developer! I’ve added yet another cat photo to the Internet. You are welcome world! (Note at the time of publishing my site is offline [I forgot to renew the domain—oopsy]).

Once I had my site up and running on Cloudflare, I learned how to make API calls to pull down the our Enterprise raw logs and use jq to sort them (jq, I learned, is “a lightweight and flexible command-line JSON processor”):

curl -H "X-Auth-Email: aschafer@cloudflare.com" -H "X-Auth-Key:
cc1e78b22222229b9d72643fbda69655579d" -H "Content-Type: application/json" 
"https://api.cloudflare.com/client/v4/zones/f5fb827cf31f628c1c0730bc4b0792d
d/logs/requests?start=0&count=1" | jq 'select(.clientRequest.uri == 
"/admin"), .client.ip'| sort | uniq -c | sort -r

(Note: This cURL command does not contain a real API key. I learned the hard way to NEVER include the API key when sharing a cURL.)

I was so proud. I could say things like, “pull down the raw logs and pipe them into jq” to my clients, and I actually knew what I was saying—my tech language skills were improving.

I then read “High Performance Browser Networking” by Ilya Grigorik. I didn't even understand what that title meant at first. I had to translate it into non-tech English. It turns out that, for example, Chrome is a high performance browser, which is a tool you use to navigate a network of computers, a.k.a. the Internet. So it is a guide book for building the most performant web apps within the limits of current browser and networking technology.

Grigorik’s philosophy resonates with me, “Good developers know how things work. Great developers know why things work.” Insert any other profession or art and the statement remains true.

It took me six months of reading on bus rides to work, but by the end I could say things like, WebSocket API, Subprotocol Negotiation, TLS OCSP Stapling, and TCP Head-of-Line Blocking. I learned from Grigorik that, “TCP provides the abstraction of a reliable network running over an unreliable channel, which includes basic packet error checking and correction, in-order delivery, retransmission of lost packets, as well as flow control, congestion control, and congestion avoidance designed to operate the network at the point of greatest efficiency. Combined, these features make TCP the preferred transport for most applications.” Who knew?

After putting so much work into learning what Cloudflare really does, I came to understand something fundamental about the tech world: the learning never stops. Never. The fire hose never turns off.  

When I started at Cloudflare we offered more domains and extra SSL cert hosting slots as our additional products. Now we have Workers and Access and Argo and Argo Tunnel and Spectrum and Load Balancing and Stream and a Mobile SDK, and the list keeps growing. And we all have to learn about all of this new technology as it gets released. It is amazing!

Over the last few years, I’ve learned the language of Silicon Valley, and more specifically, I can speak the language of Cloudflare fluently. That has made a huge difference in my career.

I’ve enjoyed a lot of successes at Cloudflare, but the one achievement I’m most proud of is creating the “Big Horse Award for Strong Work”.

The idea for this came directly from chapter 2 of How to Win Friends and Influence People: “Give honest and sincere appreciation”. I make it a point to tell the folks I work with that they are doing outstanding work every chance I get because the folks I work with really are doing outstanding work all the time, and they should know about it.

Maybe three years ago my best friend at Cloudflare sent me a message via HipChat that read something like: “Hey Big Horse, you check that Jira ticket yet?”. From that day forward I called everyone “Big Horse” on HipChat at all times, which I thought was hilarious and everyone else thought was weird or annoying.

Shortly after that, in an effort to step up my “Give honest and sincere appreciation” game, I started sending emails to the whole company pointing out the strong work our support team was doing in our Zendesk customer support tickets. Our support team is world-class, but since only a few teams in the office can access Zendesk, a lot of folks internally don’t see their amazing work. I decided to take screenshots of tickets that were particularly well-handled and share them. I’d titled these emails “Strong Work, Big Horse!”. I quickly learned that emailing the whole company “does not scale”.

This culminated at one of our all hands B.E.E.R. meetings, where I gave out a Big Horse Award to a few outstanding members of our Support team. I had this stunningly beautiful trophy made for the occasion:

We needed a logo, so I Googled “stupid horse drawings” and found an image. With a little editing via photo editor and PowerPoint, a meme was born:

Since then we’ve had all sorts of iterations of the Big Horse logo:

And we had paraphernalia made:

Our support team even spray painted “Big Horse” on the side of a building on 4th St in downtown San Francisco on a team outing:

We’ve issued a new Sparkle Lama award as well—since not everyone wants to be called a big horse:

Many Cloudflare team members have Big Horse and Sparkle Lama stickers on their laptops, and we’ve shipped those golden big horse trophies around the world to our London and Singapore offices. These symbols have become easy ways to let our teammates know that they are doing great work. It is a small thing, but it adds up and helps make Cloudflare a great place to work.

Just a few weeks ago this Tweet was pointed out to me:

"For a reason I don’t understand yet, members of the Cloudflare engineering team own over 2% of all active .horse domains in the world" > https://t.co/IhGW55Oi2h

— Neil Levine (@neilwlevine) February 22, 2019

Well, Neil, the reason for this is that a few engineers and myself had big plans of launching a website around the Big Horse Award, we bought big.horse and a few others, but we didn’t follow through—yet. Stay tuned.

The Big Horse and Sparkle Lama Awards are my contribution the tech culture I’ve been a student of these last few years.

Five years after those first conversations with Matthew, Michelle, and John, I’m headed back to China with Cloudflare!

We are expanding our presence in China, and I have the good fortune (幸福) to combine the skills I acquired in philosophy and in the Peace Corps with the skills I acquired in Silicon Valley. We will be onboarding new Chinese clients, hiring more team members, and building out partnerships with other Chinese tech firms. I’m incredibly lucky to be headed back to a country that I love and embark on a new adventure.

I have a whole new fire hose aimed at me, and I plan to drink deep. I’ve been taking Mandarin classes again, this time to learn words like encryption (加密), caching (缓存), and cloud software (云软件). I’ll be learning a whole new interpersonal skill set around working with clients in China and across Asia. And since the office is just starting, this project will be a new exercise in resourcefulness.

 life_journey = ["China", "Silicon Valley", "China"]
for x in life_journey
   print(x)

I had no idea how much opportunity lay before me when I walked in the door as “the writer”, and I am profoundly grateful that Cloudflare took a chance on me. I plan to throw myself into this project in China, to learn and grow and contribute, and to figure out the best way to translate “Strong Work, Big Horse” into Mandarin.

我非常开心回去中国帮助成立我们的北京分部！

Today, March 12th 2019, marks the 30th birthday of the World Wide Web! Cloudflare is helping to celebrate in coordination with the Web Foundation, as part of a 30 hour commemoration of the many ways in which the Web has changed our lives. As we post this blog, Sir Tim Berners Lee is kicking off his journey of the web at CERN, where he wrote the first web browser.

The Web Foundation (@webfoundation) is organizing a Twitter timeline of the web, where each hour corresponds to a year starting now with 1989 at 00:00PT/ 08:00 CET. We (@cloudflare) will be tweeting out milestones in our history and the web’s history, as well as some fun infographics. We hope you will follow the journey on Twitter and contribute your own memories and thoughts to the timeline by tweeting and using #Web30 #ForTheWeb. Celebrate with us and support the Web!

If you are still awake there’s really one final question that you might want to know the answer to: What does the CTO do? The reality is that it means different things in different companies. But I can tell you a little about what I do.

I didn’t join Cloudflare as CTO. My original job title was Programmer and for the first couple of years I did just that. I wrote a piece of technology called Railgun (a differential compression program used to speed up the connection between Cloudflare and origin web servers) and then I went on to write our WAF. After that I worked on our Go-based DNS server and other parts of the stack.

At some point Lee Holloway decided he didn’t want to manage Cloudflare’s growing staff and Michelle Zatlyn (one of Cloudflare’s founders) asked me if I would ‘temporarily’ manage engineering. This is now the longest temporary job I’ve ever had!

Initially a lot of what I did was manage the team and help interview people. But I was still writing code. But more and more what I did was encourage others to do stuff. One day a bright engineer I’d been working with on DNS told me that he thought he could ‘solve DDoS’ if he could be left alone to work on an idea he had.

This was one of those situations where the engineer had shown they were very capable, and it was worth taking a risk. So, I said “OK” go do that, I’ll write the code you were meant to write, assign all your bugs to me. That turned out to be a good decision because he built our entire DDoS mitigation system (known internally as gatebot) which has fended off some of the largest DDoS attacks out there.

Of course, like everything else Cloudflare does, things outgrow an individual and need a team. Today gatebot and DDoS in general is managed by a team of engineers in London and Austin and the original engineer has moved onto other things. So, encouraging people is an important part of the job.

Slowly my temporary job got more and more things added to it. I was running Cloudflare’s IT department, SRE and technical operations, the network, infosec and engineering. Some temporary job. Slowly I got rid of some of those things. IT is now its own department as is infosec. Those things are far better run by other people than me!

The challenge of managing a team split around the entire globe (I had staff in San Francisco, London and Singapore) meant that new leadership was needed and so I recruited a head of engineering and SRE/ops had its own leader. Today more than 250 people sit in my overall team.

Along the way I stopped writing code and I did less and less day to day management as the leaders were able to do that. But something else became more important: things like this talk and sales.

Robert Metcalfe, who invented Ethernet while at Xerox PARC, said “I didn’t get rich by inventing Ethernet, I got rich by selling it”. This is an important point. It’s not enough to have good technology, you have to get people to hear about it and you have to sell it.

One way Cloudflare markets is through our blog. You may not realize it, but we have a very, very strong brand because we write those super technical blog posts. They don’t look like marketing, but they are. And another way we market is by doing this sort of thing: going places and talking.

But frequently, what I do is talk directly to customers. On Monday afternoon and evening, I was on two long video conferences with big potential customers in the US.  Yesterday, I was on a call about our partnership with IBM. This morning I did a call with a potential client in Germany before flying to Verona. So… one thing the CTO does is a lot of sales!

One thing I am not is the source of all technical wisdom in the company. I was once introduced by a law school friend of Matthew Prince’s as “the brain behind Cloudflare”. That’s so far from the truth. There are many jobs in engineering at Cloudflare that I am incapable of doing today without an enormous amount of learning. And teams are much stronger than individuals.

I do, on occasion, use experience to push the company in a certain direction. Or simply encourage something that I think is the right technology (I did this with our adoption of Clickhouse as a column-oriented database, with Go and recently with Rust). With Rust I decided to learn the language myself and make a little project and put it on GitHub. That’s enough in my position to make people realize it’s OK to use Rust.

So, in concluding here are some things to learn from my experience and the creation of Cloudflare. Be audacious, share widely, be open, work hard, spend a lot of time finding the right people and helping them, create teams, rewrite code, panic early! And above all, while doing this remain humble. Life comes at you fast, problems will arise, the wheel of karma spins around, you’ll need the help of others. Build something great and be humble about your creation.

• Part 1: How I came to work here

• Part 2: The Most Difficult Fortnight

• Part 3: Audacity, Diversity and Change

• Part 4: Public Engagement

• Part 5: People: Finding, Nurturing and Learning to Let Go

• Part 6: What does Cloudflare's CTO do? (you are here)

So, let me talk a bit about people. Software is made by people. Sometimes individuals but more likely by teams. I’ve talked earlier about some aspects of our architecture and our frequent rewrites but it’s people that make all that work.

And, honestly, people can be an utter joy and a total pain. Finding, keeping, nurturing people and teams is the single most important thing you can do in a company. No doubt.

Finding people is really hard. Firstly, the technology industry is booming, and so engineers have a lot of choices. Countries create special visas just for them. Politicians line up to create mini-Silicon Valleys in their countries. Life is good!

But the really hard thing is interviewing. How do you find good people from an interview? I don’t know the answer to that. We put people through on average 8 interviews and a pair programming exercise. We look at open source contributions. Sometimes we look at people’s degrees.

We tend to look for potential. An old boss used to say, “Don’t hire people who’ve already done the job, hire those who can learn to do it”. It’s an interesting idea. People naturally want to hire people who know how to do something. But technology changes all the time, so what you are really looking for are people who are curious.

And you won’t find curiosity by looking at degrees and qualifications. You’ll find it by asking about what people do and think. What they enjoy and what they’ve done when no one was looking.

Another thing that’s really important is to ask, “Can this person express themselves?”. It’s rare that it’s OK to have someone who can’t communicate with others. Sure, you may come across that one genius who you want to hire who only speaks in grunts. But real magic happens when teams (especially small teams of 3 to 12 people) make software together. And teams are built on communication. So, look for people who can express what they are thinking: might be through email, or drawing, or speaking.

You’re also going to find that you’ve hired the wrong people or built the wrong teams. Don’t be afraid to move people around. Last year 16% of people moved to a different job inside Cloudflare (not just teams!). You should constantly be looking at your teams and asking how well they are performing.

It’s not a failure to change a team, or reorganize, or move people about. In fact, it’s a failure as a manager to NOT do that.

Don’t be afraid to let people go.

It’s sad but you’ll think someone is great when you interview them and then they turn out not to be. Or someone gets too big for their boots and starts behaving like they own the place. Sometimes people need to leave the company. This is by far the worst thing a manager has to do (to this day I hate letting people go).

Over the last few years I’ve been in the position of having to decide whether to remove people from senior management positions in engineering. Making those decisions is really hard. You might enjoy working with someone but realize that their team isn’t doing so well, or they don’t seem to be achieving what you expect from them.

I know from my own experience I’ve always taken too long to make changes. I always want to give people a second or third chance. And usually it’s been a mistake. Actually, not usually, always. It’s unbelievably tough to say to someone “I don’t believe that you are the right person to be X and so I’ve decided to replace you”. But if you do that be 100% clear. It’s fairer to the person being moved on that they know that a concrete decision has been made.

I think one of the most important things I say to people who work for me is: “You need to tell me if the job you are doing isn’t making you happy”. Because I may not realize. I’m only human after all. One of my engineers took me up on that one day and I’m glad he did. This was someone who reported directly to me: a staff engineer with a ton of experience.

One day he came to me and said, “I don’t want to work for you any more, I want to work for X on Y”. Perhaps he was nervous to say that to me but putting people in jobs they enjoy is key. A manager isn’t successful because they grow a big team, they are successful when their team builds awesome software and awesome software gets built by people who feel they are doing their best work. That should be your goal: help people do their best work. Help people grow and learn.

There’s a lot of discussion in the software industry about diversity and inclusion. Many years ago, I had a small team of engineers in one of my first management jobs. There were five of us: Alice, Tanvi, Roman, Dan and me. Two women, three men. It was one of the most fun teams I’ve ever worked on because of that mixture of people and backgrounds. We built a really nice piece of software.

Lots of research shows that diverse teams are stronger, happier and do better work. You’re really losing out if you don’t have a diverse team. This is an area Cloudflare is working very hard on (and especially in the engineering team). Not because it’s trendy or cool, but because it means we’ll be a better, stronger, smarter company.

To do so we’ve looked at the language we use in job descriptions, the way we interview people, and how we source potential candidates. It also meant reviewing our benefits and internal policies to make sure that the company is attractive to all sorts of people. It’s working and I expect that by the end of 2019 we’ll be able to talk about all that we did.

Bottom line: there are great people out there from all sorts of backgrounds. Go find ‘em!

Final part is here.

• Part 1: How I came to work here

• Part 2: The Most Difficult Fortnight

• Part 3: Audacity, Diversity and Change

• Part 4: Public Engagement

• Part 5: People: Finding, Nurturing and Learning to Let Go (you are here)

• Part 6: What does Cloudflare's CTO do?

We don’t believe that any of our software, not a single line of code, provides us with a long-term advantage. We could, today, open source every single line of code at Cloudflare and we don’t believe we’d be hurt by it.

Why don’t we? We actually do open source a lot of code, but we try to be thoughtful about it. Firstly, a lot of our code is so Cloudflare-specific, full of logic about how our service works, that it’s not generic enough for someone else to pick up and use for their service. So, for example, open sourcing the code that runs our web front end would be largely useless.‌‌

But other bits of software are generic. There’s currently a debate going on internally about a piece of software called Quicksilver. I mentioned before that Cloudflare used a distributed key-value store to send configuration to machines across the world. We used to use an open source project called Kyoto Tycoon. It was pretty cool.‌‌

But it ended up not scaling to our size. It was great when we had a small number of locations worldwide, but we ran into operational problems with 100s of locations. And it wasn’t, by default, secure and so we had to add security to it. Once we did, we open sourced that change, but at some point when using open source software you have to make a “modify or rewrite” decision.‌‌

We’d done that in the past with PowerDNS. Originally our DNS service was based on PowerDNS. And it was great. But as we scaled, we ran into problems fitting it into our system. Not because there’s something wrong with PowerDNS but because we have a lot of DNS-related logic and we were shoehorning things into PowerDNS, and it was getting less and less maintainable for us. This was not PowerDNS' fault; we'd built such a large edifice of business logic around it that PowerDNS was being crushed by the sheer weight of that logic: it made sense to start over and integrate logic and DNS into a single code base.‌‌

Eventually we wrote our own server, RRDNS, in Go, that is now the code behind the largest and fastest authoritative DNS service on the planet. That’s another piece of software we haven’t open sourced. That one because it’s riddled with business logic and handling of special conditions (like the unique challenges of working inside China).‌‌

But back to Quicksilver. It’s based on LMDB and does all data and code sync. across our global network. Typically, a change (you click a button in our UI or you upload code for our edge compute product) and it’s distributed globally in 5s. That’s cool.‌‌

And Quicksilver is generic. It doesn’t contain lots of Cloudflare-specific logic and it’s likely useful for others. The internal debate is about whether we have time to nurture and handle the community that would grow up around Quicksilver. You may recently have seen the creator of Ruby saying on Twitter “We are mere mortals” pointing out that the people behind popular open source projects only have so much time. And we take a lesson from the creators of Kyoto Tycoon who have now largely abandoned it to do other things.‌‌

Perhaps Quicksilver will get open sourced this year, we’ll see. But our rule for open sourcing is: “Is this something others can use and is this something we have time to maintain in public?”. Of course, where we modify existing open source software, we upstream everything we can. Inevitably, some projects don’t accept our PRs and so we have to maintain internal forks.‌‌

While we’re on the topic of intellectual property let’s talk about patents. Cloudflare has a lot of patents. Although it might be nice to live in a world where there were no software patents it’s a little like nuclear weapons. It’s very hard for one country to disarm unilaterally because a power imbalance is left behind. If Cloudflare didn’t patent aspects of our software, then others would and would then use them against us.‌‌

So, we patent for defensive reasons. To stop others from using the patent system against us.‌‌

And speaking of patents let’s talk about governments. Lots of technology companies think they are too cool for school. They don’t need to think about governments because technology moves faster than them and what do those old, boring lawmakers know about anything anyway?‌‌

Wrong. Dead wrong.‌‌

Yes, governments move slowly. You actually want them to. Imagine if governments changed policies as fast as chat apps get launched. It would be a nightmare. But just because they are slow, they can’t be ignored.‌‌

Put simply governments have tanks and you don’t. Eventually lawmakers will make laws that affect you and unless you’ve spent time explaining to them what it is you do you may have a nasty surprise. ‌‌

Cloudflare decided very early on to engage with lawmakers in the US and Europe. We did this by helping them understand what is happening in the Internet, what challenges we foresee, and helping them with the technical arcana that we all deal with.‌‌

If there’s any chance that your business ends up being regulated by a government then you should engage early. Cloudflare thinks a lot about things like copyright law, the fight against online extremism, and privacy. We have to because our network is used by 13 million web sites and services and all manner of things pass through it.‌‌

Lots of times people get mad at us because they don’t like a particular customer on our network. This is tough for us because oftentimes we don’t like them either. But here’s the tricky thing: do you really want me, or Matthew, deciding what’s online? Because many times that’s what angry mobs are asking.‌‌

“Shut this down”, “Throw this off your service”. It’s odd that people are asking that corporations be gatekeepers when corporations answer to shareholders and not the people. The right answer is that if you see something you don’t like online: engage in the political process in your country.‌‌

The transparency of democratic institutions and, in particular, the judiciary is vital to the long-term survival of countries. It’s through those institutions that people need to express their desire for what’s allowed and not allowed. ‌‌

How do you engage with governments? Every single government has committees and advisory bodies that are dying to have people from industry help out. Go find the bodies that are doing work that overlaps with your company, don’t be put off by how old-fashioned they seem, and get involved.

On to part 5.

• Part 1: How I came to work here

• Part 2: The Most Difficult Fortnight

• Part 3: Audacity, Diversity and Change

• Part 4: Public Engagement (you are here)

• Part 5: People: Finding, Nurturing and Learning to Let Go

• Part 6: What does Cloudflare's CTO do?

After Cloudbleed, lots of things changed. We started to move away from memory-unsafe languages like C and C++ (there’s a lot more Go and Rust now). And every SIGABRT or crash on any machine results in an email to me and a message to the team responsible. And I don’t let the team leave those problems to fester.

So Cloudbleed was a terrible time. Let’s talk about a great time. The launch of our public DNS resolver 1.1.1.1. That launch is a story of an important Cloudflare quality: audacity. Google had launched 8.8.8.8 years ago and had taken the market for a public DNS resolver by storm. Their address is easy to remember, their service is very fast.‌‌

But we thought we could do better. We thought we could be faster, and we thought we could be more memorable. Matthew asked us to get the address 1.1.1.1 and launch a secure, privacy-preserving, public DNS resolver in a couple of months. Oh, and make it faster than everybody else.‌‌

We did that. In part we did it because of good relationships we’ve established with different groups around the world. We’ve done that by being consistent about how we operate and by employing people with established relationships. This is partly a story about how diversity matters. If we’d been the sort of people who discriminated against older engineers a lot of Cloudflare would not have been built. I’ll return to the topic of diversity and inclusion later.‌‌

Through relationships and sharing we were able to get the 1.1.1.1 address. Through our architecture we were able to be the fastest. Over years and years, we’ve been saying that Cloudflare was for everyone on the Internet. Everyone, everywhere. And we put our money where our mouths are and built 165 data centers across the world. Our goal is to be within 10ms of everyone who uses the Internet.‌‌

And when you’re everywhere it’s easy to be the fastest. Or at least it’s easy if you have an architecture that makes it possible to update software quickly and run it everywhere. Cloudflare runs a single stack of software on every machine world-wide. That architecture has made a huge difference versus our competitors and has allowed us to scale quickly and cheaply.‌‌

It was largely put in place before I joined the company. Lee Holloway (the original architect of the company), working with a small team, built a service based on open source components (such as Postgres and NGINX) that had a single stack of software doing caching, WAF, DDoS mitigation and more.‌‌

It was all bound together by a distributed key-value store to send configuration to every machine we have around the world in seconds. And centrally there was a large customer database in Postgres and a lot of PHP to create the public cloudflare.com web site.‌‌

Although we have constantly changed our software this architecture still exists. Early at Cloudflare I argued that there should be some special machines in the network doing special tasks (like DDoS mitigation). The truth is I wanted to build those machines because technically it would have been really exciting to work on that sort of large, complex low latency software. But Lee and Matthew told me I was wrong: a simple architecture could scale more easily.‌‌

And they were right. We’ve scaled to 25Tbps of network capacity with every machine doing every single thing. So, get the architecture right and make sure you’re building things for the right reasons.  Once you can scale like that, adding 1.1.1.1 was easy. We rolled out the software to every machine, tested it and made it public. Overnight it was the fastest public DNS resolver there is and remains so.‌‌

Naturally, our software stack has evolved a lot since Lee started working on it. And most parts of it have been rewritten. We’ve thrown away all the code that Matthew Prince wrote in PHP from the earliest days, we’ve started to throw away code that I wrote in Lua and Go. This is natural and if you’re looking back at code you wrote five years ago and you’re feeling that it’s still fit for purpose then you are either fooling yourself or not growing.‌‌

It seems that about every order of magnitude change in use of software requires a rewrite. It’s sad that you can’t start with the ultimate code base and ultimate architecture but the reality is that it’s too hard to build the software you need for today’s challenges and so you can’t worry about tomorrow. It’s also very hard to anticipate what you’ll actually need when your service grows by 10x.‌‌

When I joined most of our customers had a small number of DNS records. And the software had been built to scale to thousands or millions of customers. Each with a small number of records. That’s because our typical customer was a small business or individual with a blog. We were built for millions of them.‌‌

Then along came a company that had a single domain name with millions of subdomains. Our software immediately fell over. It just wasn’t built to cope with that particular shape of customer.‌‌

So, we had to build an immediate band aid and start re-architecting the piece of software that handled DNS records. I could tell you 10 other stories like that. But the lesson is clear: you don’t know what to expect up front so keep going until you get there. But be ready to change quickly.

• Part 1: How I came to work here

• Part 2: The Most Difficult Fortnight

• Part 3: Audacity, Diversity and Change (you are here)

• Part 4: Public Engagement

• Part 5: People: Finding, Nurturing and Learning to Let Go

• Part 6: What does Cloudflare's CTO do?

It’s always best to speak plainly and honestly about the situation you are in. Or as Matthew Prince likes to put it “Panic Early”. Long ago I started a company in Silicon Valley which had the most beautiful code. We could have taught a computer science course from the code base. But we had hardly any customers and we failed to “Panic Early” and not face up to the fact that our market was too small.

Ironically, the CEO of that company used to tell people “Get bad news out fast”. This is a good maxim to live by, if you have bad news then deliver it quickly and clearly. If you don’t the bad news won’t go away, and the situation will likely get worse.

Cloudflare had a very, very serious security problem back in 2017. This problem became known as Cloudbleed. We had, without knowing it, been leaking memory from inside our machines into responses returned to web browsers. And because our machines are shared across millions of web sites, that meant that HTTP requests containing potentially very sensitive information could have been leaked.

Worse this information was being cached by search engines. So, anyone could go to Google or Bing or Baidu and look for sensitive information just by knowing a few keywords. Luckily, for us, Google’s Project Zero discovered that we were leaking by looking at Google’s crawler cache. They informed us and we were quickly able to stop the leak.

But that didn’t diminish the fact that private information (much of which would have been transmitted encrypted) had been cached by search engines. Although we stopped the leak within 45 minutes the cleanup task was massive. It was massive firstly because we had to find what had been leaked and secondly because we had to find all the search engines with caches and somehow ask them to delete cached data.

None of the search engines had handled something like this before. We were asking for mass deletion of data and it took a long time (at least it felt like a long time) to get to the right people and start to get cached data deleted.

From the very first night of Cloudbleed I started collecting information to be able to write the public disclosure. Ultimately, when Project Zero wanted to go public, we were ready with a long, transparent blog post on the subject and were able to talk about it.

It was, by far, the most difficult week of my career. Firstly, we had the bug itself, secondly, we had the cleanup, and then we had to tell people what had happened. Throughout that week I barely slept (and I am not exaggerating) and a large team of people across Cloudflare in the US, UK and elsewhere kept in contact constantly. We learnt that it’s possible to keep a Google Hangout between two offices running, literally, for days without interruption.

The hardest thing was that we seriously did not know, at the beginning, whether Cloudflare would survive. Right at the start it looked terrible, it was terrible, and we had two questions: “What private data has actually been leaked and cached?” and “Did anyone find this and actively exploit it?”.

We answered both by extensive searching and collating of information from search engines. Ultimately, myself and others called customers and spoke to them on the phone. We were able to tell them what we’d found and statistically what was likely to have leaked.

The second question was answered by looking for evidence of exploitation in our logging systems. But there was something very tricky: Cloudflare had long limited the amount of data it logs for privacy reasons. So, we had to dig into statistical analysis of all sorts of data (crash rates, saved core dumps, errors in Sentry, sampled data) to look for exploitation.

We split into separate teams to look for different evidence and only myself and Matthew Prince knew what each team was seeing. We did that because we didn’t want one team to influence another. We wanted to be sure that we were right before publishing our second blog with more detailed information.

We didn’t find evidence of exploitation. And while serious, the data cached in search engines was found to contain little really private information. But it was very, very serious and we all knew that this could have been worse.

Although I look back at those two weeks as the worst of my career, to quote Charles Dickens: “It was the best of times, it was the worst of times”. Most of the company didn’t know Cloudbleed had happened until we went public. The morning it became public I showered very early and took a cab to the office.

Normally, the office is quite quiet in the morning and I was stunned to walk into an office full of people. People who asked me “What can we do?”. It was an incredible feeling. We printed a large poster of Winston Churchill staring down at the team saying, “If you’re going through Hell, keep going!”. Everyone pitched in.

In the middle of it someone from the press, the BBC I think, asked me if I’d changed any passwords because of Cloudbleed. I said I had not. And that was true. I didn’t change anything personally. But in the middle of that firestorm I took a lot of criticism from armchair critics for that.

Although terrible, Cloudbleed reinforced the culture of Cloudflare: openness and helping others. We were all in together and we got through it. And our customers saw that: we didn’t lose major customers, in fact, we gained customers who told us “We want to work with you because you were so open”.

• Part 1: How I came to work here

• Part 2: The Most Difficult Fortnight (you are here)

• Part 3: Audacity, Diversity and Change

• Part 4: Public Engagement

• Part 5: People: Finding, Nurturing and Learning to Let Go

• Part 6: What does Cloudflare's CTO do?

Here's part 1:

I’ve worked at Cloudflare for more than seven years. Cloudflare itself is more than eight years old. So, I’ve been there since it was a very small company. About twenty people in fact. All of those people (except one, me) worked from an office in San Francisco. I was the lone member of the London office.

Today there are 900 people working at Cloudflare spread across offices in San Francisco, Austin, Champaign IL, New York, Washington D.C., London, Munich, Singapore and Beijing. In London, my “one-person office” (which was my spare bedroom) is now almost 200 people and in a month, we’ll move into new space opposite Big Ben.

The original Cloudflare London "office"

The numbers tell a story about enormous growth. But it’s growth that’s been very carefully managed. We could have grown much faster (in terms of people); we’ve certainly raised enough money to do so.

I ended up at Cloudflare because I gave a really good talk at a conference. Well, it’s a little more complex than that but that’s where it all started for me without me knowing it. Fifteen years ago, a guy called Paul Graham had started a conference at MIT in the US. At the time Paul Graham was known for being an expert LISP programmer and for having an idea about how to deal with email spam. It wasn’t until a year later than he started Y Combinator.

Paul invited me to give a talk at this MIT Spam Conference about an open source machine learning email filter program I had written. So, I guess the second reason I ended up at Cloudflare is that I wrote some code and open sourced it. That program is called POPFile and you can still download it today (if you’d like your email sorted intelligently).

I wrote POPFile because I had an itch to scratch. I was working at a startup in Silicon Valley and I was receiving too much email. I used Microsoft Outlook and I wanted my mail sorted into different categories and so I researched techniques for doing that and wrote my own program. The first version was in Visual Basic, the second in Perl.

So, I got to Cloudflare because of a personal itch, open source, public speaking and two languages that many people look down on and joke about. Be wary of doing that. Although languages do make a difference the skill of a programmer in their chosen language matters a lot.

If there’s a lesson in there it’s… share with others. Share through open source, through giving talks, and through how you interact with others. The more you give the more people will appreciate you and the more opportunity you will have. There’s a great book about this called Give and Take by Adam Grant. We gave everyone at Cloudflare a copy of that book.

One of the people who saw me speak at MIT was Matthew Prince, Cloudflare’s CEO. Matthew was speaking also. He saw me speak and thought I was interesting, and I saw him speak and thought the same thing.

Over a period of years Matthew and I stayed in contact and when he, Michelle and Lee started Cloudflare he asked me to join. It was the wrong time for me and, to be honest, I had a lot of doubts at the time about Cloudflare. I didn’t think many people would sign up for the service.

I’m glad I was wrong. And I am glad that Matthew was persistent in trying to get me to join. Today there are over 13 million domains registered to Cloudflare and I have ended up as CTO. But I wasn’t hired as CTO and it wasn’t my ambition. I joined Cloudflare to work with people I liked and to do cool stuff.

I’m very lucky that my background, upbringing, parents and career have enabled me to work with people I like and do cool stuff. The cool stuff changes of course. But that’s technology for you.

When I was first at Cloudflare I went to quite a few meetings with Matthew. Especially meetings with investors and people would always ask him in a jovial manner “How’s it going?” and he would always answer “It’s terrible”. At first, I thought he was just being silly and was playing for a laugh to see how people would react.

In part, he was doing that but there’s also a lot of truth in the fact that startups are “terrible”. They are very, very hard. It’s very easy to get distracted by the huge successes of a small number of companies and not face the reality that building a company is hard work. And hard work isn’t enough. You might not have enough money, or the right people, or you might discover that your market is too small.

Silicon Valley lives in a schizophrenic state: everyone outwardly will tell you how they are “crushing it” and doing so well. But inside they are full of fear and doubt. Mentally that’s a very hard thing to sustain and it’s not surprising that some people suffer mental health problems because of it. We shouldn’t be ashamed of admitting that things are hard, as Matthew did.

Silicon Valley also likes to use very positive language for things that might be a little negative or tough. One such term is “pivot”. There’s nothing wrong with changing direction or responding to customer or market demands. But face it with reality that you had to change direction. That’s OK. To quote George Bernard Shaw: “Progress is impossible without change, and those who cannot change their minds cannot change anything”.

Part two is here.

• Part 1: How I came to work here (you are here)

• Part 2: The Most Difficult Fortnight

• Part 3: Audacity, Diversity and Change

• Part 4: Public Engagement

• Part 5: People: Finding, Nurturing and Learning to Let Go

• Part 6: What does Cloudflare's CTO do?

I have always loved birthdays. It is a chance to get together with loved ones, a chance to have fun and a chance to reflect on anything you want to keep doing or change in the upcoming year. At Cloudflare, we’ve embraced celebrating our birthday as well.

This week, Cloudflare turns 8 years old. It feels like just yesterday that Matthew, Lee, Matthieu, Ian, Sri, Chris, Damon and I stepped on stage at Techcrunch Disrupt to launch Cloudflare to the world. Since then, we have celebrated our birthday every year by giving a gift back to our customers and the Internet. This year, we plan to celebrate each day with a new product benefiting our community. Or in other words, it is a weeklong birthday celebration. Like I said, I love birthdays!

The Cloudflare team when we launched the service at Techcrunch Disrupt during September 27 to 29, 2010 – Matthieu, Chris, Sri, Ian, Lee, Matthew, Michelle and Damon.

While I can’t share exactly what we’re releasing every day — after all who doesn’t like a surprise? — I wanted to share some thoughts on how we decide what to release birthday week.

Our mission at Cloudflare is to help build a better Internet. That is a big, broad mission that means many things. It means that we push to make Internet properties faster. It means respecting individual’s privacy. It means making it harder for malicious actors to do bad things. It means helping to make the Internet more reliable. It means supporting new Internet standards and protocols, and making sure they are accessible to everyone. It means democratizing technology and making sure the widest possible group has access to it. It means increasing value for our community, while decreasing their costs. Here is more color on each:

As more applications go online, users expect the interactions to be fast. It is hard to imagine a world where people want a slower Internet experience. It’s the exact opposite — and will only continue.

Speed means high bandwidth and low latency. As we move along these two axes, more applications emerge. Music on the Internet was unlocked at a certain level of bandwidth. Video required more. Videoconferencing has both bandwidth and latency requirements. These technologies are reshaping entire industries — and having a impact on societies globally.

What’s exciting to me is that there are a whole host of further applications that will be unlocked as we continue to increase the speed of the internet. One of the things that will enable this is edge computing — moving the cloud closer to the internet visitors. Cloudflare released Workers a year ago (on our 7th Birthday), and we are so excited by what developers around the world are doing with it. We know a whole new set of applications are being planted right now and will emerge over the next 18 months because of this gained speed.

When we announced 1.1.1.1, our fast and private DNS service for consumers, we were blown away by the reception in the marketplace. People do care about their privacy and they are looking for solutions that understand that. When we build a product, we always ask ourselves how does this impact an individual’s privacy? We want to be a leader in terms of privacy.

The promise of Cloudflare has been to band businesses, people and organizations together to be stronger than the malicious actors. It’s the first time where the resources for the good people have outweighed resources for the bad people. Today, Cloudflare offers a broad security portfolio to its customers and we constantly work to make the services we have better, and to expand our scope. You will see our development in new areas on the security front this upcoming week.

While speed matters in unlocking new applications, so does reliability. There are a whole host of applications that can only be unlocked if they can depend on the internet being there. Transportation is one example; health care is another. If the internet breaks for these applications, life threatening things can start to happen very quickly, just as they would be if power was lost to these applications. But it’s not just examples where lives can get lost — if you’ve been in an office when the wifi has gone out, you’ll know that more and more businesses depend on the internet just to get day to day operations done. Cloudflare is committed to being at the forefront of a more reliable internet.

The original internet was designed as a decentralized network. One of the principles that enabled this to happen was to have a series of open standards that everyone agreed upon, as opposed to a series of balkanized networks that were all talking their own language. The original set of principles gave everyone a common language. This open set of standards let thousands of ideas bloom, and it is part of what has made the internet so great. We’re committed to that idea.

At the same time, the Internet is over 35 years old. Many smart, talented engineers around the world have come up with new protocols and standards that are faster and safer than the original protocols. But, getting these new protocols and standards distributed is difficult. We want to help distribute and drive adoption of new standards and protocols, and make access  easier for our customers. We’ve done it with HTTPS, SPDY, HTTP2, DNSSEC and there are more to come.

It is kind of crazy to think about the amount of timely information that we have access to today because of the Internet. And by and large, how it’s possible to communicate with any other person on the planet. But this only holds true if everyone is able to access the Internet. What do we mean by that? Well, it in turn breaks down into two further principles: democratization and affordability.

It’s one thing to have an open standard. That, in theory, allows anyone who understands the standard to participate. But go back to the early days of the web, and you really had to be a “techie” to be able to participate.

We’ve come a long way since those days; in terms of user clients, we’ve gone from a command line interface to a supercomputer with touch screens in our pockets. But there’s more to democratizing technology than just making it easier from the perspective of a consumer. There are also all the small businesses that are now possible, that were not previously so, because these entrepreneurs can use the internet to directly reach customers. It’s enabled all sorts of products and services that were not previously possible.

Many of those businesses would not be able to start if the tools and infrastructure required to get going are beyond their technical grasp. One of the things that Cloudflare has been committed to from the start is taking complicated and technical solutions and making it easy enough for a non-technical person to use. We have wanted to expand the number of Internet properties who have access to these services. Millions of customers around the world fit this profile. We might have one of the fastest and most secure networks on the web fit for enterprises like New York Stock Exchange and IBM. But if you’re a one man shop just getting started, you shouldn’t need an IT team to be able to make your website fast and secure. With Cloudflare, you don’t have to.

As the Internet grows, it becomes more valuable, and capabilities become lower cost. This is one of the powers of network effects. We have many examples of this at Cloudflare. We want more connections to other Internet providers around the world so that we can pass bandwidth savings along to our customers. Or, last year during our 7th Birthday, we pushed our DDoS mitigation technology to all of our plans, including the Free plan. This is technology that used to cost at least $10K/month. We are always looking to deliver more value to our customers. It is a daily topic around Cloudflare.

So, back to our Birthday Week. Every announcement this week ties back to helping to build a better Internet in some way. Here is a preview of this week’s releases:

• On Monday, we are releasing something that will make the Internet more private and secure for every user.

• On Tuesday, we are leading the way democratizing a new Internet standard, while also making the Internet faster.

• On Wednesday, we are bringing together a coalition of partners to help our customers lower their infrastructure costs — dramatically.

• On Thursday, our actual birthday, we are releasing a new service we hope you’ll love that provides something that every one of our customers needs, but now with the best security and lowest price.

• On Friday, we are releasing a new product that pushes the power of the Internet forward by making it more programmable.

I often get asked what makes Cloudflare special? My answer always comes back to the people I work with and our partners who work passionately to delight our customers. The Cloudflare team comes to work every day to solve the tough challenges of the Internet to ultimately help build a better Internet going forward. This week, I am excited to share our work with all of you.

Every day, we will be posting a blog post at 1200 UTC with that day’s announcement. We will do a round up at the end of the week as well. I can’t wait to hear what you think!

The three Cloudflare co-founders: Matthew Prince, Michelle Zatlyn and Lee Holloway

Launching Cloudflare at Techcrunch Disrupt in September 2010 to a panel of esteemed judges

Matthew Prince, our CEO, presenting Cloudflare to a group of entrepreneurs.

The three co-founders, Michelle Zatlyn, Lee Holloway and Matthew Prince, at one of our office openings early on

Subscribe to the blog for daily updates on all our Birthday Week announcements.

CC-BY 2.0 image by Steve Jurvetson

Today Cloudflare’s DNS service answers around 1 million queries per second – not including attack traffic – via a global anycast network. Naturally as a growing startup, the technology we used to handle tens or hundreds of thousands of zones a few years ago became outdated over time, and couldn't keep up with the millions we have today. Last year we decided to replace two core elements of our DNS infrastructure: the part of our DNS server that answers authoritative queries and the data pipeline which takes changes made by our customers to DNS records and distributes them to our edge machines across the globe.

The rough architecture of the system can be seen above. We store customer DNS records and other origin server information in a central database, convert the raw data into a format usable by our edge in the middle, and then distribute it to our >100 data centers (we call them PoPs - Points of Presence) using a KV (key/value) store.

The queries are served by a custom DNS server, rrDNS, that we’ve been using and developing for several years. In the early days of Cloudflare, our DNS service was built on top of PowerDNS, but that was phased out and replaced by rrDNS in 2013.

The Cloudflare DNS team owns two elements of the data flow: the data pipeline itself and rrDNS. The first goal was to replace the data pipeline with something entirely new as the current software was starting to show its age; as any >5 year old infrastructure would. The existing data pipeline was originally built for use with PowerDNS, and slowly evolved over time. It contained many warts and obscure features because it was built to translate our DNS records into the PowerDNS format.

In the old system, the data model was fairly simple. We’d store the DNS records roughly in the same structure that they are represented in our UI or API: one entry per resource record (RR). This meant that the data pipeline only had to perform fairly rudimentary encoding tasks when generating the zone data to be distributed to the edge.

Zone metadata and RRs were encoded using a mix of JSON and Protocol Buffers, though we weren’t making particularly good use of the schematized nature of the protocols so the schemas were very bloated and the resulting data ended up being larger than necessary. Not to mention that as the number of total RRs in our database headed north of 100 million, these small differences in encoding made a significant difference in aggregate.

It’s worth remembering here that DNS doesn’t really operate on a per-RR basis when responding to queries. You query for a name and a type (e.g example.com and AAAA) and you’ll be given an RRSet which is a collection of RRs. The old data format had RRSets broken out into multiple RR entries (one key per record) which typically meant multiple roundtrips to our KV store to answer a single query. We wanted to change this and group data by RRSet so that a single request could be made to the KV store to retrieve all the data needed to answer a query. Because Cloudflare optimizes heavily for DNS performance, multiple KV lookups were limiting our ability to make rrDNS go as fast as possible.

In a similar vein, for lookups like A/AAAA/CNAME we decided to group the values into a single “address” key instead of one key per RRset. This further avoids having to perform extra lookups in the most common cases. Squishing keys together also helps reduce memory usage of the cache we use in front of the KV store, since we’re storing more information against a single cache key.

After settling on this new data model, we needed to figure out how to serialize the data and pass it to the edge. As mentioned, we were previously using a mix of JSON and Protocol Buffers, and we decided to replace this with a purely MessagePack-based implementation.

MessagePack is a binary serialization format that is typed, but does not have a strict schema built into the format. In this regard, it can be considered a little like JSON. For both the reader and the writer, extra fields can be present or absent and it’s up to your application code to compensate.

In contrast, Protocol Buffers (or other formats like Cap’n Proto) require a schema for data structures defined in a language agnostic format, and then generate code for the specific implementation. Since DNS already has a large structured schema, we didn’t want to have to duplicate all of this schema in another language and then maintain it. In the old implementation with Protocol Buffers, we’d not properly defined schemas for all DNS types – to avoid this maintenance overhead – which resulted in a very confusing data model for rrDNS.

When looking for new formats we wanted something that would be fast, easy to use and that could integrate easily into the code base and libraries we were already using. rrDNS makes heavy use of the miekg/dns Go library which uses a large collection of structs to represent each RR type, for example:

type SRV struct {
	Hdr      RR_Header
	Priority uint16
	Weight   uint16
	Port     uint16
	Target   string `dns:"domain-name"`
}

When decoding the data written by our pipeline in rrDNS we need to convert the RRs into these structs. As it turns out, the tinylib/msgp library we had been investigating has a rather nice set of code generation tools. This would allow us to auto-generate efficient Go code from the struct definitions without having to maintain another schema definition in another format.

This meant we could work with the miekg RR structs (of which we are already familiar with from rrDNS) in the data pipeline, serialize them straight into binary data, and then deserialize them again at the edge straight into a struct we could use. We didn't need to worry about mapping from one set of structures to another using this technique, which simplified things greatly.

MessagePack also performs incredibly well compared to other formats on the market. Here’s an excerpt from a Go serialization benchmarking test; we can see that on top of the other reasons MessagePack benefits our stack, it outperforms pretty much every other viable cross-platform option.

One unexpected surprise after switching to this new model was that we actually reduced the space required to store the data at the edge by around 9x, which was a significantly higher saving compared to our initial estimates. It just goes to show how much impact a bloated data model can have on a system.

Another very important feature of Cloudflare’s DNS is our ability to propagate zone changes around the globe in a matter of seconds, not minutes or hours. Our existing pipeline was struggling to keep up with the growing number of zones, and with changes to at least 5 zones each second, even at the quietest of times we needed something new.

For a while now we’ve had this monitoring, and we are able to visualize propagation times across the globe. The graph below is taken from our end-to-end monitoring: it makes changes to DNS via our API and watches for the change from various probes around the world. Each dot on the graph represents a particular probe talking to one of our PoPs, and the delay is tracked as the time it took for a change made via our API to be visible externally.

Due to various layers of caches – both inside and outside of our control – we see some banding on 10s intervals under 1 minute, and it fluctuates all the time. For monitoring and alerting of this nature, the granularity we have here is sufficient but it’s something we’d definitely like to improve. In normal operation, new DNS data is actually available to 99% of our global PoPs in under 5s.

In this time frame we can see there were a couple of incidents where delays of a few minutes were visible for a small number of PoPs due to network connectivity, but generally all probes reported stable propagation times.

In contrast, here’s a graph of the old data pipeline for the same period. We can see how the graph represents the growing delay in visible changes for all PoPs at any given time.

With a new data model designed and ready to go, one that better matched our query patterns, we set out implementing a new service to pick up changes to our zones in the central data store, do any needed processing and send the resulting output to our KV store.

The new service (written in our favourite language Go) has been running in production since July 2016, and we’ve now migrated over 99% of Cloudflare customer zones over to it. If we exclude incidents where issues with congestion across the internet affect connectivity to or from a particular location, the new pipeline itself has experienced zero delays thus far.

rrDNS is a modular application, which allows us to write different “filters” that can hand off processing of different types of queries to different code. The Authoritative filter is responsible for taking an incoming DNS query, looking up the zone the query name belongs to, and performing all relevant logic to find the RRSet to send back to the client.

Since we’ve completely revised the underlying DNS data model at our edge, we needed to make significant changes to the “Authoritative Filter” in rrDNS. This too is an old area of the code base that hasn’t significantly changed in a number of years. As with any ageing code base, this brings a number of challenges, so we opted to re-write the filter completely. This allowed us to redesign it from the ground up on our new data model, keeping a keen eye on performance, and to better suit the scale and shape of our DNS traffic today. Starting fresh also made it much easier to build in good development practices, such as high test coverage and better documentation.

We’ve been running the v2 version of the authoritative filter in production alongside the existing code since the later months of 2016, and it has already played a key role in the DNS aspects of our new load balancing product.

The results with the new filter have been great: we’re able to respond to DNS queries on average 3x faster than before, which is excellent news for our customers and improves our ability to mitigate large DNS attacks. We can see here that as the percentage of zones migrated increased, we saw a significant improvement in our average response time.

The most time consuming part of the project was migrating customers from the old system to something entirely new, without impacting customers or anybody noticing what we were doing. Achieving this involved a significant effort from variety of people in our customer facing, support and operations teams. Cloudflare has many offices in different time zones – London, San Francisco, Singapore and Austin – so keeping everyone in sync was key to our success.

Already, as a part of the release process for rrDNS we automatically sample and replay production queries against existing and upcoming code to detect unexpected differences, so naturally we decided to extend this idea for our migration. For any zone to pass the migration test, we compared the possible answers for the entire zone from the old system and the new system. Just one failure would result in the tool skipping the zone.

This allowed us to iteratively test the migration of zones and fix issues as they arose, keeping releases simple and regular. We chose not to do a single – and very scary – switch away from the old system, but run them both in parallel and slowly move zones over keeping them both in sync. Meaning we quickly could migrate zones back in case something unexpected happened.

Once we got going we were safely migrating zones at several hundred thousand per day, and we kept a close eye on how far we were from our initial goal of 99%. The last mile is still in progress, as there is often an element of customer engagement for some complex configurations that need attention.

Replacing a piece of infrastructure this core to Cloudflare took significant effort from a large variety of teams. So what did we gain?

• Average of 3x performance boost in code handling DNS queries

• Faster and more consistent updates to DNS data around the globe

• A much more robust system for SREs to operate and engineers to maintain

• Consolidated feature-set based on today’s requirements, and better documentation of edge case behaviours

• More test coverage, better metrics and higher confidence in our code, making it safer to make changes and develop our DNS products

Now that we’re now able to process our customers DNS more quickly, we’ll soon be rolling out support for a few new RR types and some other exciting new things in the coming months.

Does solving these kinds of technical and operational challenges excite you? Cloudflare is always hiring for talented specialists and generalists within our Engineering, Technical Operations and other teams.

CC BY 2.0 image by d26b73

If anyone, border agents or others, wants more detail I usually say: “If you run a web site or API for an app and you are Amazon.com, Google, Yahoo or one of a handful of major Internet sites you have the expertise to stay on top of the latest technologies and attacks; you have the staff to accelerate your web site and keep it fully patched. Anyone else, and that’s almost every web site on the Internet, simply will not have the money, people, or knowledge to ‘be a Google’. That’s where CloudFlare comes in: we make sure to stay on top of the latest trends in the Internet so that every web site can ‘be Google’."

The author William Gibson has said many times: “The future is already here — it's just not very evenly distributed.” And that applies to the Internet as well. Companies like Google already have web sites that are ‘in the future’ compared to most of the Internet.

CloudFlare believes that the future should be evenly distributed and our service is designed to provide the most up to date Internet experience whether a web site is large or small without installing software or buying and maintaining hardware.

Although great effort is made to ensure that the web remains backwards compatible (yes, you can still surf the original Space Jam web site from 1996) users of the web expect a fast, safe experience and that means keeping up with changing technology. And they expect to be able to access the web on mobile devices and desktop computers. It’s not possible for a web site to stand still.

Organizations like the IETF and W3C are constantly working to improve the Internet with technologies like IPv6, HTTP/2, HTML5 and TLS 1.3, and there are constant micro-improvements (for example, the ever changing set of recommended SSL/TLS cipher suites or changes to hints to allow web browsers to preload content or new compression algorithms like Brotli). It’s almost impossible for someone managing a web site to stay up to date.

As well as changes to the underlying technology hackers and attackers are also innovating. Protecting web sites requires a layered defense that’s constantly updating as DDoS techniques change and volumes go up, and as vulnerabilities are found in web sites.

CC BY 2.0 cropped image by Incase

As the Internet itself grows and more and more people get online web sites face another problem: unexpected popularity. Large web properties, like Google, have big, fat connections to the Internet, lots of servers and load balancers to help their web sites cope with an influx of traffic. For others, unexpected popularity (be it a link on the front page of Reddit, a mention on a major TV program, or a sudden Twitter storm) can be a hug of death where the one time the web site definitely needs to be online it’s offline because it can’t cope.

Add to that the curse of DDoS attacks, which get directed at web sites large and small, it’s very hard for a web site operator to stay up to date and safe.

In the past web sites wanting to ‘be a Google’ often spent a small fortune on hardware devices and virtual appliances such as giant routers, DDoS mitigation boxes, specialized firewalls, load balancers and had to maintain piles of servers to deal with traffic spikes.

CC BY 2.0 image by Forsaken Fotos

All that hardware brought its own problems: firmware needs updating and web sites are locked into the features that a particular vendor provides. If a front-end load balancer doesn’t provide support for HTTP/2 there’s little to be done other than make the expensive decision to switch to some other hardware.

Updates to hardware firmware first have to be made available by the vendors of the hardware and then scheduled. The hardware becomes yet another thing to maintain (at great initial and ongoing cost) and often lags behind the latest Internet innovations and attacks. And the hardware itself can lag behind as LAN technologies inevitably scale up from 1Gbps through 10Gbps onwards to 100Gbps and so on.

During the severe Heartbleed problem the hardware load balancers from one large vendor were vulnerable and leaking private information and it required an emergency patch by the vendor to be distributed to everyone who had a support contract for the hardware. Between the time the vulnerability was disclosed and the time end users patched their hardware the bug was being actively exploited across the Internet.

As I mentioned above in the case of Heartbleed, there’s an inherent gap between when a security problem is disclosed (and the black hat community immediately starts exploiting it) and the patching of end user hardware and software. This happens over and again.

CC BY-SA 2.0 cropped image by drivethrucafe

Back in 2014 a nasty bug named Shellshock emerged that affected many, many web sites. CloudFlare immediately rolled out protection for all our customers. As Wikipedia points out there were reports of web sites hacked using Shellshock within one hour of its disclosure. A day later botnets had been created by exploiting this vulnerability and were performing DDoS attacks. Five days after the disclosure we'd blocked north of 1.1 million attacks attempting using Shellshock.

Recently, a vulnerability in the ImageMagick image manipulation software caused web sites to be hacked. Once again we rolled out protection for customers using our WAF and saw the vulnerability being exploited by black hats immediately.

This gap between when a vulnerability is made public (and starts getting exploited) and when a web site owner updates their software or firmware creates a real opportunity for hackers. CloudFlare protection buys web site owners time to update and protect themselves and prevents them getting hacked.

CloudFlare consistently pushes out new Internet technologies so that our customers have the latest, fastest and safest Internet experience, but it also does so for another reason: there’s nothing like actual experience with a technology. If you want to provide the most up to date technology you have to stay ahead of the future.

CC BY-SA 2.0 image by Livid Instruments

For both CloudFlare and our customers it makes sense to have the latest technologies available for testing and use as soon as possible. For example, a customer may want to start optimizing their web site for HTTP/1.1 and HTTP/2; because CloudFlare offers HTTP/2 service they can quickly start testing different configurations in the real world.

Or a customer may want to start experimenting with HTTP/2 Server Push to see how much of a speedup they can obtain for their web site or app. Once again, CloudFlare makes that available.

Or a customer may have realized that IPv6 is fast becoming an important technology because it's faster than IPv4 in many cases. CloudFlare has provided IPv6 for years.

Equally, CloudFlare gains useful experience from testing and deploying new technologies. We recently spent time doing a deep analysis of the Brotli compression algorithm to understand how it would perform for our customers. It’s up and running on our public test server for those that like to live on the bleeding edge.

Equally, we've rolled cryptographic algorithms like ChaCha20-Poly1305 to give mobile users fast, secure connections with better battery life. We're now experimenting with TLS 1.3 to ensure that our customers stay up to date with the latest in secure Internet.

Web performance, web security and web attacks evolve and improve rapidly. People expect an almost instant response from web sites and apps, and to have high security. Web site and API owners need protection from the latest security vulnerabilities and to supply that fast, rich experience to users.

Hardware appliances no longer fit the bill. They get upgraded less frequently than their owners change mobile phones and the only people who think of them as an asset work in finance.

CC BY-SA 2.0 image by jimmy thomas of the ghost town of Cisco, UT terminated by the demise of the steam locomotive

1. The full version of that is "We reject kings, presidents and voting. We believe in rough consensus and running code" ↩︎

This blog post is probably more personal than the usual posts here. It’s about why I joined CloudFlare.

I’ve been working on DNSSEC evolution for a long time as implementor, IETF working group chair, protocol experimenter, DNS operator, consultant, and evangelist. These different perspectives allow me to look at the protocol in a holistic way.

First and foremost, it’s important to realize the exact role of DNSSEC. DNSSEC is actually a misnomer: it’s from an era when the understanding of different security technologies, and what role each plays, was not as good as today. Today, this protocol would be called DNSAUTH. This is because all it does is to provide integrity protection to the answers from authoritative servers.

Over the years, the design of DNSSEC has changed. A number of people working on early versions of DNSSEC (myself included) didn’t know DNS all that well. Similarly, many DNS people at the time didn’t understand security, and in particular, cryptography all that well. To make things even more complex, general understanding of the DNS protocol was lacking in certain areas and needed to be clarified in order to do DNSSEC properly. This has led to three major versions of the protocol. The first two were not deployable for various reasons. Some of the decisions made, in hindsight, were sub-optimal. They were artifacts of constraints placed on the design by the DNS protocol itself, understanding of DNS, and various operational realities. DNSSECv3 [RFC403x], however, is deployable.

Today, we have wide spread deployment of the crucial building blocks for DNSSEC:

• Root and TLDs: over 2/3’rds of the TLDs are signed

• Most DNS software is DNSSEC enabled

• Many registrars offer their customers DNSSEC support either by signing the customers zones or by adding DS records into the parent zones.

What’s missing is having Enterprise zones signed, and turning on validation in resolvers and clients. It’s estimated that over 10% of all user DNS answers today are validated, but how much is validated in data centers is unknown.

DNSSEC deployment has been what I call a game of “excuse elimination”. First it was “com will never be signed”, then “the root will never be signed”, then “the answers will be too big”, and so on. Right now, the main excuse is, “this important domain is not signed”. Getting CDNs to sign is a great step towards getting the important domains signed. This is because CDNs frequently act as DNS operators for such domains.

So what does all of this have to do with me joining CloudFlare? Well, when a friend mentioned to me that CloudFlare was looking for a DNS person I checked them out. CloudFlare impressed me by wanting to do things correctly right from the beginning, and people here are not afraid to do things differently if it’s better. CloudFlare had been thinking about doing DNSSEC, and wanted me to help them implement and deploy it. This is turning out to be a fun project not just because of the scale, but also because of the ability to take a fresh perspective and questioning all prior assumptions.

CloudFlare’s DNS servers provide answers from over 30 anycasted data centers all over the world. We operate lots of DNS servers—authoritative for millions of zones. Not all the servers return the same answers to all clients because of policies and locations. Furthermore, much of the DNS data we serve has geographical bias. Thus, some data centers never see a query for that data. In this environment the only realistic way to answer the question is to generate the signatures at the edge on demand. This is a radical departure from most DNSSEC implementations, but there are few implementations like PowerDNS that have this capability. What online signing does is significantly reduce the volume of data that has to be transferred to the edge. We’ve designed our systems to only transfer signed DNSKEY (and CDS) records to the edges, while everything else is signed there. This requires transferring the zone signing keys to the edge.

CloudFlare is a frequent target of DNS attacks, both against our customers and as an reflector/amplifier. For that reason, we are fanatical about keeping DNS answers as small as possible to minimize the damage our systems can do to others when used as a reflector. This has directed us in a number of choices on how we do DNSSEC.

First, we use the Elliptic Curve algorithm ECDSA P-256. A ECDSA key is stronger than most RSA keys used today and the signatures are much smaller. Also, it takes fewer CPU cycles to generate the signatures than with RSA making this is a double win for us. When we started on the project, we found only one Validating Resolver implementation that did not support ECDSA. We reached out to them and now Google Public DNS correctly validates ECDSA!

Second, we do negative answers in a special way. Negative answers in DNSSEC can get large. For zones signed with NSEC, it’s not uncommon to have SOA + RRSIG(SOA) + 2 NSEC records + 2 RRSIG(NSEC) records in the negative answers. Even for the weakest RSA keys allowed, this results in an answer that is at least 635 bytes. NSEC3 signed answers require, in most cases, 3 NSEC3 and 3 RRSIG (NSEC3) records to deny the existence of the item asked for—that’s at least 1000 bytes. So we selected NSEC as our negative answer and use ECC keys. But the biggest saving comes from not having to prove that the covering wildcard exists at all, which is the role of the second NSEC record. We return an answer that says, “sure, the name exists, but the type you asked for does not”. This allows us to return only one NSEC record in negative answers!

In the past, NSEC records have been criticized for leaking information about the zone contents. Our implementation of negative answers allows us to provide negative answer with no value for a zone walker. Thus, our customers will gain the best possible defense against zone walking.The net result of our careful engineering of DNS answers is that we are able to keep most of our signed answers under 512 bytes. There are, however, exceptions, like when customers have large answers or long names but that is unavoidable.

Today's announcement regarding CloudFlare's alpha DNSSEC support is the first step towards providing a comprehensive DNSSEC offerings to our customers. We plan on offering DNSSEC to all our customers soon.

In that blog post, we said that we'd be expanding our network to betters serve customers in China and Latin America (as well as continuing other global expansions), and that we'd be making a big announcement around SSL.

CC BY-ND 2.0 image by Do Hyun-Kim

Looking back at 2014, we did a whole lot more and many of those changes had a meaningful impact well beyond CloudFlare. Now when we make a change, the needles on the Internet's dials move: when we roll out support for new protocols, sites tracking those protocols see a sudden jump in usage.

Here's a month by month review of CloudFlare's 2014:

January 8: keeping our promise to Latin America, we opened our first data center there in Chile.

January 27: we published our first transparency report covering National Security Orders on the first day it became legal to discuss them.

February 13: we published details of a massive DDoS attack (that peaked at almost 400Gbps).

February 14: we introduced a new Strict SSL mode to ensure that connections between CloudFlare and customer web servers could not be subject to a MITM attack.

February 17: we rolled out support for the most recent version of the SPDY protocol (SPDY/3.1).

April 3: we rolled out support for CNAME flattening that includes the zone root.

April 7: March 2014 had been very quiet, but it was the calm before the storm. On this day, the Heartbleed vulnerability became public. CloudFlare clients were protected, but that wasn't the end of the story.

Four days later, we set up the Heartbleed Challenge to determine if private keys were obtainable using Heartbleed. Nine hours after the start of our challange, we had the definitive bad news: yes, private keys could be obtained.

Because private keys could have been vulnerable, CloudFlare then revoked every SSL certificate that we'd issued and caused the CRL to grow massively in an unprecedented fashion. Later, we gave a detailed analysis of how the private keys could leak with Heartbleed.

May 3: we began publishing our SSL configuration so that others could use it.

May 7: faced with the fact that RC4 looked more and more vulnerable, we removed RC4 as a preferred cipher and saw an instant drop in the number of connections using it. We also followed up with an analysis of who still uses RC4

June 4: a big announcement for us and for anyone who wants to use CloudFlare for business: we're PCI Certified.

June 5: even more OpenSSL problems, and we patched them all to protect our systems and out customers' sites. The same day was World IPv6 Day when it became clear that 20% of the IPv6 is on CloudFlare (we also added special headers to ease the transition from IPv4 to IPv6)

June 12: we introduced Project Galileo which gives free CloudFlare service to sites likely to be attacked for exercising free expression rights.

June 13/16: two new CloudFlare data centers come online: first Madrid, Spain then Milan, Italy.

July 7/22: CloudFlare's new data center in São Paulo, Brazil comes online, followed two weeks later by Medellin, Colombia.

August 5: we rolled out support for WebSockets.

September 18: we rolled out Keyless SSL and went deep into the details.

September 24: the ShellShock bug hit. We patched our systems and rolled out firewall rules for all customers.

September 29: we made SSL free for everyone with the announcement of Universal SSL, fulfilling the promise we made at the start of the year.

October 14: we dropped support for SSLv3 entirely because of the POODLE vulnerability.

November 10: we outlined our plans to upgrade certificates that use SHA-1 to meet Google Chrome's expected behavior.

December 3/9: two more data centers, this time it was Lima, Peru followed by Johannesburg, South Africa.

Looking back over 2014, we added new data centers around the globe and added capacity everywhere, rolled out Keyless SSL, WebSockets support, Universal SSL, CNAME flattening, SPDY/3.1 and more, stayed on top of nasty Internet bugs like Heartbleed, Shellshock, POODLE, and more.

What will 2015 bring? Much more: new data centers all over the globe (including in China), new product lines that we haven't hinted at and some we have (e.g. DNSSEC support), and lots of surprises. This year, we plan on adding more equipment and network capacity than we have in CloudFlare's combined first five years.

Best wishes for 2015.

If your New Year's Resolution is to look for a change of employment (and you fancy working in London or San Francisco), check out our openings.

I'm the new Network Strategy guy at CloudFlare and my first day was Monday, March 10th, I arrived at the offices as instructed, not knowing what to expect. After all, this was a startup! My desk; my computer; my t-shirt; my miscellaneous office items were all laid-out ready for me to sit down. You can't ask for anything more. This is the type of welcome that simply makes you know you've arrived. I had arrived.

Right away, without skipping a beat, I was being walked around the offices and introduced to the San Francisco-based people at CloudFlare. The company has nearly 80 employees. It was a little daunting at first; but well worth every minute. I was delighted to meet all the people I was going to spend copious amounts of time interacting with. By the end of the hour I had met with accounting and administration, then sales, some smart marketing folks, the heads-down operations team, a cool support team and of course the network engineering group that I will work with some day. After all, I am a network guy!

I've spent a lot of years working on IP networking. I started writing network software in the 80s. Next, I spent some years building networks and datacenters. Other careers included global internet routing and internet peering. In the past 10+ years I've been a strong proponent of IPv6--more of this later.

What about that 5,000 number I mentioned? That was the other addition to CloudFlare on Monday. I walked in the door to that carefully laid-out desk and 5,000 customers signed up to have their web properties accelerated and protected by CloudFlare. Yes, 5,000! That's not a daily sign-up record, however it's nice to know that I'm not the only person that believes in CloudFlare! I think those 5,000 web properties and myself are all in very good company. I know I'll do my part to help protect those 5,000 customers plus all the other CloudFlare customers.

I'm an IPv6 guy. I fully believe in IPv6. I've lived and breathed it for many-many years. People that know me know that IPv6 have been my passion for a long time. Luckily CloudFlare also shares that passion.

The Internet is running out of addresses (think area codes and phone number in the telephone world). IPv6 fixes that issue. The IPv6 protocol was defined by the IETF back in the late 90's and has spent the last decade minimally deployed. It is sadly overlooked by many network operators. It took the in-your-face realization that IPv4 address space (the IP addressing scheme defined at the birth of the Internet) is extremely close to being fully allocated and that no more space is available before IPv6 started being taken seriously. Events like World IPv6 Day and World IPv6 Launch organized by Internet Society (ISOC) helped to finally drive home the message that IPv6 really worked and that it must be deployed if we want the Internet to continue to grow. For the last three years, CloudFlare has been running an IPv4/IPv6 gateway for its customers. What that means it any CloudFlare customer’s web property is available over both IPv4 and IPv6. It is already deployed, available, working and being used!

But that's not the full story because one of the configuration options that is build into the CloudFlare customer control panel is a switch that says "IPv6 off" or "IPv6 on." (the default is "IPv6 off").

Many customers have flipped the switch to enable IPv6. That's good; but it's time to make the default setting "IPv6 on." In this day and age this is a very safe thing to do. Over the next few weeks CloudFlare is going to make the default for new customer be "IPv6 on." No need to flip that switch to be enabled for the whole Internet (that's IPv4 and IPv6).

In the upcoming weeks CloudFlare will enable IPv6 for existing customers in a staggered release. CloudFlare takes the delivery of each and every bit very serious and you can be assured that every person at the company is involved in making this operation is successful. Yes there will be the option to turn off IPv6; but we strongly believe that at this point there's little need for that option to be exercised. By the time we finish this process, there will be more IPv6-enabled web presence than all CDNs, combined.

Finally, let's go back and talk about that first day. I hadn't completed all the new employee paperwork yet I left the offices feeling excited and happy and slightly drained. CloudFlare is not a sleepy-quiet-backwater-feet-up-on-the-desk company. It's a high-paced, innovative, going-places, dynamic place to work and it's filled with dedicated people ready to build the next best thing. I'm honored to have joined the company. It's going to be a wild ride! If you want to join me (along with those 5,000 other Monday signups) check out the careers page. We are hiring!