🏗 What Launched Today at Platform Week?

Hey everyone, welcome to another edition of "What launched today" at Platform Week. Here we are, Thursday, May 12th. Still going strong. So many announcements, overwhelming amount, and this is a really exciting day. I got a lot of awesome authors here with me to talk about some really interesting stuff. My name is Christian. I'm the engineering manager for our developer advocacy team and I'm joined by an awesome crew, pretty all over like geographically distributed, I think I can safely say as people at Cloudflare Connect and stuff today, it's very exciting day. Let's start with a round of introductions. John, you want to kick us off? Hi, everyone. My name is John Levine and I'm a product manager here at Cloudflare working on our data and analytics products. Go. And over to Annika. Hey, I'm Annika. Product manager on Cloudflare Network Services and Kabir and I are actually coming to you from Cloudflare Connect. This is a real background. I can touch it. Not virtual. Live from New York, I'm Kabir. I'm a product manager on the Workers team and off to you, Matt. Hi, I'm Matt. I am a product manager on the activity team here at Cloudflare. I think, Dawn, you might be the last one. Hi everyone. I am Dawn Parzych. I am the director of product marketing for the developer platform. And this is not a real background. This is virtual. Maybe you and I are in the metaverse or something. We'll make it tough. All right. We're in, like, some Lego sphere. Cool. So let's let's hop into the announcements today. We got five authors here, five blog posts, some really interesting stuff. Let's start with you, John, and introducing the Workers Analytics engine. Yeah, sure. This is I'm super excited about something we've wanted to build and ship for well for a few years now since I basically joined started in this role of Cloudflare. So the Workers Analytics engine actually started, it was really motivated by teams at Cloudflare who are building on Workers now, like almost every team in Cloudflare is now building and shipping software on Workers. And there's two really common things that they're running into that they need to do. Number one, they need visibility into what their applications are doing. So you can think of this as like a use case of metrics. So people use Prometheus for or service like Datadog. They just want to get some graphs up in Grafana. They want to build alerts off of that and understand what's my code doing? And there are a lot of ways to do that. There are things that developers can hack together. I mean, we do have nice integration with Datadog. There are some things we could use internally, but there were some challenges which each of those which we can get into. But the second challenge may be more interesting, which is that almost every product that launches at Cloudflare you want to have analytics for, right? So a great example is like the R2 announcement this week, people need to know how much they're using R2, how many puts and writes are they doing, how many gets, how much data is being written in right out. Really important to keep track of that. We want to surface that to users. And the good news of Cloudflare is we have a lot of experience doing this. Of course we have our analytics for our core HTTP CDN or our firewall DNS. And for things like R2, we've done this many times before and we've established some really good patterns. And so we built something internally for teams to basically make it easier to build analytics and get that out of Worker. And the response internally was actually amazing. Like within like a few weeks we had something like ten teams sign up to start using this and we realized, okay, this is something that's going to be really useful for anyone who's developing on Workers. So yeah, so that's, that's the motivation for the analytics engine. It's really cool. You can use a binding, you kind of define your, your engine and then you write the data from a Worker and then you get a SQL API on the other side and that's it. You can query that data, you do it from your terminal, from Grafana, integrate with Jupyter Notebook. I love Grafana. It's actually I tell you, I use all the time super powerful to just be able to write a SQL query on a boom, have a dashboard, share that with the team. One thing we're really excited about that too is, developers, if you're trying to ship analytics about your product, we'd love to talk to you because we''d love to help people who are building analytics for their customers or want to build usage based building on top of that data. So I think is really hard to do today and something that we're we've gotten pretty good at, the analytics engine is really well suited for. Cool. So I'll pause there. Yeah that's that's awesome. What, what kind of things I actually like coming from the developer perspective, that's kind of where my head is at like yeah, you mentioned like it's, it's great for developers to get started and use it in that way. And I see actually in the blog post it's literally just like a Wrangler integration. Then suddenly you have like this, you have this magic binding code, which is awesome. Like what kind of things do you think are like good starting points for people like developers working on Workers apps that they could plug this in? Well, a really common thing. I mean, it's what you track is kind of specific to your application. So it's built around this notion of like a data point or an event. So idea is like most applications have like a thing you're trying to count. So I can give some more examples from Cloudflare products like Waiting Room. Every time someone is like queued up in a waiting room, that's an event you want to count. Or every time someone leaves the waiting room, that's a that's another data point you want to track so you can write these data points when that happens from Worker and you kind of emit them at any time you want and have metadata in there. Like, you know, in the case of the waiting room, I don't know, like what region is someone waiting in or maybe maybe have different waiting rooms for different for different programs. And you can, you can label those. So yeah, it depends. It kind of depends on your application, but it's super flexible. Does that answer your question? -Christian? -Yeah. Oh, yeah, absolutely. Yeah. And then on the other end, like you said, like SQL, so you can access it and from anywhere you can plot it in Grafana, which is really cool. So yeah. Oh, this looks awesome. I just, I had no idea this was coming. So I'm actually kind of in my head, I'm like, Well, what could I do with this? So how do people get started? Like, is their a signup form or like. How does that work? Yeah, we're really, really close to having something people can start using. We have a signup form right now. It's like from the blog post, Cloudflare dot com slash LP slash Workers dash analytics dash engine. dash analytics dash engine forgot the URL, right? And yeah, we'll send you an email when it's ready. Hopefully in like a week or two we'll let people start letting people in off the waitlist and start creating those bindings and running data from the Worker and start querying out again. That's awesome. We should get you and your team in the Discord Talk. I'm sure people will love this data nerds in there. So, yeah, they'll be super into that. Yeah. Awesome. Super cool. Yeah. So let's move on to the next blogpost, which is "Magic NAT everywhere, unbounded and lower cost". I learned right before this. It's not N-A-T. I'm sorry. I don't know anything. It's NAT. So now I know. Annika, you want to tell us a little bit about that? Yeah, sure. So I'll start with what's the NAT and then talk a little bit about why Magic. So for this audience, I'm really excited and feel grateful to be able to be a part of Platform Week. In a lot of ways, we're talking to customers that are really different than the ones that I talk to every day, which are generally network operators. But NAT is really interesting because the use cases that this new product covers actually cover both the developers as well as our enterprise customers. And then even kind of a new set of Cloudflare users, which is actually carriers and ISPs, like many of the ones that Cloudflare is interconnected with across the world. So a NAT effectively is an acronym, it stands for Network Address Translation. And what it does is actually really simple and honestly kind of boring. Basically a NAT takes a packet and the IP addresses the source your destination IP addresses that are in that packet and it switches out one IP address for another IP address and then the return packet that comes back to answer the original packet from the connection switches those back in the other direction. So basically reverse NATs. So why would somebody actually want to do this? There's a couple of different use cases. One is getting access to the Internet from private subnets. So as an example that everyone may be kind of familiar with or didn't even know that was happening is on your home laptop, you may have a private IP address assigned something like 192.168.0.1 that's assigned to your laptop. But you need to make a request out to the Internet to go to maybe Cloudflare dot com. And in order for Cloudflare to know to respond to your request to your laptop, it needs actually a public IP address that's associated with that connection. Otherwise if Cloudflare dot com tried to respond to 192168.1, well, there's probably millions of devices that are addressed with that within private networks. And so a private NAT or excuse me, a public NAT because we're talking about what we're connecting out to actually changes the source IP address from the initial connection to a public IP. ISPs also use this technique to be able to multiplex connections from thousands or even millions of devices onto just a small handful of IP addresses. And they do this by using other information about the packet, like the source port, in order to identify specific devices that are associated with an outgoing connection. And this is really important because IPv4 space is a limited resource. And so we ran out of it. We're totally out as of 2019 and there's not enough for each device that exists in the world to have its own unique IP address. So private access from private networks to the public internet is one big use case. And then the other half of this is on the private network side. Maybe you aren't trying to access the Internet, but you need to communicate between two entities that are on your private network. Let's say that you have a bunch of stores and you want to use the same addressing scheme for all of your store locations. You want all of your printers to be on one range and all of your security cameras to be on another and all of your desktops to be on a third just to make your life a lot easier as an IT person. But what that means is that if those resources in that private network need to get to something else in your network, like maybe you have an application hosted in a data center in order again for that data center to respond, it's got to know which one of your offices and which printer to send that connection back to. And so network address translation sits in the middle, changes the IP addresses back and forth, keeps track of all of the connections in order to make sure that your traffic can get to where it needs to go. So that's the NAT part. The Magic part is traditionally customers accomplish this or users accomplish this function in one of two ways, either with a physical hardware box. So they have something like a firewall that's sitting in an office doing that across all of their traffic, or on the ISP side, they purchase really beefy, big devices that are dedicated specifically for this carrier grade, that type of functionality, or there's cloud providers that have offered managed NAT services. There's really popular and frequently used services offered by cloud providers like AWS and GCP, just to name a few. But we've heard consistently from customers of those products that they're not fulfilling all the needs that they have. They don't scale up. So there's a concrete capacity limitation. So customers have to deploy multiple NAT instances, which all each, by the way, have an individual hourly cost to run them in order to be able to scale across all their traffic. And the cost model is such that customers actually have to pay twice for their traffic to leave the cloud provider. In addition to that hourly fee, there's a data processing fee and a data transfer fee. And so the cost can kind of get out of control. And if you have momentary spikes in traffic, that can really rack up a surprise bill. So from a usage perspective and a cost perspective, customers have asked for a long time for us to deliver something better. That's what we're really excited about with Magic NAT. So my big question was going to be What is NAT? I feel like you crushed the answer. Like, I feel like I get it now. That's amazing. So, no questions. A-plus. I love it. How do people get started with Magic NAT? Like, what's the call to action? Yeah, sure. So Magic NAT is in beta for enterprise customers. There's a signup form available that's linked from the blogpost or it is cloudflare dot com slash lp slash magic dash nats. And we're looking at extending this eventually to our pay as you go and developer ecosystem as well. So if you're interested in this, please let us know. Fill out the landing page, messages on Twitter or Discord. And we want to look at options to make this available to everyone for free or at a low cost on our pay as you go plans as a service, so excited about this, let us know if you're excited about it too. Awesome. Cool. Thank you so much, Annika. So let's move on to the next blog post.n We have Dawn here to talk about our growing developer platform partner ecosystem, which is something I'm really excited about in the Workers org. That stuff is super important. Why don't you tell us a little about that? Thanks, Christian. We're building out this developer platform is what we're calling it, but a platform that you can't bring other tools to. Where you get locked in isn't great. We know what we're good at. We know the vision that we have in terms of like compute and storage and networking. But there are a host of things that developers need in order to deliver applications that aren't our core competencies. And there are great companies out there that are doing these things. So we're partnering with these companies to make it easier for people to say, like, I'm going to build and deliver my apps on Cloudflare and I don't need to change any of the tools that I'm currently using because the tools I use are supported. I get my observability tools. I have integrations with Honeycomb and Splunk and New Relic. I don't need to worry about like the CMS, like it's supported, like you've got WordPress support, we've got Contentful support. We're continuing to build this out so that no matter what phase of the development process people are in, you can go to our directory and be like, Yes, here's the tool that I have. So here's the tool that I'm using. And yes, it integrates and works well within the Cloudflare developer platform. So the two big things that are announced in here is, one, we now have like a dedicated landing page where you can go and look at the directory of who the vendors that we have partnered with in our developer ecosystem, we're continuing to add more to here. So if you are a partner, if you are a vendor and you want to be listed in this directory, there is a form in that blog post as well for you to click on and say, Hey, I want to be a part of this directory as well as I want to work with the developers delivering their solutions on Cloudflare. Awesome. Yeah. I, so I've been like doing stuff with Workers for, I've been working here for like three-ish years, and I can say that like the momentum of like people interested in like our platform and stuff, it's shifted a lot. Like, people are so excited. Not they weren't excited before, they just like didn't really know what Workers was. People are really excited about this stuff and yeah, I'm super excited to see us kind of do this work. What here's a – I hope this isn't like a hard, tricky question, but like, what kind of things are like partners do we not have here? You don't have to name specifics, but let's say like type of partners. Would you like to see here that you think we need to reach out to? I have my opinion, but I'm just curious that your thought is. My thought, and this is probably a little bit of my bias as well as getting earlier into the development cycles. We have a lot of partners on like the observability and the debugging side of things, but more partners on that like early stage, like the planning, the design, like the iterating, like those types of things would be great to see some partners in here because it's the observability and the troubleshooting. Like, yes, things break, but like what are some of the partners we can do to make sure things aren't breaking? That gives you the help in that workflow as you're building and releasing apps? Yeah. So, Christian, what's your thoughts on that? You said you had thoughts and opinions. No, I think that's a great answer. I mean, I agree with that, actually. I think that in particular is such an interesting like that space is changing so much right now with how people I mean, pages is a good example. That's like the way that people build applications is changing a lot right now. So I think that that's an interesting and interesting area and. Yeah, I mean, I also I feel like just having more partners from like different frameworks and like open source projects and stuff. I also think that's a really interesting place that coming from like a Rails and React background, that's changed a lot in the last couple of years too. So I think having people from those those teams plug in would be really cool. So yeah, so people should definitely check out the the new partner. What's the official title, Partnerships Page, that you'd go on? Let me scroll down again. Like it changed like I think right at the last minute we changed the name of it because, why not? It is the Developer Platform Partner Ecosystem Directory? I have to say that slowly because it's a mouthful. Yeah. You can't say that three times fast. Yeah. Very cool. Awesome. Thank you so much. Cool. Let's move on to. To the next blog post, which is "Custom domains for workers". So Kabil, you want to to tell us about that? Yeah, happy to. So we're coming live from Connect. So sorry if there's any background noise, but we'd love to talk about customer demand. So what we launched today is another way that you can connect your Worker to the Internet. And this is fairly important because it's something that developers have been doing for years on the Workers platform. Right. One of the most important things, you write your code, but how are your users going to get it? That's a really big problem. There's all sorts of ways you can route to a Worker and we're just making more and more of those. And today, one of the really interesting things that we we changed about how you could do that is we're connecting it directly to DNS. When you're a developer and you want to connect something up to the Internet, you just want to focus on the code that you're writing, the application that you're delivering, the value you're delivering to your customers. You don't want to focus on how do I hook it up with DNS? Do I need to go, If I'm in a larger organization, talk to the guy in the DNS team, talk to the folks on the certificate, SQL team, get those through a bunch of IT processes and get to get them issued and connected up to the Internet. Or if you're in a smaller organization or you're just a sole developer, I don't want to go learn about what DNS is. I don't want to go learn about what SSL cert I want to issue for this particular domain. Instead, Cloudflare just does that for you. We have a really mature certificate issuance pipeline. We have a really mature DNS product. If you haven't used it, I recommend using it and we can just do that under the hood. All you have to do is go to your Workers app, click on the Triggers tab and say Add custom domain. You can type in, for example, app dot example dot com, API dot example dot com. Those can all be connected to different Workers. And a new thing that we're doing is for any of those workers that are DNS, routable, we're considering that the origin you might hear that term tossed around if you're a Cloudflare, longtime Cloudflare user, if you're connecting or phoning home back to a server that isn't connected to that isn't on Cloudflare Network, we call that the origin. In this case the Worker itself is the origin. And what that means is if you're talking from another Worker, if you're talking from any other service outside of Cloudflare, you can just say fetch on that domain name and we'll trigger that Worker again. So let's say I have a team that's adding a security header to one of my requests that's coming in before every single request that has to go to my API gateway. I can issue a worker that runs on every single route and then it can just fetch the API gateway as it normally would, just as if it's talking to a service that's off of Cloudflare and on that same zone, we're going to trigger another Worker. It's something that wasn't possible earlier, but it's something that we're giving to our developers today. Another thing to note is in tandem with an announcement that we made earlier this week, service bindings, which allows you to talk to other Workers directly from your code. You now have more and more ways that you can trigger other Workers. And there's a really big distinction between when you might want to use a Worker that's directly connected to the Internet via DNS versus a Worker that maybe is a private microservice that I don't want connected up to the Internet. Those private services can share resources across a single top level request. And these public ones, they don't share resources. They spin up a new top level request. From our side. You also get the benefit of being able to add any of your security protections that you want to in front of that API gateway. If you have something else running in front of it, you might have the security team saying the API gateway has to have a certain authorization header. We're going to put that in the WAF and we're using Cloudflare. We have to enforce that before the Worker even runs, things like that. It's really exciting and it's at the end of the day, a really great way to just have more and more flexibility on our platform and ways to get in and out of the Cloudflare network. I like the sound effects. Kind of add a little bit of suspense and, you know, like release of like, wow, here we go. Custom domains. I love it. We are we are in an echoey room. And I don't know, it sounds a little bit like a spaceship in here. We got something. Yeah. So, like some sci fi sounds in the background. Yeah. So, well, I would say that the stuff about like calling a Worker, like having it live as like kind of the zone or like whatever as the origin. Like, I think what you said is like that something couldn't do before. I would actually go a step further and say that was like actively very confusing to people that you can do that. - Like - Yeah. I've talked to people many times and like our discourse stuff are like, what's the deal with this? And I'm like, I don't really understand dense enough to tell you why it doesn't work. I just know it doesn't work. So, so that's really exciting. And yeah, I think that's a huge improvement. And yeah, I mean, I think that just will help a lot of people with that confusion. So people can use this right now, I think is what you said, right? Like they can just go in and start adding these today. Yeah. Yeah. We've launched it as an open beta today so you can hop into your dashboard and start adding custom domains to your heart's content. We do want to add a little more configurability for those who don't want an Excel cert. Or maybe they don't want to. They don't want their experiment to show up on a CT log. So there's a little bit more work to do just to make it more and more configurable. But today you can just go into your dashboard and add a custom domain and start testing. Love it. That's awesome. Yeah, I definitely recommend people I know people in the Discord have already started using it. Just so you know, the official reaction emoji of this blog post in the Discord is the Kool-Aid man. Oh, yeah, oh, yeah, oh, yeah. So, you know, so that's how excited people are about it. I think I put that on my resume somewhere. Yeah. Just, just wanted you to know. Very important stuff. Cool. So let's move on to the last blog post of the day. Last but not least, announcing PubSub, programable MQTT based messaging. Matt, you want to tell us about that? Yeah. So for those of you who don't know what PubSub is or what it is, instead of most basic terms, it is a an event, bus or message. So I have maybe an IoT device which could be something like a payment terminal, a virtual machine, another cloud, maybe another Worker. And I want to talk to each other. I can publish messages. Those messages could be telemetry and events. It could be a notification to send an email to a system that maybe has to happen a little bit later, but maybe not right now. It could be transaction data counters, anything you can imagine. In fact, in a blog post, we have a concrete example around what it would look like to take transaction data, right? There's little sort of card terminals that you see all the time that every food store has these days, every sort of little cafe has. Right. Nearly all of those took MQTT and so we built those specifically rather than sort of building a bespoke protocol is because it is so pervasive. We think that's a big win for developers. So the nice thing is like PubSub is fantastic. People want PubSub systems, but what about if you want to write in your favorite language or you have existing systems to integrate with? If you had to write in Java or Rust or Python, right, there are tons of standards based libraries already to go. And so if you're already using base system today, there's a pretty straightforward path to come up with Cloudflare and benefit from scale or programmability. Or if you're just getting started right, you get to kind of use the tools you're familiar with. If not, you can always use Focus and we'll be totally okay with that. The other major part, and I think this is sort of I think where we really want it to be different is making it programable. So it's not just a message broker doesn't just publish messages and have subscribers subscribe to those messages. Maybe there's one or more so you can have fan in or fan out scenarios, but actually being able to rewrite those messages on the fly as they get published, that can be super useful. That can be for fixing up data, scrubbing PII, counting and actually aggregating those metrics. And so one of the cool examples that kind of worked out this week was if you can do all of that from tens of thousands of devices, all publishing to Cloudflare, you can use an analytics engine, just as John was talking about out of this session, to take data out of that payload increment counters and metrics and make them variable and then pass those messages back on to the subscribers as if nothing happened without any significant increase in latency. You can do all of that without blocking the message delivery that can really grow. You can if you're sitting inside that workout, well, now you can actually pass messages and say, okay, I want to capture or sample messages that have this particular field or payload or on this topic, messages it pops up organized by topics, I can write this to R2. I could push them to another Worker and aggregate them up as a bunch. I could write them to Durable Objects. And for those of you following along and I've seen other sessions maybe in the near term, write those to D1, our SQLite based database as well. So being able to just aggregate messages from thousands or tens of thousands of endpoints turns out to be really, really flexible. So we're really excited about this. We've got a bunch of teams internally that are already knocking on my door and saying, Hey, we want to build things on this as well, which is always really cool. And I think one of the big pieces we're thinking about is how to get this into customers hands as soon as possible. We are holding ourselves, I think, to a late May, early June, opening up the private beta. And I'm watching the sign up forms come in and the number increment and dreading clicking all the buttons to enable these folks, but also kind of excited about it. That's awesome. Yeah. You know, what it kind of reminds me of is when we did WebSockets with Durable Objects a while ago, I was very scared as a developer of WebSockets, I was like, Yeah, I'm probably not ever going to get into that because I don't. That's scary. This is like the same kind of thing to me, or it's like I see the, the huge utility of this, but would always be like very scared of setting this up for myself in production. So if I can just like handle it with a Worker, like it's amazing. Also, I think correct me if I'm wrong, I use home assistant like all the time, which I think is like a big MQTT thing. Like they use it everywhere in there. So I think I could connect my thermostat to a Worker now, which is as a complete dork. I'm very excited about it. Does that sound like I'm on the right track there? The really important use cases. The other Christian that I work with is one of the engineers on the team on this has actually done exactly that is like a big IoT geek and so one of the many, many use cases but like you can plug that in at home and that's kind of important to us as well is like there are folks going to bring million payment devices or more to us and then benefit from scale and security. There's a whole bunch of really interesting small scale indie stuff, people experimenting for the startups and wondering what they want to build on. And so one of the big things about this is making it accessible, making it easy to use, not making it hyper expensive to get started as well. And so then you can go home and tie it into home assistant and not have to worry about bills. Yeah. That's awesome. Well, believe it or not, we only have, like, literally 10 seconds left. So I just want to thank you all for for coming and talking about your blog post. Thank you, everyone, for tuning in. We'll be back same time tomorrow. Talking more platforming blog posts. Thank you so much.