💻 Product Chat on Cloudflare Tunnel and Cloudflare for SaaS Announcements

All right. Hello, everyone. Thank you for joining us. We've been talking every day this week at this time about what we have launched during Developer Week. So I'm Jen Vaccaro. I'm the Product Marketing Manager for Cloudflare Workers and Cloudflare Pages and have been running the Developer Week so far. I'm really excited to be here with Dina Kozlov and Abe Carryl and I'll let them introduce themselves and then we'll get started talking about two of our announcements today. One of them is Cloudflare for SaaS and the other one is Cloudflare Tunnel. So Dina, why don't you get started just by introducing yourself? All right. Hi, everybody. My name is Dina. I've been a product manager at Cloudflare for about two years now. I've switched around a few teams, but I was very recently on DNS for about a year and a half and I just switched to the TLS team at Cloudflare about three months ago. And I'm super excited to be here to talk about Cloudflare for SaaS. Cool. And I'm Abe Carryl. I'm also super excited to be here and have been at Cloudflare for a little bit less than a year and started on Cloudflare for Teams and working on the Cloudflare Teams dashboard and customer experience. And I'm now working on Cloudflare Tunnel as well or the artist formerly known as Argo Tunnel. And yeah, I'm super excited to talk more about some announcements that we made today regarding Tunnel. That's great. So why don't we get started with you, Abe, and just tell us a little bit about what Cloudflare Tunnel is and how it's different from what we've known before as Argo Tunnel. Yeah, sure. So not a ton has changed in the sense of the naming convention, but I will get to that in a second. I think that Tunnel, as the name suggests, is essentially a way to elegantly carve out a secure transportation method through otherwise inconvenient obstacles. And I like to use that example because Argo Tunnel or what we're calling Cloudflare Tunnel now is really no different than that. It's just a secure way of making a private connection between your origin servers and Cloudflare's network. And we really built Tunnel to remove the burden of securing and connecting servers to the Internet. And this model makes it really easy to connect things like servers to the Internet in a multi-cloud or hybrid deployment model, which replaces that error-prone network of poking ingress rules into your firewalls, which is kind of what I'll call that inconvenient obstacle. But yeah, that's kind of like a short description of what Tunnel is that hopefully paints a little bit of a picture of the naming convention there. That's great. And throughout the week, we've been talking about some ways it intersects with our other products, like one of mine, which is Cloudflare Pages. So it's been exciting to see how much this product is growing and is versatile for really so many things we do. So in particular, Abe, do you want to walk us through a little bit on what is it that we're announcing specifically today and what's new per se? Yeah, I think that to put it in perspective too, I think that it helps to kind of like talk about like the legacy world of what things look like maybe pre -Tunnel. And generally people would use things like a GRE Tunnel, which requires a lot of coordination on both ends of the Tunnel to set up kind of access to whatever the resource is that you're trying to bring online. That requires a fair amount of effort to deploy that application. And then developers end up spending a non-trivial amount of time blocking that down through ACLs or access control lists or rotating IP addresses or other kind of clunky solutions. And Tunnel is a much simpler kind of way to do that. What we're announcing today essentially is the ability, well, I guess I should back up a bit in time and say that a few months ago, Cloudflare announced wanting to make Zero Trust security accessible to everyone, regardless of the size scale and resources that they had at their disposal. And the next kind of piece of that is Tunnel. It's the ability to connect those resources one-to-one to Cloudflare or one -to-many and then to make that accessible for any use case, regardless of what that is. So previously this was really difficult to do and you'd have to do this in like large scale deployments, but making it super easy to do that through a model like Cloudflare Teams, I think has been really beneficial. So what we're announcing today essentially is just that. We're making Tunnels free and that outbound only connection feature specifically. And I think that it's a really convenient piece of not just making that connection, but also putting a per request, per identity rule engine in front of your Tunnels. And yeah, that's what we're announcing today. That's great. And it seems like the reception has been very positive, just kind of going through the blog and people's comments on that. So I'm sure we'll see a lot of interesting things built with our customers on this. So one of the things you talked about in the blog that I found interesting and thought we could walk through a little bit is how we are reinforcing our Tunnels. Maybe you can share a little bit of behind the scenes on that. Yeah. And I think that I'll kind of start there by how you create your Tunnel to begin with. And essentially the way that we kind of do that is by running a lightweight process or connector that creates that outbound connection that we call Cloudflare D. And instead of managing DNS or networks, Argo Tunnel helps administer and serve traffic from the origin with a single command. So you've run a command like Cloudflare D Tunnel create, and then a name. And the reason why that's a little bit different and why I start there is because essentially one of the big improvements that we've made to reinforce our Tunnels is this concept of name Tunnels, which I'll circle back to in just a second. But once you've created that Tunnel, we'll kind of give you a certificate or a cert PIM file that allows you to auth to your new instance of Cloudflare D, at which point you can then kind of go into the configuration of that Tunnel. And let's say that for my example, I like to use Hugo sites. So let's say that you're trying to create a quick Hugo site and you want to share it with your friend or like me, you want to share it with your mom and show your mom something cool that you're working on. And you can put that on your local host and you can say, hey, like instead of you having to hit this thing directly, here's a DNS record. You can point that DNS record to your unique ID, which is that like named Tunnel aspect.cfrgartunnel.com. And then you can just send that DNS record directly to somebody who you want to be able to do that. You can also put those Zero Trust security policies in front of that. So if it's something where you want to be able to only allow your mom or your family, like let's say, you know, my domain is at carol.com. You can make sure that anybody who has that can reach your, your, your resource and do that directly. But yeah, that's, that's, that's like some good context to kind of dig into. And I think that the way that we've been reinforcing is essentially building that new, new name tunnel architecture, which, which kind of decouples two concepts that we previously convoluted a little bit. And what I'll, what I'll refer to throughout this is as classic tunnels. So we're decoupling the tunnel provisioning and routing process, which, which are control plan activities in from the connection establishment, which is a data plan activity. And before in like the classic tunnel mode users would run a single cloud 3d command that executes all three of these actions at once, which essentially meant that anytime that a restart happened, we would need both the control plane and data plane to be readily available and accessible which isn't always the case for a number of reasons. And all three of these steps again would have to be repeated in order for us to reconnect from core to edge. And again, name tunnels kind of decouples those two very different kind of actions where essentially what you're doing is you're creating a tunnel, and then you're registering that in what I'll call our control plane. And then you're routing your tunnel, which is creating the necessary DNS records. And then finally, you're connecting the tunnel or connecting directly to the edge. And the expectation with this or the hypothesis that we kind of had when building this was that the first two steps will happen one time at the very beginning of tunnel creation when you're naming that tunnel. And then the third step can happen, you know, a number of times when you finally reconnecting. And hence, you're creating a much less error prone kind of state because you're only connecting to edge rather than needing control plane availability in order to make those connections. So I kind of have hit on it, but like the subtle nuance there is like when you're creating that name tunnel, we're doing two things. We're creating the name itself for the tunnel, as well as creating a unique identifier for that tunnel. So then if reconnects need to happen, a unique identifier that we can go back to and say, this unique ID was previously running on this metal, let's make that reconnection point back there and get that tunnel back online. I think that's one of those things that was really interesting about this. And you'll kind of see that like baked in throughout the process. That's great. That's really interesting to know some of that background. I know you mentioned like if you want to share your Hugo site or things like that, which is really relevant to what I was mentioning earlier on Cloudflare pages. And I was kind of wondering like for everyone tuning in, we announced that you can live stream your Cloudflare pages, which is our tool to host and deploy your websites. And you can use Cloudflare tunnel to like share your local hosts and have people see your updates live even before you commit any changes in GitHub. So Brita, actually Dina's sister was showing me this and I was like, wow, this is really cool. But being able to hear the background as you describe it now, I'm like, okay, now all the pieces are coming together, how that kind of fits in. Yeah, I think that was a super kind of cool and exciting project was anytime that there's that kind of the ability to thread those two concepts together. I think it's super impactful. And I think that we were just talking before we hopped on here about people at Cloudflare who love like tying these different products together. And I think that a lot of that stems from us being able to make those connections in house. To me, it's been the most impactful part of my time here and especially on tunnel. Yeah, yeah. And I think particularly developer week has been like showing how you can integrate all of these pieces together. And like the one plus one equals three, like you use these individual products, but when they're together, they're a lot more powerful and like you can make something really industry leading. So it's been exciting to see that. And I appreciate you explaining some of the background on that. So that brings me to one of the next questions I wanted to touch on. And you kind of spoke to this a little bit, but I'm wondering if we can deep dive a little bit more, but I'd love to hear about some of the challenges that Cloudflare tunnel solves for our users. And what kind of users are we particularly targeting for this type of product? Yeah, I think that that's to me, one of the most interesting parts about tunnel is that it's really as creative as our users are. And I think that we see a broad range of different use cases that are supported. You see everything from somebody who's setting up that, I'll keep circling back to that example, but that Hugo site, who just wants to share that and collaborate and make these quick iterative changes all the way to people who are using this for their infrastructure. And they're using things for whether that's putting zero trust security on top of HTTP web servers or so that they can SSH or connect to remote desktops or any other non-HTTP flow. Those are kind of like the two primary use cases. And again, I think that the real reason that we built this solution is because previously it required so much coordination to do that. And you also inherently needed to break your security model in order to poke these very intentional holes into your infrastructure to make those connections. And being able to do that through an outbound only connection, I think is really the key piece of tunnel and kind of like the pain points that we've tried to solve throughout. That makes sense. So can you explain a little bit like as of today, what is it that customers can actually do and build with tunnel? Yeah. So you can connect an origin server directly to Cloudflare and you can run a number of applications or services that way. We see connecting AWS or connecting Kubernetes cluster or to do a number of different application services like that. And then we also see people using it on the more developer use case of just connecting a site or machine and being able to reach those remotely. And those are kind of like the two primary cases that I think that we're really unlocking a little bit more by giving away tunnel for free. That's great. I'll be exciting to see with it free. Some of these new use cases that come up, I know that particularly with workers, we have a whole idea of like, okay, these are some example use cases. But then once you see what people are actually doing with it, you're always kind of surprised and excited by that. So it'll be interesting to see that as a free offering. So as we're sort of wrapping up here on the Cloudflare tunnel, you've touched on this but I want to make sure it's resonating clear with folks. Can you just explain a little bit more on like what's happening with Cloudflare tunnel behind the scenes, like how it's actually working with non HTTP traffic and all of that? Yeah, for sure. So tunnel effectively forces any request that's being made to access your application to go through Cloudflare directly, running either alongside or on your origin server. And that connects to our network and as well as client devices, or again, like that non HTTP traffic that you just talked about. Kind of the way that you do that is through a series of pretty straightforward steps, which is really just the three steps of creating your tunnel, or I should probably start with installing Cloudflare D and then creating your tunnel name. And then once you've done that, you can change your config file to support whatever the application is that you're connecting and then running that tunnel itself. Once you do that, you're really kind of unlimited in what you can do and how you can control or lock down access to it. I think that the exciting piece is how things like we can expand this out to broader use cases and do less direct relationships, I'll say, by building things with Zero Trust security policies through the team's dashboard and adding those applications in, which can be done by visiting dash .teams. And when you go in there, you'll essentially just add your application and then you'll pick how you want people or users to authenticate to that application. And then that's kind of like how you're able to lock down that security, which is a little bit different than the previous model of poking these intentional holes inward. Instead, it kind of allows that outbound connection. Gotcha. And so just wrapping up here, if folks want to get started with Cloudflare Tunnel, particularly what's available for free, do they have to go into the Cloudflare Teams dashboard or how would they get started? Yeah, great question. So you can just create a Cloudflare account and then you can install Cloudflare D right on the machine that you're working on today. And then once you do that, you'll be able to see your tunnels populate within the Argo tab. And once you go there, you'll be able to start making those connections and then pointing your DNS records to the relevant sources. And that's kind of how you would get started in a few easy steps right now. Great. Well, great. And folks who have any questions for Abe, feel free to send them through and we'll get to them as we go. So now I don't see any questions particularly yet for you, Abe, but thanks so much for sharing that with us. Maybe we'll have some time at the revisit any other questions that come up. But now I'd like to switch over to Dina. And if you could tell us a little bit about Cloudflare for SAS. I know it's something a lot of our enterprise users have been really excited about for a long time, but we have some new updates there. So why don't you tell us a little bit about what we announced today? Yeah. So today we announced Cloudflare for SAS. It's essentially a one -stop shop for all of your infrastructural needs for getting your SAS application up and running. So if we take a step back and we think of someone who's starting their own company, they just hired their first engineer and the engineer is super excited to start working on their SAS solution. But before they can start doing that, there's a long list of things that they need to do. And one of the hardest parts of that is certificate management. They have to make sure that their website and application stays encrypted, but not just that, but whatever they are offering to their end users, that needs to be safe and protected as well. And especially now, for example, Google Chrome flags websites that are not secured with a TLS certificate. And so it's really important that you have the security in place. And so when you think about certificate issuance, it's really non-trivial. You have to integrate with the certificate authority. You have to build a database and a system that can manage, issue, renew, store these certificates. Whatever your customers' essentially TLS requirements are, you have to be ready to support those. And so that's not just hard for companies that are just starting out, but it's also a problem with tech giants. And so HubSpot, for example, they're big. They came to us in 2017 and they told us that they tried to build their own certificate issuance pipeline. And they were having a hard time maintaining this. It was a lot of work and it was difficult to scale and they didn't want to continue to invest engineering effort into this. And so Cloudflare at the time was already a leader in the SSL space. We launched Universal SSL back in 2014. We have already issued TLS certificates for millions of domains. And so they came to us asking for us to help them. And so we took on this challenge and that's when we built out SSL for SaaS. And SSL for SaaS was meant to help SaaS businesses like HubSpot issue certificates for not just themselves, but for their end users. And that's been great. It's been the technology that powers a lot of tech giants like Zendesk and Shopify. And like I said, HubSpot. But we soon realized that what we built, which was SSL for SaaS, it was actually a lot more than that. It's not just certificate issuance, but essentially what you do when you set it up is whatever you set up on your application, the Cloudflare benefits of DDoS mitigation, any WAF rules, security performance, you're going to extend that to your end customers. And so it's no longer just SSL for SaaS, but it's the whole Cloudflare product suite that we're extending to SaaS providers and their end users. That's really interesting. I know we've had a lot of happy users on the worker side that have also been integrating with the SSL for SaaS and now with Cloudflare for SaaS. One of the things I just wanted to touch on is you were talking about how this offering is now beyond just your SSL certificate management. And you were talking about the different security and performance. You detailed this in your blog really nicely. And I'd love to deep dive into that a little bit more, particularly on the security protections with DDoS and WAF, and then going into some of the performance benefits that we offer. Yeah. So on the security side, Cloudflare has a great built-in DDoS mitigation. And so when you set up Cloudflare for SaaS, it's not just your application that's getting the DDoS mitigation, but also your end customers. And so these SaaS providers, their customers are relying on them to always be online, to always be available. And so it's really important that when their customers are being attacked, that they continue to be protected. And we extend that benefit out to them. And so not just that, but SaaS providers can also take it to the next level. And they can set up bot mitigation. They can set up WAF rules. They can kind of set up any granular features that they need to tighten up their security posture. And this is really important for any customer that might have banks as their customer, for example, and they need to have that security in place as well. And not just security, but we can also take it to the next level with performance. So for example, I might be an e-commerce platform and my origin servers might be located in North America, but what I am offering is a global business. And so I might have customers that are all the way out in Asia, and we don't want them to make the round trip every single time to North America and have a much worse experience and much higher latency. And so for those customers, they can use Argo Tunnel to make sure that we use the best routing to take them from the Asia eyeballs to the North America data center so that no matter where their customers are located, they all get the same excellent and fast experience. That's great. So we're seeing some of the merging between Dina and Abe over here and their products. And that's been something really incredible. And I mentioned this a little bit earlier, but to reiterate, the Cloudflare ecosystem enables us to have so much more just at our fingertips for our users. So the fact that your product is running on Cloudflare's network, like you said, 200 plus data centers so close to users worldwide, able to redirect traffic with Cloudflare Tunnel, that everything we're building on top of it really is providing more and more value to our customers beyond even just what the product itself is meant to do, or even where it started with certificate management. But now it's grown into something so much more powerful. So that's really exciting to see. One of the things that I'm curious on is if you could walk us through a little bit through the decision on making this product available to everyone. So we had it for enterprise for a long time, and what was that process to open the gates? Yeah. So we had it in enterprise for a really long time, but the market that we really wanted to target was developers. They're just starting out. And for example, on the worker's side, we've invested in a lot of work to make it as easy as possible to just deploy your code, and we'll take care of the rest. And so we really wanted to extend that to just your infrastructure. So as a developer, when you're starting out, you have to set up your origin server, you have to keep your customers' traffic protected, keep them online, make sure they have low latency, you want to offer custom domain support. And as you're figuring out your way through these challenges, instead of wasting months of engineering effort into building out your solution, you're just getting things set up. And we don't want developers to be spending their resources doing this, and instead, we want to help them out. And so two months ago, we launched a soft beta on Twitter. We just wanted to gauge how developers were feeling about this. Would they be interested in Cloudflare for SaaS? And we got a lot of excitement. We got a lot of requests. And what we've seen is that this really takes a lot of the burden away from customers. They no longer have to think about integrating with a certificate authority. They no longer have to worry about performance or scaling. That's a really big one. They're scared their site is going to go down, or they're scared that they're going to have a ton of users on board, and they might not be able to handle that. But with Cloudflare, you don't have to worry about that at all. You can just keep scaling with your application, and we want that to be one of the last concerns. And so now what we really want to do is we really want to bring it out to everybody. So the beta that we launched today is paving the way for Cloudflare for SaaS for pay-as-you-go, because we want this to be before you even start coding your SaaS application, we want you to start thinking about putting your origin server on workers. So you don't just have one server, but instead, every single of our 200 data centers, that is your origin. You then put the certificate issuance on us. You then allow us to take care of the custom domain so that your customers don't have to be pointing dina.mysaastore.com, but instead, your customers can just have dina.com and point it to your website and get all of these benefits. And so we really just want to reduce the time that developers take to get everything set up to essentially zero so that they can just stay focused on building out their SaaS solution. Yeah, that's great. I mean, we'll be curious to see this expand as well on the worker side. Since there is like a great integration story there, can you just explain a little bit how users might get started by integrating both workers and Cloudflare for SaaS? Yeah. So think of it as kind of two sides of the equation. Workers is for getting your SaaS application set up. It's where you're going to create, for example, your e -commerce site, your platform. And then Cloudflare for SaaS, it takes care of how you're going to now deliver your solution to your end customers. And so essentially, you would set up your worker, you would set up all your code there. And then once you're ready, you go, we enable you for Cloudflare for SaaS. And then you go and you can integrate the APIs in so that anytime one of your customers signs up for your application, you create what we call a custom host name. And then that automatically issues a TLS certificate. And as soon as they point the traffic to you, they're going to get all of the benefits of the Cloudflare network. And so together, they just work really well. That's great. And so speaking of the integration between them, also in your blog post talked about not only is this built for giants, but also the future giants and the smaller folks who are just getting started with their platform. And so in that vein, I'm wondering if you could talk about some of the products that you mentioned, I think Statusflare and the other one was Puma. And if you could share a little bit about what they're doing and even not an enterprise customer, but how they're getting started with this and what benefits they're seeing. Yeah. So something that actually really surprised us from the beta was that 80% of the users were building their whole application on workers, which instantly gets them lightning fast delivery time. It gets them the unparalleled redundancy. And something that's been really cool is to see what's being built out. So we've had e-commerce platforms. We've had a live chat system. We've had a blogging platform. One of my favorites is, as you mentioned, Statusflare. It allows you to set up a status page for your website. It allows you to set up monitoring. Another one was Plink. They create smart links for podcasts so that you can easily share that. There's also, we've had an online education platform is something that's being built out. So it's really cool to see all of these because all of these have the potential to be the tech giant one day. And we really want to be there for them. That's great. And so speaking of these small and then also enabling our larger customers, so what will be some of the differences between what's available for enterprise and what will be available for Pago? Yeah. So the TLS team has been hard at work with some SSL management customizations. When you become a large enterprise, you need a bit more granularity. You need more control. So they're going to get features such as custom origins. So being able to route different customers to different origins or being able to almost bucket them into different groups. Another one is Apex Proxying. So today, the way that you point to your SaaS application is through a CNAME DNS record. But there's an RFC that says that you can't have a CNAME at the Apex. Some DNS providers like Cloudflare allow it through CNAME flattening, but most don't. And so if customers want to have the application set up on the Apex domain, so that means on dina.com and not www.dina.com, then what they might need to do is they might have to point to an A record. And so for those customers, we have Apex Proxying as one of the features. And then coming very soon is Analytics. Thanks everyone for tuning in. I think we're wrapping up here, but feel free to tune into Cloudflare TV the rest of the week and stay tuned to what we're launching for Developer Week in the next couple of days. Bye.