Cloudflare: Past, present, and future – An interview with John Graham-Cumming

In this comprehensive discussion, Ken Simpson, CEO of MailChannels, converses with John Graham-Cumming, CTO of Cloudflare, to explore the company’s past, present, and future. From discussing the company’s journey from its humble beginnings to its IPO, key challenges and milestones, the conversation evolves to reflect on significant events and strategic decisions such as competing directly with Amazon via the R2 Blob Storage engine. Graham-Cumming provides insights into the current state of the “Supercloud” and the integration of AI in their Workers platform. The discourse also ventures into Cloudflare’s approach to fostering innovation through their $2.0 billion venture capital fund, the Workers Launchpad, and their unique positioning against major competitors. Future-oriented, the conversation explores Cloudflare’s plans to tackle cybersecurity threats, the role of AI and Machine Learning, potential future features, and the company’s vision for shaping the future of the internet and digital security.

Listen here:

Watch here:

Read the transcript:

John: Email somehow is, is a technology that refuses to die. 

Ken: That is true. That is so true. You know, you’d 

John: think that somehow SMS or WhatsApp or other things, but the, the asynchronous nature of email and you know, the fact that everybody has an email address that can be reached, um, has made it that. It is a, it is a very valuable way to communicate and, um, it’s just not going away.

John: And the problem is threats come through. 

Ken: Today I’m excited to bring you my conversation with John Graham Cumming, Chief Technical Officer of Cloudflare. In today’s conversation. John and I retrace CloudFlare steps from its humble beginnings as a venture backed startup through its IPO and its decision to compete with hyperscalers like Google and Amazon Web Services by offering developer platforms and tools.

Ken: In our conversation, we talk about John’s idea of a super cloud, a one size fits all platform where developers can build applications that have infinite scale, uh, and don’t cost very much to run. We’ll end our conversation with a discussion of the forthcoming challenges of artificial intelligence and how Cloudflare envisions using its platform to help developers build the next generation of applications using AI tools.

Ken: And now, without further ado, here’s my conversation with John Graham Cumming of CloudFlare.

 Ken: Hi, John. So nice to have you on our podcast today. Thank you for joining me. And I wondered if we could get started by talking a little bit about. What cloudflare is, um, although, you know, people watching this podcast, most of them have probably heard of, of cloudflare, they might not know what cloudflare is today, uh, and what it means to the internet.

Ken: I wonder if you could start by just telling us what is cloudflare? 

John: Yeah, I mean, I think, uh, you’re right. That probably the viewers of your podcast, uh, are at least a little bit aware of what cloudflare is. Um, I say to people in general, the cloudflare is. Probably the biggest internet company you’ve never heard of.

John: Uh, and the reason I say that is that we handle, we think, about 20% of the web. So one in five websites, uh, uses our service. And what they’re doing is they’re using it for Uh, protection against hackers, DDoS attacks, things like that, and also acceleration of their website. So their web property is very, very fast.

John: Um, but we don’t just do that side of things. We also have a developer platform and we have a, uh, a whole world what’s called zero trust these days, which is how employees work on the internet and log into the, into the resources they need on the internet. And I think the important thing When you think about Cloudflare is to remember or learn, um, that we have a very large global network.

John: So we have our hardware in data centers in 300 cities worldwide, um, in 112 different countries. And the idea of CloudFlare is to be as close to the end user, so the people who use the Internet, as we can, because that allows us to fight against delays caused by the speed of light. Because as fast as the speed of light is, it turns out that it actually slows us down when we’re browsing the Internet.

John: It’s just not quite fast enough for what we’d like to do. And the only way to fight it is to be close to end users. So when you think about CloudFlare, we’re a global network, all over the world, close to wherever you are. And what we’re doing is making things connected to the Internet faster, more secure, more available, and more private.

John: And so that’s my little summary of who Cloudflare is.

Ken: Okay, great. Now, uh, that’s, that sounds really great. I mean, processing one in every five websites traffic is an amazing accomplishment, obviously. But how did Cloudflare get started? 

John: So, yes, it got started before I joined. So I joined the company when it was a year old.

John: It was basically a year after it was, uh, it was, uh, created and launched. Um, so I joined in 2011 and CloudFlare launched in September of 2010. And, um, you know, CloudFlare, um, the idea came about actually at Harvard where Matthew and Michelle. Uh, the CEO and the COO, um, got talking about obviously ideas and Matthew had been running a thing called Project Honeypot, uh, which was a way of tricking spammers into revealing themselves.

John: And, um, you know, many, many people were using Project Honeypot and what happened was, uh, you know, Matthew and Michelle’s. Talked about this and said, well, why don’t we do that? Why don’t we do security on the Internet? And so, so that was the genesis of, of Cloudflare. And the third founder of Cloudflare, Lee Holloway, um, had worked with Matthew in the past.

 John: And so you had these two folks who had, Matthew had worked before, Michelle had worked before, they got MBAs at Harvard, they connected with Lee, who was a technical. Uh, co founder and they built this initial service. The idea being that security was just too expensive for people and security needed to be, um, uh, something that was a service that could be done very, very cheaply.

Ken: So it really started out as a security play, uh, in the beginning, as opposed to a performance play, because now you’re, you’re saying, uh, in the intro that Cloudflare today, uh, Is really close to users, you know, within a small number of milliseconds of everyone’s browser or mobile phone. But in the beginning, it started as a security.

Ken: Uh, security tool. Well, yeah, I think that’s right.

John: I think security was really that, was really a very, very, you know, uh, it was a thing that was, it was, it was obvious that every website was going to need some amount of security because there were just more and more bad actors, be they DDoS or breaking into things.

John: And it was really reserved for, uh, you know, a small number of companies to have really good security. And so CloudFence said, well, look, you know, if you think about what happens in software in general is that things tend to get more widespread and cheaper. The same thing should happen in security. And so that’s how Cloudflare was founded.

John: But of course, the immediate problem if you do something, which is, remember, Cloudflare is an intermediary, right? If you use, let’s just talk about the web for the moment. If you go to a website that Cloudflare is providing security for, you come to Cloudflare first, and then we have to go to the real website and get what you’re looking for, the webpage.

John: And so it immediately became obvious that we also needed to do performance. And we needed to do what’s called CDN. or caching because otherwise there would be this big performance hit just to go through our service and no one was going to be willing to pay the performance hit. So right at the beginning, it became obvious that actually performance and security needs to go hand in hand.

John: And so that’s how the initial products were around caching around, uh, you know, DDoS  mitigation, WAF, protecting, protecting websites, not now to do much more than just websites, um, and making them faster. 

Ken: And I remember from the early days of CloudFlare, um, I’m being skeptical. Personally, because cloudflare cloudflare required you to change your DNS.

 Ken: You had to hand over your DNS in order for cloudflare to remap your, uh, a records onto these NGINX instances up in the cloud. And I remember thinking, nobody’s ever going to relinquish control of their DNS. This is a really bad idea. 

John: I, I had exactly the same impression when Matthew, right when Cloudflare got going, Matthew tried to hire me and asked me if I would move back from Europe because I’d been in America for a long time.

John: I was back in Europe. If I would, if I would consider moving back from Europe, going to the U. S. Again, I’m working for Cloudflare and this was a point at which it was, you know, five or six people, um, above a very, very smelly nail salon in Palo Alto. Um, and I remember thinking, well, I didn’t particularly want to move back to the U.S.

 John: I’d kind of, I’d lived there for 11 years and decided to come back to, to Europe. But also, I mean, who’s going to hand over their DNS and more importantly, not just DNS, but who’s going to hand over their traffic, right? You know, the whole traffic of your website is going to do well. Um, funny thing is that it quite quickly became obvious that a lot of people were, and actually to tell you a funny story about this, the init, the initial way in which CloudFlare worked was right at the beginning.

John: We didn’t have a way of, um, setting up the DNS in our system. Um, what we did was we asked our initial customers to give us the password for their domain registration, and we log in as them and change their DNS for them. 

Ken: Oh, there can’t be any problems with that approach. 

John: And the thing is actually what’s, what, you know, is, is wild is that lots of people did that.

John: I’m sure. Yeah. The enthusiasm was incredible. Yeah. And so it quite quickly became obvious that people were crying out for this security slash performance service for the things that we’re putting on the web. 

Ken: I guess, uh, you can never underestimate people’s willingness to forego security in favor of convenience.

John: Well, I wasn’t, I certainly wasn’t going to give Cloudflare the password to my, you know, to my original, I’ve owned that domain since I think 1997 and no one’s going to touch the domain.

Ken: alone a startup above a nail salon in Colorado.

John: Yeah, exactly. Who knows what they’re going to do. 

Ken: Unreal. Um, and yet, you know, and yet Cloudflare made steady progress.

Ken: You know, what were the next steps after you joined? How did, how did CloudFlare move from a nail salon, uh, to a swank office in San Francisco and then eventually an IPO? It wasn’t 

John: a very swank office, the second one. We did move to San Francisco from Palo Alto because I was in London and I was on my own for a long time.

John: And then, uh, I actually hired. A second person who’s still with [00:10:00] the company. Um, and we started building out the London office. I mean, part of the thing was, was that in the beginning you’re just growing and responding to the growth in the market. You have some idea where you’re going, but quite a lot of your problems are in fact technical.

John: And so a lot of stuff I did right at the beginning was. Which I was a year in, was things didn’t work great. And so lots of stuff had to be re architected or re written. Um, and so there was a very big effort, I think about a year or two in, where so the first thing I worked on was, or one of the first things I worked on was our web application firewall.

John: Um, it was really janky. It used a combination of Nginx, Apache, and ModSecurity. Um, there were all sorts of restrictions. It fell over all the time. There were all sorts of problems at the beginning. And, um, the week I joined, Matthew gave me a list of things like, go work on these things. Huh. And, um, one of them was, was write a new WAF.

John: So I, I went around and I looked at all the WAF stuff that was out there and open source projects and stuff like that. And. I just said, I think I’m just going to write a WAF from scratch. I could go wrong. Well, yeah. Um, I mean, I think the hard thing was getting it to be performant, not getting it, not writing it in the first place, because we, because we care about performance and security at the same time.

John: I spent a lot of time after I got the functionality working, um, uh, making it, uh, making it perform with a really low latency. Right. Um, but in some ways it was, it was a fun project because We were already using ModSecurity and ModSecurity has quite a large test suite. And so what I actually did was I actually adapted the ModSecurity test suite so that I could test my new WAF.

John: So I kind of knew it was working because I had someone else’s test suite. So that was actually super interesting in the beginning. So I think in the beginning, there was a lot of things like that. I mean, our, our original But core processing of requests, like when you went to a website, they use cloudflare.

John: One of the things we have to do is we have to do what’s called ownership. We have to figure out whose website this is in our system. And what, what is the setup for it? Like what features do they use and what are they, how have they configured it? Um, you think that has to be done every single request.

John: Right. Right. And that thing, um, was written in PHP and it was like, it did work, but then we did this. Port a guide a guy on his own did this port of that php Into lure because we’re using engine we were using engineers lure at the time and The thing about all these things we’re talking about here is these are running systems So, you know you so you we I think one thing that cloudflare got really good at and we’ve done this over and over again is You know, replace the wings on the aircraft while in flight, which is to say, you know, How do you take some piece of technology and write a new one?

John: I mean we’ve written We’ve we’ve rewritten things. Uh, well, we rewrote our dns infrastructure completely More than once, actually. Um, so I think one of our sort of secret sources is a willingness to rewrite things and figuring out how to do it without breaking this live system. 

Ken: Right, so not being too opinionated about having the correct architecture as you grow, but being willing to throw it out and start again when it’s needed.

Ken: You’ve done that a few times. Well, I think part of it is you.

 John: if you’re in a company that’s growing very, very rapidly It’s hard to know what the correct architecture is right from the beginning. Because one of the things that happens is if you, you have some weird choices, right? You can kind of write stuff that gets something running and get it out there and get feedback from the market and iterate.

John: Um, you’ll, you’ll inevitably get the wrong architecture of some parts of it. I mean, I remember, um, there was a customer. I think they still have a customer at WP Engine, which is a big WordPress. Hosting website. And we had architected our DNS to work really well for millions of domains and for each domain having a small number of subdomains, right?

John: And WP Engine, so that you imagine it was horizontally scaled really, really well. And W, if you like, and WP Engine has a separate subdomain for every customer. So they were a single domain with potentially millions of subdomains, right? And everything fell over. Because it just, you know, because it’s because you hadn’t anticipated that and the problem is you sort of look backwards and go, right.

John: Okay. Couldn’t we have anticipated that in the beginning? And it’s like, yeah, we probably could have anticipated that beginning. In fact, you could have anticipated all sorts of interesting scaling problems, but. Some of them you wouldn’t have anticipated, so you would have always been surprised. And second of all, you would have spent so long architecting for things you, problems you didn’t have yet that you wouldn’t necessarily have got the feedback from the market.

John: And, you know, there’s only very few things that I think, boy, I wish we’d really done X at the beginning because over time we were able to respond to the changing market and the changing customer base and rewrite stuff. And I think that has worked out pretty well for us. Yeah. I mean, 

Ken: it seems like you pretty early on built an airplane that has removable wings.

Ken: Uh, you know, well, 

John: I think the PHP, we, we kind of sold that off, right?

Ken: But after, after PHP, you know, you, you created an approach to technology that enabled you to, to replace things as needed and fix things as needed as you scaled. Whereas maybe some other companies would have been sort of rigidly tied to an architecture that didn’t work out.

Ken: Um, and it would have been more painful for them to change as they scaled. Uh, maybe there’s some selection bias there, survivorship bias there, uh, where those companies are no longer with us.

John: The important thing is less, is less the architecture and more the, um, when you think about the culture within the company, like, are you willing to rewrite stuff?

John: Are you willing to change languages? Is that okay? And actually, I think when we rewrote, um, I think it was when we rewrote our DNS server, there was some questioning in the company about, you know, why hadn’t we got it right the first time? Uh, and I actually wrote an email to the whole company about this, and I believe it was published as a blog post in like 2013 or something, um, about the sort of culture of rewriting and why it’s so important to do that.

John: And, and, and I think that that has been something that has benefited us a lot to be able to do that. Um, but it would be great to be able to anticipate all of the scaling and problems you’re going to have up front and not have to rewrite things. I wish that was, that was possible. And just, I think there’s some law of physics that says that’s not possible.

John: Yeah, definitely.

 Ken: So, so how, uh, obviously, you know, Cloudflare started out doing. Web proxying, uh, primarily for security, but then performance became this requirement that you just had to satisfy. And then over time, you’ve, uh, you mentioned that you’ve added additional things on to the platform, and now there’s this whole developer environment.

Ken: Uh, you know, how, what was the sort of thought process? How did you come to add these additional capabilities onto the platform? How did you discover that you should do those things? 

John: Well, it’s funny because I think… We could probably go back to like 2012 or 2013 and we, we, we talked a lot about what’s next and the, um, there are lists of ideas and I think we, we haven’t satisfied all those ideas that were in that list.

John: I mean, there were things like, you know, should we build a search engine? Um, and I think that we, um, there were some things where they were both ideas that we had and then, uh, the sort of the market or our customers. Pushed us in that direction. I mean a very good example of this is is the developer platform, which you mentioned So if you go back cloudflow, it’s very configurable through the api through the ui but um, it’s an absolute truth of of programming that um, no configuration Language or setup is as flexible as a programming language.

John: So inevitably There’s something that a customer wants to do that can’t be done in the ui or in the api And so very early on, our customers pushed us to create, um, you know, some programming mechanism and the way this used to work was called edge side code was our customer. Tell us what we wanted and we would write it and our deployment mechanism meant that it had to be, uh, in our main code.

John: And so if a customer wanted a custom piece of work done. Um, then we had to do a release of our software, which was pretty wild. It was very slow to develop. Uh, it was very difficult. Like a customer would update something, we’d have to like, change, [00:19:00] you know, run our test suite and deploy our software. And so very early on, the idea that people wanted configuration through, uh, you know, modify the configuration through software.

John: Was important. And then we just began to see more and more opportunity to run code on our large network close to the end user where, um, you know, I like it like this. If you think about our network, and if you think about the end user device, whereas a laptop or a phone, if you put code on that device, um, it’s not secure.

John: So you can’t put anything secret in it. It’s relatively slow to update. Because you have to wait for the user to update. Um, but it’s very low latency to the user, right? It’s right in front of their face. So whatever they do, they interact with. If you put stuff in a cloud provider somewhere, um, you have the, you have the opposite attributes.

John: It’s very fast to update. It’s your code. You can update it, right? It’s highly secure. You can have secrets in there. But it’s long latency to the user. [00:20:00] And what Cloudflare did by building out the network was we said, actually, I think you can have a bit of both of those worlds. So we are close to the end user.

John: Think about those 300 data centers. So the latency is very good. But you can update it whenever you want. And it’s secret. You can put secrets in there. And so you have this interesting place to put code. And I think that gives you slightly different attributes about what you’re building. And people are liking this.

John: The other thing is, it scales. You can scale up instantaneously. And so I think that Um, a combination of like the sort of customer pressure to provide this, this really code based customizability and our own vision that, you know what, actually there’s, we could run code in our network. Um, you know, we saw this, this, this kind of serverless world and decided to, to build out.

John: I mean, workers is now, I mean, it’s not new. It’s six years old at this point. Um, you know, workers has been around for a while and it’s a pretty rich platform.

Ken: Yeah, I think, uh, I read somewhere that there are. Uh, four million workers, like four million actual worker apps, uh, that are, that are in existence.

 Ken: Um, that’s quite a large number.

 John: You, you might know better than me what the actual number is. It means a very large number of developers. Yeah. And, and, and, you know, and it is a very, um, you know, a very large percentage of our customers write code on our platform from small things to very large things.

John: Right, right. Yeah, that, that’s something that’s taken off enormously. 

Ken: And so now you’re, you know, moving into the present time, you sort of call this, uh, environment that wraps up security, uh, with performance and edge code execution, you call it the super cloud. Uh, so how, uh, you know, setting aside the jargon, um, how does the, uh, CloudFlare approach to development really change the game for developers?

 Ken: Like, what should developers know about CloudFlare when they’re thinking about where to build their next app? 

John: Well, so one way to think about this is I, I grew up with the 8 bit era of computers. And the nice thing about the 8 bit era was you wrote some code and you ran it on your computer and it worked and you had it in front of you, or it didn’t work and you had it in front of you.

John: But you were inherently dealing with this one machine. And that was very satisfying as a developer because, you know, all a developer wants to do is write code and be productive. And see the results, right? And obviously, at the time, you then, if you wrote something, you need to sell it to somebody else. You had to send them a cassette tape or something with it on, but that’s a different era.

John: I don’t think developers fundamental, um, you know, desires have changed. And I think that what developers don’t want to spend time thinking about is scaling. Or the security of the application, or is it close to my end user? Where is this thing running? I mean, the idea that, you know, a developer wanting to build something suddenly sits there and says, what availability zone should I put this in?

John: I mean, how do you, how do you answer that question? You have to kind of guess or like, well, I’ll put it in, you know,  us east or something. Um, especially when your ambition is at an internet level that your application might be popular everywhere. And your application might have incredible spikes because suddenly becomes, you know, it’s on the front page of hacker news or something.

John: And so I think my vision, at least, is that it’s, you know, for those of you older enough to remember, it’s to go back to that 8 bit era of like, I wrote some code, but instead of me putting it on this machine in front of you, I put it on the internet and I don’t worry about. The sort of paraphernalia around it that makes it scale and things like that.

John: And the other thing is, I think we’ve made a pretty heavy bet on WebAssembly as being kind of the runtime, um, that is going to, you know, application is going to be written or compiled towards WebAssembly. So obviously, JavaScript is very important. TypeScript is very important, but other languages too. Um, so I think it’s, it’s worth thinking about how Cloudflare can…Can help you if you’re building an application, especially because if you’re running on our network, you then got the WAF DDoS protection, you’ve got caching and you’re all of this stuff becomes part of the offer rather than it being, you know, something which you then have to worry about and add on later 

Ken: And you and you’ve been adding, uh, Other capabilities to the workers platform.

Ken: So it’s not just running code. Now, there’s a pretty capable SQL database. There’s a storage platform with very disruptive pricing. Uh, and, uh, there’s a queuing system now. Um, you know, it sounds like you’re taking on Amazon with, uh, with those capabilities. 

John: I mean, yes, yes. And no, I, the way I think about it is Cloudflare is fundamentally, I mean, obviously you think of it as a security company.

John: We, I think we think of ourselves as a security company, but also as a networking company. And if you think about the cloud providers, like Amazon and Microsoft and Google, they really came at it from it’s smart. Servers and storage, right? That was their real core offering. I can, I can upload this. I can get a virtual machine.

John: I can, you know, do all these kinds of things. And Cloudflare came from this as the network is to quote Sun, the computer, the network is where everything is connected. The network is where everything happens. And so we view ourselves very, very differently than those the hyperscalers because we think the network is fundamental.

John: It’s what, you know, you connect stuff to the network and you get results. It’s really the case that the network is becoming is the part that had not been disrupted by the cloud, right? You’re still buying all this network hardware. You’re still doing all this old stuff. And actually, what we think is the real answer is you connect into a network like Cloudflare and then.

John: You know, whether you’re connecting directly as you know, a customer using a web browser or using warp, which is our VPN client, you know, connecting to the network. And from there, in a software way, you can design what the network looks like and what the things are operating on the network, firewalls and code that’s running and zero trust access and all this kind of stuff.

John: So, in some way, we do compete with, with Amazon. And if you look at, say, like Amazon, over time, they added WAF functionality because their customers were needing it. Whereas we, I think we really feel that we’re best in breeding. And, uh, things like WAFs, DDoS, whereas the other clouds are kind of, they’ve been forced to add that to protect their own, their own customers.

John: So we don’t really feel like we’re competing. You know, we’re not trying to be an Amazon competitor. Let’s put it that way. But inevitably there’s overlap. And it’s particularly overlap. You mentioned it. The storage product are two. Um, so R2 is a, is a, is a direct competitor for S3, Amazon’s product. And, um, the reason we decided to do that, we, because we have a view of the traffic flowing through our network, we saw that a lot of customers were serving.

John: Act, uh, content, uh, from Amazon SS three through CloudFlare. Mm-hmm. And what they were doing is they were using CloudFlare as a cash in front of S three. And the reason they were doing that was the SS three egress was so expensive. Hmm. That we saved a lot of money and we just looked at it and said, it’s insane that Amazon [00:27:00] and others are charging when you take your data out.

 John: I mean, when I think about the pricing, uh, of, of R two.

 Ken: Uh, your storage product, the fact there’s no egress fees, I think you’re, you’re driving a very sharp wedge, uh, into Amazon and others who charge high egress fees because to me, I mean, and, and our Amazon bill is disturbingly large, uh, every month for our service, a large fraction of the bill is bandwidth.

 Ken: It’s ridiculously higher than if we had bought bandwidth on the open market. And so therefore it must be a key component of their profit. So it’s not like Amazon can turn around and say, well, okay, Cloudflare came along with R2. We’re just going to drop our egress fees as well from S3 because that would disappear a ton of profit.

 John: Well, I mean, we wish they would, because I think that it’s egregious that Amazon and others charge this crazy amount for egress. Um, and it’s, and it is a mechanism of lock in, right? It’s like, you know, the Hotel California, you can check out, but you can never leave, right? You’re locked into the platform.

John: So I think that, um, that is a significant, uh, place where we decided to compete with Amazon. And I think it’s really paid off and I’ll tell you one area has really paid off is AI. Um, the data involved with AI is large and for training or for inference the models themselves are very large and those models have to be moved around.

John: Um, and the reason that’s moved around is because GPU resources are scarce, um, you want to do training in different locations, you know, depending on the provider you have. So you’ve got, you fundamentally need to get your large amounts of data, be it for training or the model or checkpoints in the model, out of storage.

John: And It’s just nuts if you’re, you know, you’re paying a fortune to move your own data around. Uh, and so we’ve seen a lot of uptake in R2 from AI companies.

Ken: Very interesting. Yeah. I, I’d like to get into a discussion of AI, um, later in our conversation, because I mean, this surely has to be making waves, uh, in, in the, in your platform.

Ken: Um, I mean, one thing we’ve noticed in the last few months at Amazon, the cost of spot instances has skyrocketed. It hasn’t been discussed much, uh, publicly, but there are a few people who have noticed this trend, um, and my hypothesis, completely unproven, um, is that there’s just generally a larger workload going into these cloud hyperscalers, uh, and that is increasing the marginal cost of their services, which is reflected in spot pricing, uh, you know, you guys must be getting some refugees from the Amazon world just because of that.

 Ken: I would imagine. Yeah, yeah.

John: We definitely are. It’s absolutely the case that we get, you know, people are wanting to re-architect away from, from, from the cloud because of those, you know, the expense of some of these things. And I think that, you know, longer [00:30:00] term we think that the CloudFlare workers style will, will win out, um, over, over having, you know, Large virtual machines or even containers.

John: Um, but and as with everything Cloudflare does, we’re in it for the long term. So it’s not a let’s fight Amazon or Microsoft or Google today on the container business. Because I mean, ultimately we think that will, um, that that business will become commoditized. And, um, we think that, you know, the scalability of our platform, plus the security, plus the caching is really quite compelling if someone’s building an application.

Ken: Yeah, I mean, this, uh, this segues nicely into the, the workers launchpad fund, which I’m told is now at about 2 billion. That’s right. So, uh, when I think about workers, you’re, you’re obviously introducing a really disruptive model for developers. Uh, that’s a pretty heavy lift in educating people about this new approach that is, is probably better, but [00:31:00] it’s different from what people are used to.

Ken: So, uh, can you talk about how the launchpad is. It’s going to, uh, help build the workers developer, developer community. 

John: Yeah, I mean, the idea of the launchpad is that we’re seeing people bet on on cloudflow workers as a as a platform. Um, and some of the people are betting on it are, you know, startups or brand new companies.

John: And I think that the, um, you know, the ability to have funding that’s tied to the platform is just a, is another, um, Way to attract people to the platform. Um, and I think it’s also an endorsement of, you know, this is a real, this is, you know, not some toy you can build your entire business on. And what we’re hoping is that someone builds the next, I don’t know, Snapchat or, you know, other application on our platform.

 John: And because we can scale up, we’ll scale up with them. So I think providing funding is an important part of just in sort of the entire package. And I think it’s, you know, the very large dollar number there is an indication of how excited the investment community is about the opportunity of building on something like Cloudflare, in part because of the ability to scale out very quickly.

 John: So if somebody has a hit, they’re going to have, you know, very, very fast scaling.

 Ken: Right. So it’s sort of like from the beginning, these companies are using a development architecture that naturally scales to without limit effectively. So accommodating any level of growth that might happen, which, of course, is a venture capital fund stream.

 John: Yeah, and it’s not just, you know, I mean, obviously that the developer fund applies to those small companies, but it’s what we’re seeing is, um, quite large firms. I was actually talking to a very large, uh, transport firm this morning, and they, they had done a shift from on premise hardware. Into Amazon. So they wanted to get off of having their own data centers into Amazon.

John: And then they, what they said was, we are all in on using serverless and Cloudflare workers. So we’re going to go into Amazon was a temporary step that we’re going to get on to get our stuff off of hardware, get our applications running in a Kubernetes type thing in Amazon. And then we’re going to rearchitect for serverless.

 John: And the reason they wanted to rearchitect was better scalability. And also they felt that from a development perspective, developers were going to be happier writing in a serverless environment than writing for this monolithic container based Kubernetes environment, which I thought was fascinating because that’s sort of been my 8 bit computer theory.

John: It’s like, developers are going to have more fun doing it this way. And they had made a strategic decision that’s what they were going to do. So I suspect that, um, we’re going to see this serverless thing grow more. It’s not just going to be for Perhaps the most innovative small companies, actually other companies are going to see the value in moving away from these large, uh, monolithic or, you know, complicated.

John: I mean, even Kubernetes is very complicated to manage to something which I think is going to be much more, much easier to manage and much more scalable.

Ken: Yeah. Very familiar with Kubernetes and orchestrating within a hyperscaler. I mean, it’s It takes multiple people, uh, their full time job just to keep that maintained.

Ken: And, you know, one of the major aspects, when I think about it, one of the main things that we work on is upgrading Kubernetes. It’s a constant task in our OKRs. Upgrade Kubernetes to the next edition, you know, then you have to build a new cluster. You have to test it. You have to launch it. It’s constantly happening.

 Ken: The idea of having a cloud environment where you just write code and it just runs, someone else is taking care of all the details is extremely attractive. And I only wish that you guys have been around. Uh, 10 or 12 years ago with this technology. 

John: Yeah, and one of the things we built in, uh, in Cloudflare Workers is you can actually obviously as we upgrade, we, we change our runtime and obviously we, we care a lot about backwards compatibility, and we actually have this configuration where you can state your compatibility date.

John: Like, like I’m working with the APIs of this date, um, so that that can either what we can do with that is either we can say, okay, great, your, your thing will still run, or we can tell you actually there’s something we’ve changed as you’re going to have to update something, right? So you can actually see the, we actually published the change history with the compatibility dates.

John: So you can see what was available, what changed and all that kind of stuff. And that’s an important part of running a platform like ours. 

Ken: That’s a brilliant idea. That’s a brilliant idea. So like building in the notion of obsolescence, right? And making it very clear to people. Um, yeah, you’re going to have to make changes.

Ken: Sometimes it’s, it’s, uh, unavoidable.

John: And we’re going to add new things, right? So maybe that you’re like, uh, um, you know, I need this particular API. So my compatibility date is here, right? So it has to run from here on out. 

 Ken:  Um, so looking ahead, uh, you know, to the next five or 10 years, I know a lot is obviously changing as a result of the rise of generative AI.

Ken: So it might be more difficult to predict the future than it has been in the past. However, Uh, from your crystal ball, what, how do you see this, this, uh, cloud flare, super cloud evolving in the next five to 10 years? 

John: Well, it’s worth saying what I mean by super cloud. So remember, I said there’s these 300 cities and 100 and I think it’s 112 countries where we have data data centers, and it’s all bound together into into a network, some of it using the Internet, some of it using our private fiber, um, and we allow you to run code on that and fundamentally, we want you to run code.

John: In the right place, and what is in the right place meet? Well, one answer to in the right place is something called edge computing, right? Which you hear about. And at the idea of edge computing is to say that the right answer to my question about where the code should run is close to the end user. And that’s an okay answer.

John: That means it’s going to be low latency to the end user. And if you’re optimizing for that latency, Right? Might make a lot of sense, but we know from monitoring of our own of applications running in our network that, you know, most of those bits of code. Don’t just talk to the end user. They also talk to other things that they may be calling.

 John: They’re going to a database, maybe calling other APIs on the Internet. Um, so actually the optimal placement of a piece of code. Might not be the edge next to the end user. It might be somewhere else. It might actually turn out to be quicker to have the code run with a long latency from the end user because it has to make multiple back end calls to things and you move it close.

John: So what you want to do is move code around the optimal place and. Because you have multiple versions of the code, right? Because that’s what we do. You might be like, Oh, I’m sitting here in Lisbon and maybe the application I’m using, uses some database, which is in the U. S. It might actually make more sense for me to be accessing a version of the code.

John: Running in the U. S. Um, but someone in London that might not be true, so we could have multiple versions of the same. Yeah, there’s multiple copies of the same code running. So that’s that is no longer edge. That’s about the whole network working for the cooperative manner to figure out where stuff should be.

 John: And then the other side of it is. There might be regulatory reasons why the code needs to run at a certain location. So it might be despite that performance thing, um, it needs to run in the EU because I’m in the EU and I’m EU user. In which case our system might say, okay, great. We’ll run it in the EU. I still won’t run it in Lisbon.

John: I’m going to run it in Frankfurt because the connectivity from Frankfurt to those back end systems is better. So the super cloud is about really taking that. Scaling and performance that we’ve always talked about and making it, um, invisible to the end user, right? And invisible to the customer is like, well, we move, we, you know, we move stuff around automatically for the best performance to, to deal with the architecture you wanted.

John: Um, and I think that is much more powerful concept than the edge as a location. I think the edge is, is, is in some ways quite restrictive, funnily enough. 

 Ken: So it’s more about. Kind of cope mobility as opposed to the, you know, being right at the edge all the time. 

John: Yeah. I mean, maybe right to the edge. I will measure it.

John: Maybe it turns out that being. You know, your, your, your, um, app makes one API call, which is well connected to the internet. And so the optimal placement is the edge, but it might be, no, the optimal placement might be that, you know, I’m here in Lisbon and maybe it’s better for my request to get routed to Paris because.

 John: There’s some connectivity out of Paris, which means that the back end API calls are faster from there, and the overall latency is now optimized.

Ken: I’m trying to imagine someone trying to orchestrate this inside of AWS using VPCs and stuff, and it’s just making my brain hurt.

 John: Yeah, we don’t want anyone to have to think about it, really.

 John: We just want people to tell us, do you want us to do this? And, um, you know. Uh, are there regional restrictions or things like that that you want us to implement? 

 Ken: Yeah, we definitely see that in the email world, like people, um, have, you know, obviously significant privacy concerns when it comes to email data.

 Ken: Um, and so we, we often get requests for processing email traffic only in a particular region. Uh, and, uh, it is honestly, it’s challenging. It’s challenging to do that in a hyperscaler because It means we have to set up in an entire region and we have quite a bit of boiler plate infrastructure, despite the, you know, auto scaling and whatnot, there’s, there’s still a certain amount that has to be there and that represents a fixed cost.

Ken: So it’s not like we can just snap our fingers and go anywhere where the customer wants us to be. I could see that as a major advantage of Cloudflare’s 

John: approach. I think, I think it will be going forward because of these privacy laws are really growing all over the world. Um, and I think one of the advantages of having such  a, having such a large network is that it’s very granular.

John: And so, you know, if you need to slice it up in a certain way, then you can, right? You, maybe it’s EU, right? Or maybe it’s Canada and the United States. Maybe that’s the that’s what you want, right? It’s where your data needs to be or your code needs to run. Um, or maybe, you know, there’s other restrictions and maybe like it’s, let’s suppose it’s health care data and maybe it’s like, well, actually, I need to just be United States, right?

 John: Or, you know, so I can’t include Canada or in Europe. It’s like, well, actually, it’s a German health care and Germans. Germany’s healthcare laws mean you can only be in German data centers, right? So you can divide up this very granular thing in the way in which you want. And because we can move encrypted data from anywhere on our network to anywhere else without decrypting it, if we need to, you can still get the advantage of the big network.

John: So, you know, imagine you’re a German healthcare provider. You’ve decided. You know, decryption and data storage can only happen in Germany, right? And then, you know, you’re a German, you’re a German consumer and you fly to South America on the holiday. In the middle of your holiday, you think, I need to change my doctor’s appointment and you log into the app, right?

 John: Which is on Cloudflare. You connect to, let’s suppose you’re in Argentina, you connect to our data center in Buenos Aires and we say this is an EU only, actually Germany only. And then we can forward the entire encrypted connection. To Germany, right? And it’ll never be decrypted outside of outside of Germany, Germany, right?

John: And all the way across. And then, um, you know, but at the same time, they’ve been, they benefit from the DDoS protection and all the things that are happening in Buenos Aires. So this super cloud concept really is about flexibility of a very large, but very granular network. 

Ken: Wow. It’s kind of surprising that it.

Ken: That not more people are using it. I mean, if it’s, it really sounds great, but I guess there’s a lot of, uh, there’s a lot of industry momentum on the hyperscaler platforms. Uh, you know, and I suppose perhaps 1 reason why you have the fund is because you really want the next generation. Uh, to be considering using Cloudflare’s platform instead, I know that a colleague of mine, uh, works at AWS, uh, and his job is interfacing with venture capital funds.

 Ken: And I know that AWS has put a lot of effort into. So making sure that every startup that is funded uses AWS, I’m sure Microsoft and Google have the same kinds of efforts, but your 2 billion fund is massive. I mean, it is a big gun. It is. Yeah, it is. 

John: Hmm. Yes. I mean, that was sort of part of the point was to really, you know, was to say, look, this is not, you know, it’s not a few million dollars and say that, and look at the list of VCs who are backing this.

John: Um, because we really think this will be the way in which applications get built going forward because just all of the advantage of being on that platform where you don’t have to worry about all this stuff.

Ken: A technical question about the fund. Does Cloudflare co invest with the venture capital firms or is it more of an introductory service and Cloudflare’s providing credits?

Ken: How does that actually work for? It’s more of an introductory 

John: thing, right? So these, these VCs have come together to pull this, you know, this money is there and it’s more of an introductory thing. But, um. To this day, Cloudflare hasn’t, hasn’t co invested. Not to say we wouldn’t at some point, which hasn’t been, uh, something we’ve decided to do, but, um, you know, obviously we are able to provide our, our, you know, members, you know, credits for our platform, access to, uh, new features, et cetera.

John: Right, right.

 Ken: Got it. Um, so, uh, AI, right? Uh, GPT, uh, massive growth in open source, uh, language models and other, and other forms of models. Everything is moving so rapidly. Cloudflare announced a new capability around AI model management. Can you discuss what that is? 

John: So there’s a whole load of AI stuff going on at Cloudflare.

 John: I mean, it’s funny because I’ve been, um, you and I first met a long time ago because I had written a spam filter that used machine learning. And that was over 20 years ago. And so it’s funny to see some of these machine learning things, you know, um, appear again. Um, the reality is they never went away.

John: What happened was there was just gradually more and more machine learning and more and more work going into AI. And as we got more powerful machines and more data, we got better and better results. So Cloudflare’s been doing… Uh, actually stuff with AI type, like the LLM type stuff, um, and also the machine learning stuff for a long time, we use it for security reasons, and you think we do about 46 million HTTP requests per second, um, and so figuring out, is that a human user?

John: Is this a threat? You know, we can’t do that with anything other than machine learning, um, and so that’s been a very important part of our platform, but within the developer platform, I think what’s clear from the excitement around LLMs is that, uh, machine learning functionality will become something that every app, um, is expected to have as part of it.

John: Whether it’s visible or not. And I always give people the example of if you, your phone, if you have a fairly recent phone, probably has the ability to search your photos by you typing something in. So you might, you know, I know that if I go to my phone and I type in car. It’ll show me pictures of cars that I’ve taken photos of.

 John: And that’s a wonderful sort of embedded machine learning or AI piece of functionality. You know, you don’t really think about it, but just this magic happens. So we think that that’s going to happen for lots of applications. And so we launched this thing called Constellation, and Constellation is A way for you to run AI models on our platform in Cloudflare Workers so you can add this functionality so you can go to Hugging Face and get some model you want and we will run it for you.

 John: And we’re investing very heavily in two areas. First of all, in, um. You know, the ability to run models on our CPUs, because there’s a lot of stuff that’s very interesting around CPU execution and models. Um, and also there’s a whole bunch of experimentation going on with, uh, with GPUs within our network.

 John: So, the idea is that AI and machine learning become first class citizens on Cloudflare workers, in the same way that we have database functionality or queues or email and all those sorts of things. We think it’ll just be part of every application going forward. 

 Ken: Hmm. Is there any like hosting GPUs in a data center?

 Ken: It seems to me like that might be a slightly different experience than hosting CPUs that are optimized for network activities. I mean, the, you know, GPUs, they devour energy. They generate tons of heat. Um, has that stretched your infrastructure team, uh, working on bringing in tons of GPUs to power these applications?

John: Well, we haven’t done it yet. So we haven’t rolled out GPUs over the whole world as 300 data centers. And so there’s some really interesting trade offs around, um, where do you put, uh, you know, that kind of, whatever sort of matrix process I think you’re using, whether it’s a GPU or something else. Uh, where do you put them?

 John: What can you do in CPU and not do it on a GPU? Um, because there’s a lot you can do on CPUs. So we’re working through that now. I mean, constellation is available and people can use it. Um, but you’re going to see us grow our AI footprint, uh, over time. Um, to, to make that work, you’re absolutely right. The GPUs are very power hungry.

 John: Cooling hungry as well. Um, and so it’ll be interesting trade off, but we’ve actually done this before because when we built R2, um, R2 is a different kind of thing than the rest of CloudFlare because R2 is all about storage. So figuring out where do your storage nodes go? What does the storage node look like?

 John: Um, that was the first time that CloudFlare really built something that was different from our. Standard server, which we use for handling all of our traffic. So we’re, you know, we’re ready to do this for, um, you know, GPUs. And actually, one of the interesting ideas is maybe the GPUs actually need to be co located with R2.

 John: Because if the models and the training data are in R2 and maybe you’re just like, well, look, that’s right. They’re right next to it. So we’ll run it like that. So it’s going to be an interesting thing. But when you think about the super cloud thing, let’s imagine that Cloudflare doesn’t have GPUs in all 300 data centers, then.

John: This placement thing becomes really interesting. It’s like, oh, wait a minute. We’re going to run this app near the GPUs, which are, you know, let’s suppose we didn’t have them in Lisbon. We did have them in Madrid. So John’s app will run in Madrid because it’s close to the GPU and the model. And so we’ll be able to make really smart decisions about where stuff executes because it’s because it is a fundamental part of our platform.

 Ken: Privacy is also a major issue when it comes to machine learning, obviously, because you’ve got customer data that you’re exposing to train the models. And then you’re also exposing it to evaluate against the models. Um, Apple, Apple is seen as a real leader in this area by putting the machine learning capabilities onto the device.

Ken: Uh, and they really make a lot of effort to tell everyone about it, that they never, uh, you know, never send your photos into the cloud for machine learning recognition. For example, it’s all done on device. 

John: Absolutely. And I think, you know, again, we were talking a little bit before about, you know, my examples of the German healthcare thing.

 John: The same thing is going to apply with AI, which is like, okay, where is this? Where is this data allowed to reside? And so we will be, uh, you know, we’ll be able to slice the network in the same way. 

 Ken: Wow. Well, one thing that’s been on my mind, uh, for the last four months, uh, really since the launch of GPT four, um, has [00:51:00] been that people must be starting to use workers to develop, um, apps that essentially take in.

 Ken: A little bit, you know, requests of various kinds, send them off to GPT for for evaluation, and then pump out the results to the user. So like using workers as a prompting engine, sort of like a place to put your, you know, quote, auto GPT code to to have GPT help you build autonomous agents. Are you seeing that?

Ken: Are you seeing developers apply the platform in that way? 

 John: Uh, yes. Yes, absolutely. I mean, I mean, one of the ways they’re doing it is they’re just taking in a, you know, a request from the end user and they’re then enriching it with a prompt and then the prompt is not visible and they’re passing it on to, you know, something like chat GPT or whatever other other model they’re executing.

 John: Um, that’s, that’s sort of a simple, simple use right? So, um, I, I think that We’re going to see a lot of exploration, um, of, of, of AI, I think [00:52:00] also, um, we’re going to get, we’re going to hit, you know, the garden, the hype cycle where hype, hype, hype, and then it does this, and then it comes up and it plateaus, right?

John: I feel like we’re, we’re still in the hype phase. And it’s going to be kind of like, I’m not quite sure when it’s going to be. There’s going to be some sort of shakeout where it’s like, some of these things didn’t turn out to be as amazing as everybody thought. But then some of them are going to turn out to be truly amazing.

John: Right? So there’s going to be sort of, it’s going to be unclear. I think it’s unclear right now, which applications are. the most exciting, uh, for it from an AI perspective. And it’s going to take a little while before we get it really, you know, really sorted out. But, um, there’s, there’s, there’s a lot that’s there.

John: And I do feel like, um, the, the sorts of results you’re seeing from say GPT 4 do point to, you know, really rich new experiences, which we’re all going to see in applications going forward. Um, and so, yeah, I’m, you know, obviously I’m, I’m fascinated to see what happens.

Ken: What happens next? I’d like to ask a somewhat biased question.

Ken: Uh, so Cloudflare has always been known as a network company dealing with web traffic, obviously processing traffic for 20% of all the world’s websites. You’ve done storage. There’s a developer environment. Um, but last year you made a pretty big move into email, uh, by acquiring an anti phishing company.

Ken: What is your vision for email, especially with your, your history of coming from Uh, the email world, at least to some degree. 

John: You know, both Matthew and I had done email stuff, right, around spam. And I think sometimes it’s better to work on things you don’t know about because you don’t know all the pitfalls, right?

John: So we, we often worked on the web and DDoS mitigation, which, you know, we didn’t know that much about. I really were able to build up this knowledge and build up this incredible service. And we sort of stayed away from email because we’re like, Oh, I [00:54:00] remember all that stuff about deliverability and you know this really well, right?

John: About all the problems and then is it authenticated and just all the messiness of email because because email, I mean, is, is one of those protocols and standards that is, it is standardized, but it’s, there’s a lot of law and sort of knowing how it really works. And so we kind of stayed away from it for a long time, but then.

John: You know, so many threats come through email and, you know, this super well, um, and it became very obvious we had to help, uh, our customers and we, we had that problem. So what happened with area one, the company we bought as they were, we were a customer and we were using it and it was so much better than everything else.

John: We ended up buying them and then deciding that email was an integral part of the platform. And so we, we, and we’ve announced other things, right? This is now forwarding. We obviously have a relationship with mail channels. I’m sending email. Um, I think, you know, email, email somehow is a technology that refuses to die.

 Ken: That is true. That is so true. 

John: You know, you’d think that somehow SMS or WhatsApp or other things, but the, the asynchronous nature of email and, you know, the fact that everybody has an email address that can be reached, um, has made it that it is a, it is a very valuable way to communicate and, um, it’s just not going away and the problem is threats come through it.

Ken: So totally. Here we are. Yeah. I mean, when you think about email, everybody. When you create a, when you create a login to a website, they always need your email address because the email address is the one thing that everyone has at least one of, if not multiple, uh, and that that can never go away because it’s so integral to authentication around the internet.

Ken: Uh, and people are, 

John: and people are very scared to give their phone number. Right. So you can’t say, well, I could replace with a phone. You know, I could start asking people their phone number for an authentication [00:56:00] perspective, because then you, um, then you, you just wouldn’t get people signing up. So whereas email feels funnily enough, a little bit safer to give away, you know, worst case, I’m going to block the sender or whatever.

Ken: Yeah, I encourage people to think, especially within the company about how terrified they would be if. Someone got access to their entire email archive, like if they had to log into their Gmail account, you know, what could they learn about you? It’s virtually endless, you know, and that’s why security is so crucial because it’s, it’s just probably the richest collection of personal data that anyone could ever have on you.

John: It’s funny you say that because I often get asked, you know, what’s your, how should people keep themselves safe online? Right? Like people will ask me this for newspapers and things. And I always say, you know, to the, to the journalist, whoever, do you have a good password on your email that ask yourself honestly?

John: So, um, could I say to him, look, if you don’t and I can break into your email, I can control everything. I can change every password you have. I can read everything about your life. And so. It’s so important to have, you know, good password, second factor authentication, preferably with a key. I love these. One of my UV keys right here, um, you know, use hardware keys, um, because the email is such a such an important, uh, you know, sort of rendezvous point for everything.

John: I mean, I’m sure if I got your email, I could go email You know, change the password on any service you used and have access to that too. I can spread out across the world. So yeah, email is just too vital. And so Cloudflare felt we really needed to do it. 

 Ken: And do you, uh, you know, forgive me if this is a difficult question to answer, but do you have a vision for how Cloudflare wants to play in the email world in the future?

 John: It’s a hard  question to answer because the one obvious question is, you know, should we build some bulk email service because they will send a marketing emails, right? And they send them from our platform and we send out marketing emails and you sort of sit there and you think, should we do that? And then you sort of think, is that the business we want to get into?

John: Is that fundamentally a business which is sort of related to what we’re doing? It kind of is on the workers platform. It’s not really on the security side. So I don’t think we have a very strong platform. Yeah. Sense for what’s next in terms of email. I mean, email forwarding was very valuable. Um, there’s a very large number of people use email forwarding for their personal email little businesses things like that I think that’s that’s that’s been a very big part Um, I think that the area one stuff which is protecting a business’s email.

 John: That’s a good thing to be in Um, because we do fundamentally security story fundamentally rounds out the story about what we’re doing Where do we go from there? I don’t know I I still, I, you know, one of the things Cloudflare will do is we, we’re willing to iterate very, very rapidly  on things. Um, but we’re also very interested in what the market is telling us.

John: And I don’t think the market is telling us go build like a male chimp competitor or something. I, I don’t necessarily see that yet. Who 

 Ken: knows? Who knows? Yeah, things are changing. Yeah. My, my sense of it is, uh, is that generative AI, uh, could start changing that. I imagine that a lot of generative AI apps that revolve around email will be coming out where, you know, someone is taking in email data on one side, processing it with various prompts and whatnot, and then turning back and sending an email out the other in the other direction.

Ken: Uh, you know, we’re, we’re definitely seeing, well, in a recent interview with Spamhaus, we saw a very interesting application of generative AI, apparently spammers. Are, uh, generating email exchanges with the Spamhaus support team using chat GPT. So when they get an IP listed, when they get an IP added to a Spamhaus block list, they automatically send a very friendly email to the support desk and it engages in a conversation back and forth.

 Ken: Uh, and the only reason that they noticed this is because the spammers tend not to be so well spoken. In their, in their support email communications, but I thought that was a really interesting application of generative AI. 

 John: Well, I mean, we see that in, um, in phishing, right? I mean, one of the things that gives phishing away quite often is the language isn’t very good.

 John: Right. Right. And so you often see that there’s, it just doesn’t read quite right. Yeah. So I imagine that, you know, sort of Grammarly for spammers is, is going to help them write better. 

 Ken: Very interesting. Well, John, I think that about wraps it up for, uh, for our discussion today. Thank you so much for joining me.

 Ken: It’s been a fascinating exploration of Cloudflare’s past, present and future. Uh, and I really, uh, I’m always excited to see what the next news release will bring from Cloudflare. Uh, lots of, lots of surprises in the future, 

John: I’m sure. Lots of stuff. Yeah, yeah. I mean, there’s lots of stuff cooking. So yeah, don’t, uh, hold your breath because, you know, you’ll probably have to gasp a few times when we announce some things, so.

 Ken: Very good. Very good.