🏗 What Launched Today at Platform Week?

Everyone, welcome to another edition of what launched today at Platform Week. Happy Wednesday. This is our third edition of the segment on Cloudflare TV. My name is Christian. I'm an engineering manager here on the developer advocacy team, and I'm joined by another excellent round of authors to talk about all of the amazing things that they launched today. They get a lot of things to talk about very, very big day. So let's start by just going around and having everyone introduce themselves. Maybe Rita, you want to start? Sure. Hey, folks, I'm a director of product here at Cloudflare, working on our developer platform, Workers. Greg, you want to go next? Sure thing. So, my name is Greg. I'm a product manager at Cloudflare, focused on storage. Hi. My name is Jamie here. I'm a director of engineering here at Cloudflare. I work on data logs, analytics, and I'm based in San Francisco. And my name is Alex. I'm the product manager for the cash team here at Cloudflare. Awesome! Welcome, everyone. So for our viewers, if somehow you ended up on Cloudflare TV and don't know what's going on right now this week, which is, I think pretty unlikely, we'll just do a little bit of recapping, though. We are in the middle of Platform Week, which is one of Cloudflare's innovation weeks. Every single day we are announcing new products, new features. It's a really exciting time to be a user, a Cloudflare it's also an exciting time to work here as well. We have a lot of stuff to talk about, it's a really big day. And to start, I'm going to kick it over to Rita, who's going to be talking about D1, our first SQL database, which people are very excited about on the Internet. I think that's fair to say, right, Rita? I would definitely say so. Yeah, the response today has definitely been overwhelmingly excited and positive, so we're excited to see that. So what is D1? So D1 is our very, very first SQL database on the you will be able to build with if you're building with Workers. So if you think about kind of our progression of developer products, you know, five or so years ago we announced Cloudflare Workers, which gave developers access to being able to run code or logic directly on the edge, and as a result, being able to build really fast and really scalable applications. But to really build full stack application, you also needed access to state for data. So, quickly after the announcement of Workers, we announced Workers KV, which was our very, very first kind of entry into the data space. And since then we've announced Durable Objects, which basically is a different model for how to think about data and compute on the edge. And then we announced R2, which Greg will talk about here in a bit, but a really big missing piece has been how do you, if you're a developer and you've built applications on other platforms before, SQL is one of the best tools in the box, right? It allows you to express yourself in really, really great ways. And SQL just underlies so many applications. So if you think about any software from counting to the Cloudflare dashboard, right, managing things like users and like what subscriptions they have and all of your products and inventory and all of that kind of stuff, nothing really beats the ability to be able to write a good old fashioned SQL query. So that's why we announced D1, to enable developers to do exactly that and be able to do that really, really easily. So once we open up the beta, the flow will be such that you can go into the Workers dashboard, click a button, create a database, easily create a binding and start querying it. Or if you're using Wrangler, which we announced Wrangler 2 earlier this week, that's going to be a really, really easy and fun and neat flow as well. And yeah, so a couple of important details about D1. So D1 is built on SQLite, which is the most ubiquitous database in the world, which I think is really, really interesting to think about. Like any operating system that you've used, so many phone devices are constantly using it. And I think it's really interesting from the perspective of Workers being in technology that kind of was born out of V8, which generally runs on the client as well, and taking it and running it on the server side. And so it kind of felt like this really clean fit. And so that's kind of like the interaction layer. And then as far as the storage layer goes, it's built on one of the other products that I mentioned earlier, Durable Objects, which means that it gets all of the benefits in terms of consistency and in terms of data being kind of prioritized to be as close to the user as possible without you having to think about it, but without also kind of being on the edge all the time. Yeah. So I think that's those are some of the, I would say, key bullet points. But I think the really exciting part is to see what people build once they have access to, like I said, kind of this very, very critical, meaty building block. Yeah. It's it's really cool. Like, it's not just like kind of the announcement of, like you said, like the database part of it. And there's, there's also stuff like there's going to be Wrangler integration. There's a really cool demo video in the blog post which talks or which shows like basically like executing commands against that database. Like also like dumping the database locally to a file. Like it's a lot of the stuff. I think normally I would think of like okay, like some companies doing a database thing or whatever and it's really like super basic. But there's a lot of stuff in this blogpost in regards to like kind of developer experiences, stuff like that that also gets included in the announcement and it shows how to run code and like it really is like just writing SQL statements in your worker, Which is something I've dreamt about for a long time. So, yeah, super exciting. Is there anything about the kind of like maybe like a second half of the post, I guess, that you feel like is worth talking about in regards to like, I don't know, pricing or like read stuff or anything or it should people go check that out? You think on the blog post, how in depth should we go, I guess is what I'm asking. Definitely recommend people go check it out. We tease out some of the obviously no product is going to be everything on day one and one of our core values at Cloudflare is to, you know, we like to ship things and be able to provide immediate value to customers and then ruthlessly iterate. So we wanted to give a small preview of some of the features that we envision coming up. And honestly, like, yeah, we look forward to users telling us what they need from us, right? That helps us really prioritize. So yeah, a few of the things that we teased out are things like replicas to ensure that reads our faster for more locations. Another really interesting concept is the ability to kind of run the Worker code really, really close to where the where the D1 instance actually is kind of similar to start procedures which will help people write more complex operations. Yeah. So definitely recommend that people go read about it. And then I'm curious, Christian, from your perspective as a developer advocate, what are the things that you look? Like, what's what's going to be the first thing that you build with that? Great question. Yeah, I mean, I have long wanted relational data basically in Workers. There's a lot of things where I've kind of figured out like weird cavey solutions to these problems or I'm like, Oh, this isn't like a great fit for it, but at the scale it'll, it'll be fine. So yeah, anything that has to do with kind of a relational data, I mean, I think you could go build like a Twitter or a Reddit or something like that on here, right? And that kind of stuff is super exciting to me as a, as an actual legit, like let's put relational data in our Worker. So that's one, one thing. And I think the other thing I'm interested in is, I mean, one thing, it's great kind of what you hinted at with SQL is like, SQL has been around for a long time, right? Like there's a lot of really excellent tooling and a lot of cool stuff you can do by building on top of SQL. I come from a Rails background. I love Rails still to this day. And so I'm I'm dreaming of maybe someone, whether it's, I don't know whether it's us or whether it's someone in the community building the next Rails on Workers and D1, that's kind of the dream for me. So, yeah, there's a lot of exciting stuff. Where should people go if they're interested? Like, what's kind of the call to action? Where should they go to learn more besides the blog post? I think the blog post is the best place. There's also a demo in there that you can play around with and then link to sign up for our beta that we hope to start letting people into. And also, I want to touch on I know that you made earlier, which is that this is a really exciting time to work with Cloudflare, which is also a good reminder to also say we're hiring for many, lots of many different roles. So if folks are interested in this stuff, please do apply. Yes, absolutely. Yeah. And also mention before we jump into the rest of the blog post today for any of these blog posts, if you just go to blog dot Cloudflare dot com, you'll be able to catch up on everything we're talking about. If you also go to Cloudflare dot com slash platform week, so Platform Dash, you'll be able to see all of the announcements throughout the rest of the week and kind of in a nice list. So if you if you want to catch up over the weekend on stuff that you probably missed, I know I have already missed some things. That's a great place to do that. Cool. So let's move on to the next blog post which is introducing cash reserve. Alex, you want to talk a little bit about that? Yeah. Thanks, Christian. So today we announced Cache Reserve, which is implemented on top of R2, which I believe Greg will be talking about in just a moment here. But the problem that Cache Reserve aims to solve is that across sort of any sort, any cache, anything, there's this aspect of ephemerality where stuff will be stored in that storage place for a short period of time, maybe a long period of time. It's a bit a bit hand-waving because there are different capacities all across the edge how long things can last there. Also, we've implemented LRU eviction, which means that if something that is cached sort of becomes less popular over time than our edge will evict it and replace it with a more popular asset. And what that does is kind of provide a really needed efficiency across our entire network. It would be bad, I think if customer data was sort of cached on maybe a different in like a different way, maybe on a first come first serve basis and then we hold on to it for as long as possible because that would mean that if something becomes popular sort of later in time or is maybe no longer relevant, then it would be served maybe from a farther away data center, which would mean that visitors to a website would be waiting longer for that content and the network would just generally be running inefficiently. That being said, there is this aspect of just like long tail content that exists as a concept throughout the Internet, and this long tail content might be accessed really infrequently. So I'm thinking about, let's say you're maybe like a Vimeo of the world or a another large video provider, and you want to serve as much as possible from cache. And these videos kind of go through maybe cycles of popularity. You know, I can upload something as a as a user of these video sites and it might not get any traction for months and months and months and all of a sudden it goes viral or something. So instead of having to cache it and then evict it and then recache it, costing the website owner a bunch of this egress Cache Reserve will sort of hang on to this content in cache for as long as the TTL requires, and provide that additional protection for people's origin resources. And so it I think it is a great sort of improvement to other sorts of caching products that we have that really help benefit, you know, these origin protection, Origin Shield products, some of the things that we've announced recently like cache, like tiered cache that allow for you to place multiple caches sort of between your visitors and your origin. This is providing one really, really large upper tier that will help to fan content out across Cloudflare network without your origin needing to be involved in that process at all. That's awesome. Yeah. And I think one thing that stands out to me from the blog post is that it's built on top of R2. Right. That's kind of the model there. Yeah, that's, that's definitely the model. And I think that's part of the reason why this wasn't a thing before, is because R2 wasn't a thing before. We needed a place that had the capacity to store all of this content and that didn't really exist on Cloudflare network until R2 was a thing. And so having a place that can hold on to these assets for a really long time, what was needed and that's the cool part, it also sort of shows the versatility, I think, of R2 and the Workers platform. Generally, you can really do a lot of use cases and it can support, you know, really large, I guess stores of data at scale. And it's kind of been cool to see from what Rita was saying. You know, like five years ago they announced, you know, Workers. And then just like the development of everything has been quite rapid and really impressive to see. Yeah, absolutely. That's that's super interesting. Yeah. I love the full circle, like Cloudflare building things on top of R2. That makes me very happy. So where do people go to try it out? It looks like it's in a closed beta. How do you recommend people get started with it? Yeah, it's currently in a closed beta state while we finish up some implementation details. We should be letting people off of that waitlist in a couple of weeks here. And so in order to sign up, you can go to the blog and there's a bunch of sign up links. Additionally, in your dashboard under the caching tile, there's a Cloudflare Cache Reserve page that you can sign up there as well. And so there's a lot of different ways to sort of find the sign up page, and we should be able to put that in customers' hands in the coming weeks here. And we're really excited to see what everybody thinks. Sounds great. We will all hopefully have 100% cache hits on our on our website soon. Right. That's that's the goal. Very cool. So very relevant. I think moving on to R2, a new hope for Object Storage, R2 enters open data. Greg, you want to tell us a little bit about that? Yeah, definitely. So we announced R2 probably around six or seven months ago now and we've been in closed beta since then working with some design partners to build out the platform. If you're not familiar, R2 is our zero cost egress object store. And so an object store where you can store data at a price that's about 35% cheaper than Amazon S3, but also get great performance and be able to retrieve that data back out without paying egregious egress charges. Yeah. So excited to see that to progress to open beta here where anyone can go into the Cloudflare dashboard, flip the switch and after putting a credit card down, start to use R2. So, are you able to talk about what the journey was from where we were in the last blog post to here, or is that kind of a secret? Yeah. I think a really big part of us being able to build out our R2 generally has been Durable Objects. Rita has talked to a little bit about D1 or SQLite running on top of Durable Objects. objects. I think that's been a great primitive for us to be able to use as the metadata layer for building out R2. And I think we're really confident with where the system is getting to. We obviously have some more work to do on the performance side of things and to continue to add out features. But we support all of the basic CRUD operations you can do on S3 today, except you get to stay on the Cloudflare network and not pay those charges. So I won't say it's been an easy path to get there, but a lot of work has gone into that and super proud of the team and what we've been able to put together. Yeah. And I think just knowing from talking to people on the developer advocacy team, like some of the stuff also that is kind of coming with open betas. I think there's some documentation that's been added to our developer docs as well. well. Is there anything in particular that people should check out there you think is kind of new and interesting? Yeah, so we have a few examples. So just so it's clear, there's two main ways to access R2. One is to go through a Cloudflare Worker and use our Worker API, but we also support an S3-compatible API. And so there are a lot of different packages that integrate with S3, whether that's Bodo or some of these other packages out there. And we have examples for how we integrate with those. And of course, welcome to get additional suggestions on ones we should add there. So we have a few more examples in there. We have the types and the actual definition for the Worker API and then we have the S3 API as well and we're adding more to that as we speak. So yeah, definitely check that out and then also hop in the Discord. We have a Discord where we chat with everybody who is testing things out and giving us feedback and things we should fix. So yeah, I think I think we're making good progress there. There's also a Q&A with your team coming up soon, right, in the Discord training. I believe that's on Friday. People can check out the Discord. Discord dot gg slash Cloudflare dev is the invite link. I remember it. But yeah, there's going to be a Q&A with with your team. So, I guess, anything you want to add there? Yeah. No, I mean, it'll be great to answer everybody's sort of questions, know, talk a lot about the roadmap and where things are going and what we'll be able to add here. Cool. Yeah, that sounds great. And again, if people want to dig into any of the stuff blog dot Cloudflare dot com, you'll be able to read all of the blog posts. And on that again, keeping on the R2 theme is our next blog post "Logs on R2: slash your logging cost", Jamie's here to talk a little bit about that. Yeah, this is first of all, I should say thank you to and shout out to Tanushree Sharma, who wrote the blog post and just couldn't make it today. But a lot of great work has gone into this and we're pretty excited. This is what people in the industry call a dogfooding exercise and is really great. So we've been early customers of R2 and today with open beta are able to share this capability with users out there. So just a quick explanation, a recap. One of the services that Cloudflare provides is something called Log Push, where we stream or push customers logs to destinations that they specify. Right now, there are five kinds of logs that we do this like. The obvious one are the HTTP request logs. And it's really a lot. I mean, we, we do this for a lot of customers. It's a lot of data. We have to do it reliably because these logs are important to them. By far the most popular destination has always been S3 and we push a ton of logs to S3, but with the appearance of R2, it's pretty obvious we should use this, right? And so we hooked it up and now it's available in the dashboard. It's very easy to set up and we can send all the logs to R2 as opposed to other destinations. What's really interesting about this for folks watching is that I can say we didn't use any secret API or some sort of back office tool or something. We used the same R2 that you all have access to. And this is an awesome thing because, as I mentioned, it's really a lot, you know, our logs are significant and we push a ton of them and we're very confident that we can do this reliably with R2. Yeah. I think that's super cool. And I imagine it will not be the last example of this. We see where people are talking about moving some sort of workload into R2 and seeing big cost savings. And for people who want to go check out the blog post, there's a lot of cool stuff about like an example website and seeing what the cost savings is from using S3 to R2, it's pretty substantial, right? Yeah, the cost savings could be huge depending on your specific use case, but also expect to see more because the great thing about Workers platform is that all of these things are building blocks and as we use the building blocks ourselves, we can get more capabilities. So we imagine that in the future many of our logging analytics products will be based on the same architecture where we actually push the logs into R2 and then do stuff with them. We have some stuff in the works related to that. I think it's better for everyone because we can leverage this massive network that is Cloudflare and then we also can. What? Well, you'll notice when you sign up, when you enable your R2 job, you're meant to provide some Uh, access. Keys that are the same access. keys you would get otherwise. And the reason for that is that we take this idea of custody seriously as well. well. So these are your logs, their customers logs where we're. more and more going to build on Cloudflare capabilities so that custody and isolation is maintained. Yeah. That's awesome. So I guess I'm looking at the blog list here. If people want to get started, it looks like there's actually a great section here at the end with developer documentation, which as a developer advocate, I'm always super excited about. This shows you how to how to get started, so that's super cool and looking forward to seeing what comes next. That's awesome. Yeah, actually, if you use the dashboard, you're presented. We support a number of destinations. They're all great. But the first one now is R2. And. And I encourage people to try it out. That's awesome. Yeah. Thanks. All righty. So moving on to our last blog post, which is "Durable Objects Alarms — a wake-up call for your applications". I don't know that much about this one, actually. It's something I haven't dug into too much. So, Greg, I'm excited to learn from you about it. Yeah. So I think the way you can think about this is we talked a little bit about Durable Objects earlier for R2 and Durable Objects are a way to do long-running compute in a single location on top of Cloudflare network. It's still a Worker under the hood, but we basically guarantee that all requests for the Durable Objects with a given ID will be sent to a single place. So the way that you invoke Durable Objects today is generally through a Worker request, which means you need to make an HTTP request. This is great, but sometimes you want your Durable Objects to wake up on its own at some point in the future. Right. And the reasons for this can be pretty varied, right? One reason to do it is for fault tolerance. So if your Durable Objects crashes and you're not sure if a client will send another request, you might want that everybody to wake up and complete any work that it had to do. Similarly, if you have a queue, if you want to implement a reliable queue and you want to wake up every so often, even if there hasn't been a request to pull work off of that queue and then go do some downstream operation, you want the ability to invoke a function at some point in the future, and that's exactly what alarms give you. So it's the ability to register a single handler helpfully called alarm that will be called at some point in the future that you specify, and each Durable Object for a given ID can schedule one handler. So you sort of have to decide in that alarm handler what work you need to do, but it gives you both fault tolerance and then also the ability to schedule work in the future. That's super cool. So yeah, I'm looking at the code example right now. So, what... I'm scared I'm going to open a can of worms here, but I'm just trying to think through from the developer perspective, what's the difference between this and like a Cron Trigger? How do you what's the difference there? A Cron Trigger invokes a worker, right. Cron Triggers are not particularly precise. Right. So they're at the granularity of about a minute, and there's less fault tolerance there. Right. So we will invoke your Cron Trigger, and if it fails or something like that happens, it'll just get called again the next time it's scheduled to run. Durable Objects alarms, one they are at much higher granularity, sub second granularity where you can set them, the second piece is that they execute directly in the Durable Objects. So you're not invoking a Worker and then invoking the object itself and making that hop. You're directly invoking the Durable Object and waking it back up. The last piece is that they're fault tolerant. So even if the alarm for some reason fails to execute, or you call your Durable Object and it fails, we'll retry with exponential back off until that actually succeeds and goes through. So it's a much more reliable way to keep your Durable Objects alive if you need to and process any of that work. Cron Triggers are more well suited for use cases like Cron Jobs, right? Versus something like a queue where you want a much tighter loop and you want to guarantee execution. At least one execution, I should say. Yeah. Yeah. Interesting. I see the distinction there. That makes a ton of sense. So how do people get started? Like how do they write their first Durable Objects line? Yeah. So there's examples in the docs today, I believe, and you can just go start writing them. So yeah, you can go build a Durable Object, and within that fill out the alarm handler and then make the call from your application and they'll start to execute. So, Yeah. Very cool. Awesome. Well, we believe it or not, we only have about 40 seconds left. We really got through everything. I mean, it went by so quickly. So, like I said, there's a lot of awesome stuff to check out on the blog. Deep dives on all of these topics, like example code documentation on how to enable all of these exciting features. Really big day here at Platform Week and we'll be back again tomorrow doing the exact same thing, believe it or not. So make sure to tune in same time tomorrow. Check out the blog, blog dot Cloudflare dot com. And thank you so much everyone for joining. Thanks, Christian.