Building the Developer Experience for Cloudflare Workers

Hello, Rita. Thanks for coming on today to talk on our last day of serverless week. It's very, very exciting. So why don't we start with a quick round of introductions. You are a Cloudflare TV veteran. You've had many appearances this week and But for those of you who don't know, why don't you start with some intros and then I can do the same. Sure thing. Um, so hello everyone. I'm Rita. I'm the product manager focusing specifically on developer productivity for Cloudflare Workers. Which we'll be talking about a lot today. Both of those things. And for anyone who's joining us for the first time this week as well. Cloudflare Workers is Cloudflare's serverless platform that runs on our network of 200 data centers around the world. Okay, thanks. And I'm Jen Vaccaro. I'm our new product marketing manager for workers and I've started just a couple months ago in mid pandemic But definitely has been exciting to to kick it off with our serverless week and we've had a lot of exciting announcements that I hope people have been tuned into. So with that, Rita, I thought we could start and you could share a little bit about what excites you about serverless Sure. Um, so, uh, I feel like I have a pretty personal connection to serverless in that it just makes me think back to I studied computer science in school and and I remember graduating, you know, Thinking about starting a company with my friends and my dad asked me about, you know, so you have this degree. Now, can you can you go do that. I was like, well, I think I know how to like any application can imagine I can think about how to write the business logic for it and think about how it should be architected in terms of the data and the code itself. But How exactly servers work or how to configure the cloud, all that stuff. I was like, no one taught us this at school. And so I remember at my first job. One of my original tasks was to put together this web application that was going to be this internal service. And I got it running locally within a day, but then getting it deployed. I got so stuck and it just felt so painful to be able to get the code right so quickly, but The actual deployment being so slow and painful. And so what really excites me, I think, is that I think it opens up doors to so many developers to, first of all, I think it It reduces gatekeeping in some ways where the barrier to entry to being able to build your own stuff is so much slower. And then I also think about just all the time that it saves people and how many awesome things people can build when they're not inundated with. All right, I gotta go figure out How to install this flavor of Debian on something and then install Nginx on it and all this other stuff. I can just go and start writing some code. Yeah, yeah. And I think that's very interesting. And a lot of what this week has been about is Whether or not serverless has been meeting those expectations and a lot of the discussion has been, yeah, there's this ease of use. But then there's, you know, some of that hasn't always necessarily been met for developers and Some there's still those myths in the market that serverless is sort of this leaky abstraction of containers and and I'm curious on your thoughts on like has the serverless market. Do you think met those expectations of that ease of use and what you've just described I certainly think it does make things easier, no doubt, than they previously were, but I think going back and putting myself back in the same shoes that I was in. Then I think if you threw me into the deep end of most cloud providers today, I would still Kind of struggle to swim. Right. And so I think, um, once you're in the ecosystem, it, it might be a bit easier. And especially if you have someone guiding you through it, but I yeah I found that there are still There's still so much added complexity to it that what really excites me about the possibilities of it is like, how can we take all the complexity out of it and just make it super, super simple. And I don't think that that's really been done today. So in that in that vein. Do you want to share a little bit about what you've been working on for serverless week you had a great blog post go out this morning. Hopefully people tuning in have had a chance to read it. But if you haven't Go to the Cloudflare blog post and Rita has one on reimagining the developer experience. So why don't you share a little bit about what you've been working on. Yeah, so I think as context for What I've been working on, you know, people, more and more, I think we're seeing these developer experience teams and roles emerge. And I think you kind of got to break it down into What does it mean to have a good developer experience. Why do developers like some products, more than others. And I think that goes back to my earlier story of I'm really a good developer experience takes the friction out of out of it for you and makes it really easy for you to develop and For workers, which is a platform that you develop on top of. So if you we were, for example, someone who was providing an API like stripe does what it would probably mean for us is we have like Really nice as because they're easy to get started with good documentation and like the documentation applies to us as well. But when you're building stuff on us. I really think that it comes to what does the experience in general of someone developing something look like and so When we started out to get started with workers, for example, like for me to write a piece of code that got deployed to the edge. The first thing that I used to have to do is go sign up a zone. And so that was one of the things that we worked on last year as an example that we've been able to remove But really a lot of what we've been working on is from the moment that you get started through. All right, like I've signed up, but now I'm ready to start working on this and really bang away at it and iterating on it. Um, what, uh, what does that look like. Um, and then once I've written my code and I feel like I've got it working. I'm being making users comfortable like it's always just this kind of scary and tense feeling of All right, here it goes. I'm going to deploy to production and let's see what happens. And so I think a big part of it is how can we ease that, um, That tensity that builds up. And first of all, make it harder to fat finger things when you are deploying to production. So integrating things with CI. So it's an automated process and you don't You're not hopefully doing things particularly manually. But then afterwards, like you're never going to get things perfectly. And so how can we equip you so that you know that even if You know, maybe you there's like this one edge case you didn't test and now users are running into it. And how do we make it so that you can find it and quickly fix that. And so, yeah. Yeah. And something I thought was interesting. And maybe you can talk to the strategy, a little bit here on how you think of developer experience, but in your blog, you talked about these sort of four steps that getting started to iterate the release and then the observe So that's sort of how you've been imagining the strategy and how we go about making it easier at each step of that process. Yeah, absolutely. And don't get me wrong. When you work on it every day. You see, I think what was nice about writing about it was going, oh, it does actually come together. In this end to end flow and that's definitely the overarching strategy, but that's not to say that now we are done developer experiences over actually we have a ton of room to still grow and iterate it each of those categories. I think for us. And I think for serverless frameworks in general. One area that's probably lagging all the behind is observability. So to me, that's certainly where we have the most room to improve still today. But yeah, that's definitely been the strategy in mind is we've been working through this And talking about observability. Do you want to share a little bit what we have there that we've been we announced in the blog as well. Um, yeah, sure. So, um, to me, observability comes down to two things. I think the this I guess view on observability is your developers are going to be testing and production so Enable them to effectively. And how do you know that what is actually happening in production. I think there's kind of two key elements to it. One is being able to easily identify Is something going wrong. And there's different ways for things to go wrong. It can mean errors. It can mean latency and To identify trends. It's really hard to look at some logs and just be able to tell that. And so one of the first things that we released earlier this year was metrics that and Analytics that allow you to look at a graph and go, yikes. That does not look good. Or, oh, okay, great. I hit the button and everything looks the same. I can move on with my day. And then the second step to that in the forensics part where you go get to go sleuthing a bit And figure out, okay, yeah, there is like even if it's a 1 % change maybe and there are more errors. Now, so what are they. And so what you want to do then is Really dig into what's going on. So one of the tools that released for you to do that is called Wrangler tail and it allows you to get your logs from production. So if any exceptions are occurring, I would be able to see that and And hopefully go and fix it quickly. Um, I can show that off. Yeah, actually, if you would like me to Think that would be great. We can do a quick demo on Wrangler tail for our new logging feature. As you get that up. One of the things I Was interesting in your cloud for TV session. The other day on dog fooding workers is how a lot of these additions that we've made come from our own internal team. Using workers and and I think it was the access team that was like really pushing for those those met those analytics and that logging and because we have such a I guess a rich internal ecosystem of developers were able to kind of get ahead of the curve and and start to add in these features as they get requested and have a lot of people testing them before it actually hits the It's the public. So yeah, if you want to get up your share your screen. Yeah, so I'm actually what I'm going to do is I'm going to walk us through quickly creating a new project because I think that will be easiest. I'm going to assume you can see my screen now. Yep. Is that good. Cool. So to get us started. I'm going to create a new project. So I'm going to run Wrangler generate And then I'll give it a name. Call it CF TV. Alright, so now I'll open it up just to make it easier for myself. Where did it go. Created it here. So, um, the first thing that I'm going to do in here is add my account ID to my wrangler.com all So that it knows who I am. And so in here you can see my little worker, my little worker code. And So just to show off Wrangler tail first, I guess, and they're just talking about it earlier. Let's say I tried doing something like I'm going to say to play off the example I used the other day. I'm going to say hello and then name. So hopefully someone Would input their name right through maybe the request URL parameter. But what you'll see here is I Not so accidentally just for demo purposes, but let's say I forgot to actually define the variable here and I go, okay, looks good. And I can run Wrangler publish to deploy it. And for anyone who doesn't know about Wrangler Wrangler is our CLI tool. And so this is all assuming that you've already had Wrangler downloaded right Correct. And we have a quick easy walkthrough for anyone who's interested on that in our, in our doc section. Well, and we released the new release candidate today. So I'm actually running the latest version of Wrangler. But yeah, if you go to, if you go to the GitHub for Wrangler, you should be able to get our latest Our latest RC and download it from here as well. If you want to update it to the beta, which gets you the latest version of Wrangler Dev on the Edge, which I'm personally super excited about as well. Very exciting and hot off the press those just as of this morning, right. Um, so I deployed my worker and what was me. I'm getting an exception. And now I'm sad and users. Jen is writing into me and it's like Rita. Your worker doesn't work. So what I can do is run Wrangler tail and actually what I'm going to do. All right, I'm gonna I just shut it down quickly, but I just want to run it through jq so Wrangler tail typically outputs JSON format. But I want to make it nicely readable. Oh, and it's prepared to stream long. So now I'm going to refresh it and instantly. You can see I'm getting logs back. So now I can tell. Okay. The outcome is that I got an exception and the message tells me that name is not defined so I can go into my code and I can see you're right. Um, I never defined the name. So let's do name equals Well, Request URL. And then Get name. All right. So now I can publish again. And that fixes it for me. So I can run Wrangler tail again. And if I did something like console dot log name, it would show up in here as well. And honestly, probably what I would do just before releasing it is run Wrangler dev So that would allow me even before I published to say, okay. And maybe for those who don't know about Wrangler dev. Do you want to give a quick description of it. Yeah, so Wrangler dev is basically our edge based local development environment. I forgot to save it. And so we wanted to allow our users to be able to get this kind of feedback quickly that allows them to understand what exactly is happening. And Wrangler dev allows you to do exactly that. And so previously it relied on our previous service which ran somewhat in isolation from the rest of the edge. So certain things were a bit trickier to debug, but now it's running fully on the edge. And so I'm going to show this off because I think it's so cool. But for example, one of the things that users would struggle with is we have this CF object that exposes different parameters about the request to you. So I can do request dot CF. Whoops. Dot country and that'll tell me the country name. So I can do hello from country and previously what would happen is it would be like, I don't know what this is because there was nothing to pass the country down to it. But now I can pass this out quickly and it'll tell me like hello from us. And so now if I publish it. Um, anyone from around the world should be able to hit my worker. And yeah, it'll tell them where exactly they're running from or another colon actually I think dot colo will tell us exactly even which color we're hitting. So we can do something like this. Yeah. And one of the things that I think is particularly interesting in the way we're implementing this and how you touch on in your In your blog is that even though this is an edge based development environment. We have all the perks of the local environment, which I think is pretty cool and pretty unique for what we're offering through workers and a lot of our competitors in the serverless space. Yeah, I think what's super cool about this is that it I we love to talk about how workers offer you the best of both worlds in terms of the traditional problem of do I run the code on the client or on the server and the trade offs that each of those options. Introduce and it was interesting to then kind of apply that playbook to ourselves and go, you know, these are the problems that we're going to face if it's running locally. And running in a centralized look at like this is a big reason that local development environments exist is because that feedback is so crucial that If I was trying to write code and I was in Brazil and the server was in Virginia, I would end up getting really, really frustrated. And so the fact that we can fund this on the edge. And I mean, I get this feedback so quickly is really, really amazing. So Yeah, I'm getting SJC now, which means I can test my code. But I can now publish it. I imagine Jen, since you're in San Francisco, you'll probably also be hitting SJC but Yeah, actually, the kind of funny thing is if we do something like And we deploy and then we run tail might be able to see If any viewers are hitting this worker. Oh, And where they're hitting it from So yeah, to hit the worker after it's been published. And I'm just going to go to dftb.rita .workers.gov to confirm that it is published with a new version. So in this new this latest version of Wrangler that you were talking about. Are these the main updates is the Wrangler dev and Wrangler tail that you were talking about. Wrangler tail has been around for a while, actually. But yeah, Wrangler dev has been Wrangler dev is the new development in this version of Wrangler and it looks like we have someone from, you know, which airport code is ham. Is it Hamburg. Hamburg. Maybe let's check Yep, Hamburg in Germany. That's so cool. Oh, wow. We have a global audience tuning in. I know we have Ord, which is Chicago. I think that was one of the first Cloudflare colos. Yeah. Hey guys. That is very, that is very exciting. So I do want to touch on a little bit on what are some of the other ways that you're sort of perceiving developer experience with workers. And is there some other features or things that we have to look forward to, or you're getting up our analytics. So why don't we walk through that because that we've recently been improving our analytics and everything that we have available there as part of the workers experience. Yeah, this is all developments from the last past few months. Um, but yeah, you can see already we're starting to get analytics, which will tell me about my errors from earlier on. That was the exception that we saw as well as the CPU time, which I think is really interesting because I think it goes to show how powerful workers are. And I think one of the really interesting things to me when we released analytics is seeing people realize How efficient our workers are like, wow. A few milliseconds. It's like sub millisecond for it. It's incredible. And something I was talking with Ashkahn the other day, and I think you've seen Ashkahn's one of our colleagues metrics that he's been running Comparing cloud the time for workers compared to like some of the other big serverless competitors and it's incredible to see how quickly we Cloudflare runs in comparison and in milliseconds and and it's interesting because like at 50% volume, we're pretty similar To some of the other leading competitors, but as the volume increases, you know, some competitors can be up to like 30 seconds and we stay pretty consistently in the sub milliseconds, which is something that's definitely gives us an advantage to our users and their end users. Yeah, I mean, when you think about the network time of a request half a millisecond is really next to nothing. I'm like an average request probably takes around 100 maybe 15 milliseconds, but usually a couple hundreds of milliseconds. And so, yeah, I, it's really incredible that this doesn't make a difference. And obviously with our improvements other day, not having cold starts at all. Yeah, just really, really cool. Yeah. So you're showing us the CPU time. What are some of the other analytics we have And then we have the invocation statuses. So earlier when my worker was throwing an exception. I can see that in here. And we've also had some updates to our KV analytics right in our KV dashboard. Um, You know, it's Crazy. The team has grown so much. I struggle with keeping up with everything that we're releasing. I think KV analytics today are at the zone level. Some might be able to show them off in here. My worker that I'm using right now doesn't use KV But this one does. So yeah, I can see the number of reads that I've had and the amount of storage that I'm using and the bandwidth. I am delighted to see that it seems like someone is using my charades game. Nice. Very cool. Yeah, you know, one, one of the one question that I had received or I was in a call with a customer and they were asking, you know, if they're not using Wrangler because not all of our customers are going to be using Wrangler. Are there ways to get some of this observability or things like that outside of using Wrangler Um, for analytics, you can. So we have a graph QL API that you can pull all of that from for Wrangler tail specifically one of the really interesting things about it is the way that it's implemented. Where we built this thing internally called trace workers that then allow us to send these logs through an Argo tunnel, which is also one of popular products to your console. So full on dog pruning at every level of the stack as well. But what we want to allow in the future is for our customers to Use the same underlying technology to actually send their logs to any logging provider that they use today, whether that's data dog or you were like or something like that. Gotcha. Gotcha. That makes a lot of sense. But yeah, this is pretty exciting and your team is particularly focused on developer productivity in an in and of itself. So there's a lot. Are there anything You have top of your mind to be working on in the in the coming months or anything that we can give a teaser to to anyone listening out there. I mean, I definitely have one thing on my mind. I don't know how much I can share about it. Um, but Yeah, I like I said earlier, there's so much at every step of the way that we can improve that Yeah, I mean, actually, like, even in the coming weeks, we already have a few nice iterate smaller iterations shipping. So I guess I can give a little spoiler alert that we're going to be revamping our docs quite a bit. And so I'm really looking forward to that. And we have another little treat coming with that and Also, Going back to, like, kind of, like I said, improving it along every step of the way we have a really big improvement. I think coming to the very, very into the getting started part Of the journey that should simplify things pretty significantly that I saw a demo of today. And I gotta say it's pretty sweet. That is very exciting. Yeah. So all of our viewers should stay tuned in the next couple weeks that we have between the docs. And yeah, some other exciting things. And then of course we have birthday week coming up at the end of September, and we have a lot of cooking there on On the workers side, which is pretty exciting. One of the things before we wrap up here. I wanted to touch on that sort of the feedback loop. And I know in your blog. You talked about opportunities in ways that we're engaged on getting feedback from our community. So maybe you can share for a second how someone might go about doing that. Yeah, absolutely. Um, so a bunch of different ways. We're always we have so many different channels to receive feedback and so First of all, if you go either to my blog post or through the platform dashboard. There's a link there, they'll take you to a survey that will allow you to give us any general feedback. And more specifically, both Wrangler and our docs are fully open source and we really look forward to getting issues from customers and we'll happily take a look at those and resolve those Right. Well, thanks, Rita, and this is really exciting. Hopefully everyone's up to date with what we're doing on with serverless week there's been some exciting announcements. So thanks for tuning in. And stay tuned for everything else we have coming. Thanks, John.