Talking Serverless with CodePen Founders

Hello everyone, my name is Rita. I'm a product manager working on developer productivity at Cloudflare and today with me I have Chris and Alex. Thanks for having us Rita. Yeah thanks. Yeah super excited too. I think a ton of people are familiar with you guys either through CodePen or through CSS tricks especially since that's how so many people get started with web development these days. So I would love to, I've definitely been a fan for a long time and would love to hear a little bit about how you guys got started even working on such a cool project that I think has enabled so many developers that are just starting out. Yeah cheers. I mean the product part of that is CodePen. Like if you use our thing to build stuff and that's what Alex and I work on together. We've been working together for a hot while. Yeah we're three minutes later. Yeah and CodePen, you know we were just chatting about this. It was fun. CodePen started as kind of a weekend project or at least that's what I kind of convinced Alex of it. And it was a way to put demos on CSS tricks. Yeah what do you remember those days? Yeah I mean as a you know I have my developer hubris and I was pretty sure we'd be we'd finish this thing in three or four months. Six months tops and it's you know we're going well on eight years and still not quite done. So it's been a bit. Just a little bit of scope creep. We're talking about CodePen and it's like a you know it's an editor in the browser with kind of a social layer to it. So people can go there and write HTML, CSS, and JavaScript and see what you're doing real time ish. You know kind of stop typing for a second and see the results of that. And that's been really fun for a lot of people because it's you know plus because it's browser based. So you can't lose it. You know you get a URL to it. Other developers can follow you. They can heart it and comment on it. It's got this kind of element of fun to it which is great. But of course there's you know we have you know millions of users who've created tens and dens of millions of pens. So now it's become this resource that's like if you're looking for a way to do something in front end it's there. You know like probably 50 times over which is kind of cool too. So there's a lot of like lurker users too that just think of it as a place you come to look for 50 examples of tabs you know because we got them over there. So that's been kind of fun. You know in the early days you know so for one thing it's not just HTML, CSS, and JavaScript. There's more these days. But even in the early days you could like write SAS. SAS is like a super popular pre -processing language for CSS. And you know we would you know somebody would not me somebody smart like Alex would spin up a server to process SAS and like would have one job. And we thought we were so smart for doing this you know. Let's go spin up an Amazon server somewhere to has this one job which is to process our SAS. So that's you know times are changing these days with how and why you would do that you know. That was kind of a softball to get us into serverless stuff if you want to think it. Yeah definitely. I mean I'm actually curious what was the itch that you were looking to scratch when you built CodePen? Like what was it that wasn't out there? And there's certainly I feel like nothing quite like CodePen but from your perspective what was the thing that was? You're more like in tune to your to your competitors when you're us. I think CodePen was not the first of its kind. There was other other apps that were similar to it. I think of JSBin and JSFill, the early ones you know. Very similar in its approach you know. It's more different these days but you know. And I loved it. I had and still do have a JSFiddle account and on CSSTricks specifically I would make demos. Here's how you do you know rounded corners that have roundout tabs on the bottom or something. And then I just make an HTML file and a CSS file and FTP it up somewhere and just link people to that document. Here's the demo. Go look at it. View source if you want to see how it was done you know. And then along comes a site like JSFiddle. Like this is a way better way to show somebody some code. Way better. So I had this moment like should I go back and take my hundreds or thousands of demos and port them all over to this app? Well you get this kind of weird feeling like but I don't control that app. They have no business plan. You know like what if I what I'm a publisher too. I run a business. What if I want to put an ad next to it? I should have the ability to do that you know if I want to kind of thing. That was the early days and so it evolved. So that's how I roped Alex in. You know help me out man. You know use your skills. And that was the thing that got you. Yeah I mean honestly I just thought it was a cool technical project. You know at the time we were kind of working at a at another company together but we were this was just kind of a side project. And at the time I remember a big part of it was processors themselves were like a new idea. The idea of transpiling from one language but then executing in another language was fairly new. It was new to me. So the whole idea of SAS and SCSS and I don't even think Babel existed at the time. At least I wasn't aware of it. So that was kind of interesting. I was like oh variables in CSS. Of course that totally makes sense. How many who wants to rewrite the same color you know 10 times in the same CSS file. And so at the time that that was kind of the interest right. And so we were AWS was new to us at the time. You know I think EC2 launched in like 2009 or something like that. And this was like 2012. And so it was still new to developers. The idea that you could you didn't have to buy a rack of servers dedicated to running your code which was you know mind-boggling. So it's like yeah let's play with these APIs. Let's play with this with the cloud right. Like it was the beginning of the cloud for us in our world. I'm sure there was people really early adopters that had been doing it for years then. Yeah so it was is it mostly still running on EC2? Is that how you guys got started building it? Somewhat. I mean yeah I mean these days we do run plenty of like web servers and things like that for like saving apps and stuff like that. But the way we do processing it's all handled through serverless these days. It's we deploy our serverless processors on lambda and we shoot those things over. So it gives us kind of like the security layer and isolation. But also the speed of being able to execute things randomly. And so that's how we've handled it today. But we still have plenty of things running on EC2. I remember the days of it were kind of like we have first of all these languages are like some of them are written in back-end languages. Or I mean all of them are to some degree. Because a lot of them are in node. But some of them are in Ruby. You know SAS was originally Ruby. And you see you're doing the one thing you should never do on a web app. Which is like hey come to our app and just write arbitrary code and we'll execute it for you on our website. You know which sounds like incredibly foolish just for security reasons. Like if why can't somebody write code that says well then ask the server for its security keys and email them to me and then I'll use it to bitcoin mine or whatever. Which obviously lots of people are trying to do. I'm sure many people are trying to do that every day on code 10. So security is a big deal for us. And I remember the early days of serverless. The promise of being like well why would we spin up a server to do this? Why don't we have some little isolated server that has no abilities outside of itself process this code. So aside from the fact that it was cheaper and faster and easier and all that. But more secure. Like you go down the checklist of stuff that serverless brought for us. And it's like all those things are amazing. How could you not be interested in this? Right I'm curious were you did you have any skepticism at all at first? Like what was do you remember the first time that you heard the term serverless and what were the thoughts that came to mind for you? Did you think it was going to be useful to you and were instantly on board or did it take some warming up? Yeah I'm ironically a bit of a technophobe. So I kind of have to the moment I hear about anything new I'm like that makes no sense. First time I heard you could run a function I just did not get it. I felt so old. I don't know how old I was at the time but I was like I think this industry is passing me up. It makes no sense you're going to execute one function. I upload a zip file and I just didn't understand it. Ironically once I start seeing the use cases and this is someone who literally runs code on behalf of other people which is I feel like is the perfect use case for serverless functions. I didn't get it. I didn't understand how it would apply. It didn't seem like you could do that much but then when you realize that you can connect to all these events that are happening in the cloud and react to them and take action intelligently. Things started to click and I kind of feel the same way about Cloudflare Workers in the sense that when I heard about them too I was like okay well I'd use something like Lambda Edge and that takes like 30 minutes to deploy and so you're a little you know that's a very frustrating experience. I've kind of moved away completely away from that at this point where if we ever need to run anything at the edge we run it on workers but initially you don't until you start seeing the use cases for why you use them and how you use them strategically. I've always felt like either edge workers Lambda or serverless at the edge or serverless at a data center neither one of them made any sense to me and today we rely on them everywhere and are only investing more effort into building on top of them. Yeah I can't remember the last time you're like let's spin up an old school web server that's like not in our mind bank anymore it's only as piecemeal moving stuff off of them when we can you know we've got a database running out of serverless function the other day. Even that's going serverless which is still mind-blowing that that's even possible but it is. Yeah I mean we realized almost as soon as we launched workers that state and compute gotta go hand in hand so you gotta have one to have the other it was why we released KV. Yeah I was gonna say that to me is like the peanut butter and jelly of serverless. The fact that you released your workers with the KV store that's been one of the biggest things that made it easy to adopt because at some point we needed to manage some kind of state and you so you go okay well what can we do that can manage that many connections and instantly as a developer you're like well maybe we could use Redis maybe we could do this but then you get into latency and how long you have to respond to this web request right and so when Cloudflare provides you this KV store and says hey this is literally this is made purpose made for this environment so like feel free to use it because you'll be able to respond to requests in real time that that was a game changer for understanding how to start implementing and using relying on workers for us at CodePen that made a huge difference. Do you remember what the first worker was that you deployed that kind of made the whole thing click for you? Yeah I think the screenshots actually were the thing so there's this pattern that I've attempted to I've recreated at different levels of success and this is by far my most successful but it's kind of like the third iteration where the pattern is I want to have a CVN but I want to generate the content for that CVN dynamically which is kind of like it feels like a bit of an oxymoron to be like I want to generate static content dynamically but that's kind of what we do right so we take screenshots of our pens for like kind of previews and unfurling and a bunch of different little reasons and so what we did was when we send the request we check the KV store to see if we've already taken that screenshot and if we have we just allow the request to proceed because we know that it's going to be either in the cache or the origin but if it doesn't if it's not in the KV store we know that we need to send a request for to generate the screenshot which takes quite a bit of time it takes like almost three seconds but in that time we're generating the screenshot and our users are only the first person who's hitting that request is going to get that delay and then after that no one else gets the delay because we've generated the screenshot we just kind of respond with what's in cache or the origin and so that's that use case I've tried to recreate that for all kinds of things for I kind of look at it as like kind of recreating what Cloudinary does for images but for other purposes so like we've built packages when it's kind of a feature where we're working on for a bit and still are in development for but screenshots is this example but following that pattern and being able to generate that for our workers has been great. It's just like it hits this URL and it's like do I have it yes serve it no generate it there's no like middleman it's like incredible it's such a clever pattern we think. Yeah it's it's I love that pattern because it adds a lot of simplicity for us you know like you don't have to I don't honestly unless you have something working at the edge that has some form of state that manages that it becomes difficult you end up having to go all the way the origin every single time to check it and that's where the KV store was huge for us to be able to do that and respond in the amount of time that's you know we didn't want to have a huge delay for this stuff otherwise we're pre-generating a bunch of screenshots all the time and we're not which is what we used to do you know we just constantly be churning through all these screenshots and maybe no one saw those screenshots so you just you're doing a bunch of work for no reason but you're you know you're prepared for that so that I really love that pattern I think that's it's such a cloud -based pattern that's wasn't a bit like six years ago you couldn't do that you know like I feel like when you first hear serverless you're required to go through this little like existential clever guy moment where you're like server open but there's still servers required that you have to go through that and then you have to get over it and move on with your life you know I think you have to do but now finally it's starting to feel like maybe there isn't servers you know like workers don't really feel like servers you know right the lambda does yeah yeah I mean it is I think of it as my personal job sometimes to make you think about servers as little as possible or you know hopefully the next generation of developers won't won't even know that they're there won't think about them at all and that word will just really confuse them they're like what is there an option so it's an admirable goal right right I like it one thing that I thought was interesting that you mentioned Alex was talking about using lambdas and then transitioning to lambda at edge for certain things versus workers for us we definitely I think there's this perception generally in the industry of like the edge is intended for only very specific purposes or for certain use cases and more and more what we're seeing is actually you can do most things on the edge that you could do centrally and that was the intent behind some of our announcements this week as well especially workers unbound allows you to run all these meaty workloads that I think generally people don't associate running on yet with running on the edge so I'm curious to you what's the distinction between something that you would try to put in a worker versus not yeah so I feel like I'm still wrapping my mind around what to to do in that instance so I guess I could start from the perspective of like some of the things that hold me back from putting certain logic on a worker and you know when you're in your server environment you usually you've come through an authorization layer you've come through a security layer and so figuring out how to start doing the authorization on the worker and realizing hey I can manage my state on the worker and I can validate authorize this request so for us it's not like we're updating a database on the worker we're kind of like doing we're literally doing work because we're taking the user's code processing it transpiling it whatever it is that that they requested and then returning it to the browser and a lot of that work ends up being it's fairly stateless but we don't want to expose it to the world you know we there wants we want there to be some form of like authentication that this person is coming from CodePen and has valid session so starting to realize okay we can move a lot of that work closer to our users like with when they have like a 20 millisecond latency and realizing how powerful that is you know I think we've done we followed this interesting pattern where we live near our servers so we don't we happen most of CodePen servers are in Oregon and you know Chris lives in Oregon I live in Seattle and so we're like oh my I mean CodePen's just as fast as it gets. If you live in Oregon or Virginia the Internet is so fast. Yeah we're like what's what's all this latency people talk about so I'm still wrapping my mind around the fact that that's not where the rest of the world lives and how amazing what kind of a service you can provide to your users based on that so now that we're wrapping our minds around the idea that hey we can do some authorization if you want to do some like light authorization with the JSON web token where we're like making sure that hey you came from CodePen you have a valid session and now I can start doing a work on your behalf and you don't have to go all the way to Oregon if you're say in Australia and deal with the latency of the slow speed that's like a really incredible service and so we're starting to kind of untangle the CodePen of today and start kind of bringing it out to the edge and that's you know because we're wrapped up in that world and we've been working on this for eight years it's taking a bit of time but we're you know we've got big plans to like start pushing that out further and further just because it makes sense and the experience on Cloudflare from what I understand it takes about 30 seconds to get to you know as far as I'm concerned it takes 30 milliseconds to get to Oregon so from my perspective it's it's near instant and it's it's been really great so far so that's kind of like where we're where we're at with that you gotta think it through like the architecture of them that's not straightforward it's not like pick up some code and move it over sometimes you gotta think what's gonna work and what's not I it occurred to me this like we have one function for exporting that's like that's an interesting one isn't it like I remember when we were architecting it we went through a number of versions one of them would like pick up a bunch of files send them across the network to the function and it would ball them up as a zip and either save it to its temporary storage or to a bucket or something and then give you a link to it real quick so you could download it in the browser and then we're like well that was it was kind of like a little heavy network for the client so instead we we had sent a request to the to the function and the function would then ask for the files itself from our like GraphQL API and then it would get them back and it would ball them up into a zip and download them and it was just a different architecture you know like have the function ask for the files or just give them the files and so like I don't know like what what makes more sense than a worker well when it's at the edge it almost feels like if it just had the files to work with to begin with maybe that's faster than having it have to come all the way back and get the files I don't know you just got to think that stuff out and test it it's not always straight yeah I mean especially for user interactions you definitely want to think about what's the way that I can get this to run where the user is without making that round trip and yeah what does the state look like in that moment yeah it's um it's interesting because for us you know there you have that dichotomy of like we could put more power on the client and we could you know send more code and execute more on the client but then you're overloading the client for simple things maybe they're just there to read you know like Chris said a lot of people come to CodePen just to learn they're not necessarily creating you know and most people kind of come there to read and see what people are creating and learn from them so we don't want to kill that experience we don't want to burden it with a bunch of code that also processes and executes and things like that so we keep I I'm starting to wrap my mind around around the idea that maybe like workers are actually this really good intermediate solution to not overburden the browser with a bunch of code that they might not use but still give you that really extremely fast experience um and I know it's not offline but it's it's it's really highly available it's resilient to downtime because you write them in javascript a lot of these functions they could be a service worker but then it's like I really want to deal with service workers I mean they're so cool but they're like the they're that's tricky stuff you know we have not gone down that road just yet I feel it almost feels like a worker is like easier and safer it certainly is it's a lot easier on on the mind to understand okay I control this environment yeah I know what I'm getting of it it's a new version of it or as a service worker you gotta like make sure it's de-cached properly yeah yeah I think that control of it is really um uh yeah definitely something that we've heard from customers um many times is they get in this dilemma of do I put this code on the client um and yeah then it's really fast but I lose my control over it and how do I make sure that it's updated and um on the flip side at the origin like you said um if you live in Oregon or Virginia things are um smooth and skippy but um otherwise um yeah for the rest of the world it might not be the greatest experience I think the really interesting thing about the edge is like how close can you get the code to the client without it being literally on the client it's been big I mean these screenshot ideas now you know for the first time for Rach poor Rach in Australia she's our she's our super developer on our team always had a a slow life there you know she's probably used to it in Australia but now now we can have her in mind at every single change we make yeah just club closer to her you know I think that's really beautiful um that um yeah you know I mean when you travel abroad even you realize like oh it's slower here and that's just how most people experience the Internet and I think it's really cool that uh this new generation of applications can be built um to be fast and accessible to everyone right yeah and I think that's one of the game changers about workers that I'm really excited about is for a long time I've thought about well you know we're not charged for lambdas unless we're unless you're executing them so what difference would it make if I deployed them to you know let's say 12 regions and just based on latency did routing and all this you know stuff and that would be better that that would be better but it's more complex for us to manage and the thing about workers is like there's no deploying to 12 regions like even if we could do that and it was we'd still have to churn through make sure that everyone's updated um manage all of a sudden you're managing five data or 12 data centers with VPCs or whatever you know it's like being able to push out to however many points of presence you guys have and not caring lets us just focus on what we're doing and so that is where like you start to see us push more logic out to the edge because of that simplicity it's like that's kind of a key component of it is like it has to be manageable for our brains to be able to continue to understand our own system you know we're a small company we're seven people and so being able to manage that and not get overwhelmed by all the infrastructure and network the the layout of the network is huge I can write these things and I am like not I'm a developer but very very very front end focused on our team and so to know that you know in my dev experience for these workers I'm working on them they're they're perfectly I run the little ring what do you call it wrangler yeah wrangler little fires up a little tester thing it's a url what do you have a tattoo like a little chrome I mean to know that like the code is running in like a super sky chrome is already kind of cool but then you got the dev tools down there and then the code that I'm writing is node so like as a front-end developer who writes javascript this is really comfortable like you know there's there's hardly anything to learn you know it's just like yeah that's that was the beauty of it that there's hardly anything to learn and you can just kind of focus on the job that you're doing that that's really once you get over the misconceptions and misunderstanding like I was just telling you earlier I was really confused about the idea of execution time versus how long this request has to respond and so I was like I remember seeing that I had up to 50 milliseconds so I was like guys seriously I don't my lambdas don't even wake up in 50 milliseconds so I'm just not gonna be I was like I did not understand the technology and then when you realize I think we run over 200 million workers you know executions of workers a month it might be more now and I think the average execution time is like 1.9 milliseconds or something and you just kind of need to experience it to understand that it's a different piece of technology fundamentally it's a different technology what you can do with it is a different technology how you get charged for it is different and so that that was my big barrier to entry it was like okay once I tried you know the screenshot idea and I was like I saw that it worked and I saw the timing on it you realize okay that I can start to see that I can do real work on this worker and so you know we're just kind of getting more invested as time goes but it kind of took getting over that hump for us to be like okay I can see how it goes and like Chris says like we're all almost everyone on the team is now touching the workers I mean if they haven't they all have the skills to do so which is really awesome and as and you kind of like mentally conceptualize that all our traffic goes through Cloudflare anyway so if you want worker to touch a little piece of it then you just can like most of it doesn't all of it goes through Cloudflare but most of it doesn't necessarily touch a worker because it just doesn't need to workers are scoped to a url pattern and but we use it more and more we're like what if on this particular page a worker got involved yeah I know that flew by um so thank you both so much for um joining me it was really great to hear about everything that you're building and your experiences as well yeah awesome yeah thanks thanks for having us really appreciate it