Episode #142: Cloudflare Workers with Michael Hart
June 27, 2022 • 55 minutes
On this episode, Jeremy and Rebecca chat with Michael Hart about what's new with Cloudflare Workers, how to add state with K/V, Durable Objects, R2, and more, how and why WinterCG is defining a new set of Web API standards, maintaining open source, and so much more.
About Michael Hart
A software engineering leader with 20 years of experience growing teams and building distributed systems, from fullstack development to machine learning and big data analytics. He also contributes to open source tools with hundreds of millions of downloads per month, primarily around API integrations, team productivity, and developer optimization for cloud environments. He is currently a Principal Engineer for Cloudflare Workers at Cloudflare.
Hi everyone. I'm Jeremy Daly.Rebecca:
And I am Rebecca Marshburn.Jeremy:
And this is Serverless Chats. Hey, Rebecca, how you doing today?Rebecca:
I am doing really well. I mean, people can't see the video, as we just talked about, but I'm glad that you two can only see this part of my apartment, where I live. Literally everything else, where the shadow touches, I just got back from a five day, back country hiking trip, and I have like, it rained a lot.Jeremy:
Everything laid out everywhere?Rebecca:
Yes. It was in the Olympic peninsula- it's a rainforest, you know, so it rained every day and everything. It was just wet. So I just had to put up like chairs and everything's attached to other things and it's drying out. So, it's been a good last five days and it's good to be back. How are you?
So I'm both sort of sad, but also excited. So I'm sad because this is our last episode before we take our summer break, but I am excited because there are a lot of cool things I think that are gonna be happening this summer. So I'll be very excited to get a little bit of extra time to work on those. My newsletter, I'm actually gonna be offering a paid version of my newsletter, coming out soon. So, hopefully put a little bit more time and energy into certain things. Do a little bit deeper analysis, give some more opinions in there that maybe are not as popular, the opinions that I have on some things might not be as as popular as some other opinions.
So, I do wanna delve into that, but then also lots of cool things happening with Serverless Cloud this summer. Hopefully have a bunch of cool announcements coming from that, soon enough. So anyway, so excited about that. Excited to have the free time, but I will be sad to not have our our weekly chats here. So what do you have going on over the summer?Rebecca:
Well, plenty of things going on over the summer, but I'm very excited about one specific thing. And that thing right now is our guest today. Would you like to introduce him?Jeremy:
I would. So our guest today, we've had him on the show before, a long, long time ago. This was like on Episode 18. So what was that like? 230 years ago? I can't remember. but our guest today is a principal engineer on the Workers team at Cloudflare. He's a former AWS Serverless Hero. Michael Hart is here. Hey Michael. Thank you so much for being here.Michael:
Great to be here. Good to see you guys.Rebecca:
It's good to see you, too. I'm very excited. For people who don't know, Michael was a former Serverless Hero and that is how I met him, as well. So I was an avid listener back in Episode 18, both him and Jeremy, two of my faves,Michael:
Yeah, we were all just Serverless Heroes hanging out. Back in the before times.Jeremy:
In the before times. It was a good time. Well, back then, even back then, I know, Cloudflare Workers was announced, I think in 2017 or something like that. But when it first came out, you know, it was just sort of like cloud front functions. Although CloudFront Functions didn't exist back then, but just this idea of manipulating things at the CDN. I think Fastly, was already a thing at that point too, but, a lot has changed though. Because I'm just writing my newsletter today and all of the serverless database offerings that are out there now, like just so many of them like constantly coming out. And then all these edge networks, all these container scaling platforms. I mean the marketplace and the ecosystem has just exploded.
I mean, even from what was it, it was 2019 or whenever that episode was that you, that I had you on. So I'm curious- a couple things. So at Cloudflare now, you're working on the Workers team. So maybe we should just kind of reset here and talk about that. One, you know, why don't you tell people a little bit about yourself, and then what you're doing at Cloudflare, and then let's get into Workers and sort of how they've evolved.Michael:
Yeah, sure. So, prior to this, I had a nice, six month break, prior to joining Cloudflare. I've been with Cloudflare now for, two months. And prior to that, I was VP of research engineering at Bustle Digital Group, which is a media company, all sort of on serverless. So doing lots of serverless things for them. And that was my role when I was last on on Serverless Chats. I actually should ask and I didn't ask this in our pre-show chat. Have you had anyone describe Workers on Serverless Chats yet? What Workers is?Jeremy:
I don't think we have.Rebecca:
You're the one, Michael.Michael:
So yeah, that's one big difference. The other big difference is it's an edge product, as you mentioned. And so it's running all of this at the edge. Which the advantage of that, of course, is that it's closer to the user's eyeball, as the technical terminology likes to use. So you have the code, your serverless code, running really close to the user's eyeball.
So it spins up fast. The latency is really quick because it's in a data center, you know, we have like 270 data centers or more around the world. So it'll pick the closest data center and be serving the code from there. Like you say, it started off as sort of a way for Cloudflare CDN customers to augment their requests in the same way that I guess Lambda@Edge did, but it did it in a much, I think, a much sort of smoother way and a much more light touch kind of way.
And, yeah, it's got plenty of use cases in that realm. I think, you know, plenty of big customers have used it. Because it essentially allows you to kind of inject anything you want into a request coming into, you know, if you've got Cloud Flare sitting in front of your entire site, you can intercept any request with a Worker and modify it.
You can, a classic example, during COVID there were some big pharmacies, you know, and things were changing so quickly then. You know, there were people trying to book vaccinations and things like that. And they were constantly having to put up notifications or whatever. And it was a really easy way for them to just inject HTML into the page, right? Because you've got access to the full streaming HTML in and out from a worker. And so you can just modify it on the fly. You can, so it was really easy for them to say, add a banner to every single page on their site, regardless of what backend technology they were using. They didn't need to, you know, fudge around with, 'okay, this part of the site's using PHP, this part of the site's using Java or whatever. You can just modify it on the fly. So that's kind of where Workers started. But then, of course, if you, if you think about a world where you don't have an origin, so you don't have anything behind the Worker, the Worker itself can deliver HTML, you know, to the eyeball, to the user.
So then you have a world where you can create full apps and full sites just from Workers.Jeremy:
Right. And that's one of those things where, when it first started, it was very much so like manipulate the stream that that's coming back. And there's all kinds, like you said, great use cases for that. I mean, there's still great use cases for that. Especially like the ability to route things.
I mean, just one of the things we used Cloudflare Workers a while back just to do basically redirects to different origins, but use the same domain name, right? So it's just totally cool that you can do that, essentially, you route a different origin and pulls the data back and it all loads on the same URL or the same domain name.
And then you just, you know, can change whatever the path is and stuff. And then route that correctly. Which is very cool to do, especially if you're combining multiple technologies, like you said. But since then, we've now sort of gotten to a point with Workers and of course there's Pages and a whole bunch of other products that Cloudflare has. But we've now kind of gotten to the point where it's like, it's an edge without an origin, like you said, right? Where you can actually now build the full apps there. So tell us a little bit more about what is the breadth of the full apps now that you can build? Like, I don't to say the limitations, but...Michael:
Right. I'll try and remember all of the things. So it's come leaps and bounds. I mean, I remember when I was at Bustle and we used Workers at the time to build an originless-style system. We used it to replace our front end which was a Preact server side rendering app.
So we kind of got that all running in a Worker and it was, at the time, talking to a Lambda backend that was a GraphQL server. And so that was years ago. Since, and at the time we couldn't really use it. It wasn't quite ready. I would say, you know, four odd years ago for that use case. Since then, it's sort of come leaps and bounds. It's now got a lot of those production features that you need, like logging and the ability to kind of debug this sort of stuff in production which is what we need at the time. And now it also has a whole bunch of other features like you know, stateful data sort of features.
So that's one big difference. I guess, if you don't have an origin, and you're trying to create, or you're trying to return HTML, or maybe you're trying to return an API response or something like that, it's like, well, what are you doing that on the basis of? Are you talking to something on the back end?
And you could at the time, and you still can. Cloudflare can talk to any HTTP compatible database. Like it could talk to DynamoDB, it could talk to anything like that. But Cloudflare, since then, has added a whole bunch of features. The first of which was Cloudflare KV, which is a key value store, essentially an eventually consistent key value store.
But you would have to bundle it in with your app. And if you wanted to change it, then that would mean a redeploy which is super quick on Cloudflare Workers, but still, you know, annoying. So Workers KV came out and that opened up that use case of where you wanted data at the edge and you wanted your Workers to be able to access this data.
And it's for use cases, I guess, where you're writing relatively rarely but reading heavily, and you want low latency. I guess prior to Cloudflare Pages coming along, you might have used it for a, you know, as a CMS or something like that. You know, that's a perfect use case for it.
I mean, you still could use it that way actually. But perhaps Cloudflare Pages, which is the sort of Jam Stack offering might be better for that these days. But yeah. So that's Workers KV.Rebecca:
So, Michael you, we have this list of things that we wanna ask you about in terms of Cloudflare and Cloudflare Workers. And the first on the list was, tell us about Workers KV and then, you know, we had a couple of questions around it, but then you went into it.
It was like, 'what can you do with that?' And it's like, 'oh, he just answered that. He also just answered that. Actually, he answered that.' But we have a few other things on this list, right? We have R2, we have D1, SQLite. So maybe you could go into a couple of those and describe those as well before Durable Objects?Michael:
For sure. Durable Objects.Rebecca:
Durable Objects, That's right. Yeah.Michael:
That's probably the next one. I'll go kind of chronologically with, like, when Cloudflare released them. So KV is great for scenarios where you're happy with eventual consistency and you want low latency. But if you want something that's strongly consistent, it's not a great option because you might write, you know, I guess if you think about it, these values are being propagated to every kind of edge node, all 270 nodes.
It can, when you write a value, it can take, you know, seconds for that to update all around the world. And during that time, you're kind of, you're in this inconsistent state. So if you wanted to write a value, read a value, write a value, read a value- it's not a great solution for that. Durable Objects came out and it solved that problem. And also another problem of, kind of coordination. So it's sort of the opposite where it's a singleton data object that is living just in one place. And you can use it to coordinate things. That's one aspect, I guess, of a fully stateless system at the edge is it can be very difficult to coordinate who's talking to what. And this comes to light when you're trying to do something with web sockets, like a chat room or something like that. You kind of need a central place for those web sockets to be communicating in and out of for consistency and for coordination reasons. So Durable Objects came along and it kind of solved that problem.
It's strongly consistent. And it uses a sort of object model. So you create this durable object and it lives in a particular region and all the writes go to that one object. And it's sort of single thread. It makes a lot of those difficult consistency problems quite easy because it's single threaded.
So you can read to it and write from it and know that your reads and writes are consistent. And that sort of thing. The one thing that it doesn't have is that it's not distributed all around the world. It's just sort of living in the one place. Yeah, so that's, that's essentially what Durable Objects are for.
And this idea of coordination, because there's the one object. Well, you can now use that to coordinate multiple Workers trying to do a whole bunch of things. Chatroom's a perfect example. I think Cloudflare built a queuing system. You know, like, like if you want tickets to an event or something like that, and they're all gonna be released at 11:30 then, you know, your site is gonna get slammed. And you kind of wanna stick people in a queue so that first come, first serve. Durable Objects is a great way to achieve that sort of scenario. So that was Durable Objects. And that works really well. And then recently, Cloudflare announced another product called R2, which is essentially Cloudflare's S3 offering.
So it's buckets. It's sort of bucket storage; storage for large objects. And it's essentially the same as S3. It's just one thing that's great about Cloudflare is, it has very low or zero egress fees. So egress is the kind of fancy term for outgoing bandwidth., right?Jeremy:
Which, AWS will getcha.
So if we know that this Worker is gonna be talking with this object, then obviously we can kind of ensure the shortest path to or from it. There's another, model called Service Bindings, which is a way of a Worker to essentially have a binding to another Worker.
So this is a great way to split up your apps as they become bigger and bigger. And anyone, who's kind of dealt with a Lambda app at a certain stage knows this problem well, of trying to divide your app up into different parts. But maybe still from a monorepo. And Cloudflare has this concept of service bindings where you can just talk to another Worker as from a bound variable.
Behind the scenes, we can do some really cool optimizations with that, where we can actually run them potentially in the same isolate. And then we pass on those cost savings to users as well. So, whereas a Lambda you'll always be in completely separate, kind of, containers. In this model, if we know that it's the same user and we can run things together and let's say one Worker is waiting on a response from another Worker, then we won't charge you for the time that you're waiting.
Whereas, you know, I guess in the equivalent sort of AWS style thing, if you've got API Gateway and Lambda where you're paying for the time that API Gateway is waiting for Lambda to come back. That's one thing, actually, that I've kind of come to realize, being at Cloudflare, is that the Workers product and Cloudflare as a whole is a little bit more of a seamless experience, I would say. Which, you know, some people might view as a good thing or a bad thing. But for me, it's a little bit like if you took, I don't know, WAF and Lambda@Edge and CloudFront and API Gateway and Lambda and rolled them all into one product and then just had like different check boxes for which kind of feature you wanted.
And that has, you know, big advantages when it comes to things like, I don't know, a streaming request or whatever. You just can't deal with that in Lambda. You can't. The request stops at API Gateway and then forwards to Lambda and comes back. And there are some advantages to that model, but overall, I think, especially for HTTP sort of models, it's nice to just have the smoothness of requests kind of flowing in and out of this kind of one big system. And then you can have your DDoS protection. You can have your security stuff, you can just kind of flick that on without needing to bolt on a whole other service and figure out how to connect it to your pieces.Rebecca:
It's like the express train in the New York subway, you know? It doesn't have to make every stop.Michael:
like, you're getting there.Jeremy:
Something that's reallyMichael:
You don't have to change from train to train. Yeah.Jeremy:
Something that's interesting, I think, about that too, is there's always been this big thing about the two pizza team and everything's a separate microservice at AWS and so forth. And not that that is necessarily a bad model because they can work very fast in isolation and whatever. But then you always get that problem like, well, now we have to assemble these things, put them together. So you have a lot of teams talking to different teams and so forth. And I always remember, I actually it was like a Honda Accord or something like that, that I was looking at years and years and years ago. And I remember that I get in to test drive this thing. And there's the screen that has the navigation and a couple different features on the navigation screen. And then below that there was a touchscreen that was just for the audio controls. And I'm pretty sure that there were two different teams that designed these two things, and then they're like, 'alright, now we have to fit them in the car.' They're like, 'Yeah, but this doesn't work together.' So they're literally two systems to control. It made no sense. I mean, now they're all integrated cuz somebody figured that out. But that is how I feel about a lot of the Lambda stuff. Like you can't do streaming HTTP with Lambda, right? Because you can't route that through the API gateway the same way, then you have the payload limits and you have all these other things that run into that. And then they introduce the URLs, the Lambda URLs, but then the function URLs, you don't have any control over, you know, throttling or some of these other things, right?
So there's a whole bunch of stuff that I think they're trying to figure out workarounds at this point to make things work, as opposed to, I think, where Cloudflare sort of looked at it very much so as a unified system.Michael:
Right. Yeah. It's just kind of extending the existing system that's there. And what's been amazing actually is to see how much dog fooding is done in Cloudflare. I'm sure this is true of many big companies, I'm sure AWS does this as well, but I'm not sure that AWS, you know, writes all their new services on Lambda,whereas Cloudflare is like using Workers for everything. Like everything now is written on Workers, which is great and an awesome sort of testament to how much we kind of believe in it. And I must admit, back in the day when it first launched, I was like, okay, this is Cloudflare Workers is really cool.
But are they really gonna be putting all the effort behind this? Is this a product that I can kind of trust or is it just a toy that they're putting out there? And it's been amazing over the years to be like, 'Oh, okay, no. They're really serious about this.' It's yeah, it's really becoming a thing.
And I guess internally, you know, it's just, it's such an easy way internally to create new products using Workers compared with some of the other ways that you might have to write, you know, native modules or whatever for the systems that exist. So, yeah, internally the teams have loved it as well.Jeremy:
I am reading an article right now that said Cloudflare is rebuilding its CDN service on its Workers serverless API, something called Project Flame.Michael:
Oh, cool. Yes.Jeremy:
Don't know if you know anything about this?Michael:
I do. I do. That's cool to see that it's now public. Yes. That's essentially what it is. That's it, in a nutshell. We're kind of rewriting as much of the front end side of the, I guess the entire, kind of, API gateway. The entire ,proxy front end proxy, in Project Flame.Rebecca:
You could tell that Jeremy was actually reading that article right now cuz his eyes got really big as he's focusing on these words. Well, let's talk about that, then a little bit.Michael:
Is that something that was announced for Cloudflare One or?Rebecca:
I think so. There's a lot going on.Michael:
I was gonna say, yeah, one cool thing at Cloudflare is they have so many of these innovation weeks. And a lot of these things have kind of been announced at various innovation weeks. The most recent one was the platform week where a whole bunch of things were announced. And that actually, that was something that you mentioned, Rebecca, that I haven't chatted about yet, which is D1, which is the data storage.Jeremy:
Why wasn't it D2? So you had R2, D2. Is there a reason?Michael:
Let's just say maybe watch this space.Jeremy:
There will be a D2 eventually. We'll see what happens.Michael:
I have said nothing. D1 is essentially SQLite at the edge. Strongly consistent, built on the same sort of primitives as Durable Objects. But you know, with a kind of familiar SQL interface that everyone knows. Not that everyone knows. That many people know. That there's plenty of resources out there for and I think it'll be great for, you know, there's this huge long tail of companies and, you know, eCommerce sites and things like that out there. I think that they don't need Aurora database. They don't even need an RDS database. You know, that's like, that's just too much. 50 bucks a month for the amount of data that they're storing. Now they could, of course use, use DynamoDB or Mongo DB or some sort of NoSQL offering.
And I still think that's a good option, but it does for many people. And especially I think for like, consultancies out there and things like that, it means learning another data model. Whereas the advantage of SQL is it's not, you know, mySQL and Postgres aren't exactly the same, of course. But there is a very common understanding, very common similarities with the dialects of SQL that they talk and just the general concepts of a relational database.
And so what D1 is, is a way for people to be able to write their sort of storage using SQL and have it available at the edge in their Workers. So it's, yeah, it's great. It should be really interesting. There are plenty of really interesting use cases. I mean, it's very early stages. It's just kind of in a private beta at the moment. But there are very interesting places that it could go once you kind of have that model. And SQLite, you know, it's just super cool. It's a very lightweight engine and it's really stood the test of time.
And being used in plenty of places. It's a perfect example, I think, a perfect use case for someone who has like an Ecommerce site or something like that, where you know, they wanna store their products, they wanna store their customers, they want to look them up, they wanna do joins. They want to be able to display that data. They want to be able to write it. They don't want to think too much about stuff like eventual consistency and stuff like that.Rebecca:
You talked about internal dog fooding and how impressed you were with how much you all do that and how you build everything on Workers. And I think there's something special that happens there, right? When you are that, let's say, obsessed of doing internal dog fooding. That also means that if you're the developers, you're also improving your own experience before you're putting it out into the world, or you're understanding where the experience, where the gaps are, what fails, what feels good, what feels bad? So let's talk a little bit about the developer experience and I think you have something called, is it Wrangler?Michael:
And how does that make it?Jeremy:
Not the jeans.Rebecca:
But maybe those, too. How do a great pair of fitting jeans? Um, no. How does Wrangler make it easier to build with Workers? Like how does that affect the developer experience?Michael:
Yeah, I guess so Wrangler is the, sort of, the CLI experience, the console experience for building Workers. And it's sort of fast becoming, or, you could say is now the primary way to sort of quickly spin up and iterate on on a Worker's app. So I guess, a pretty good analogy in a way would be CloudFormation for those in the AWS world. You know, you can specify, it is infrastructure as a service in that sense, in that you can specify all the parts of your app that you need and then run Wrangler and it will push them all out there. And, it's where you would define, you know, some of the things I was talking about before, like the bindings where you would define whether you're binding to KV or whether you're binding to two or another, a service binding or something like that.
Yeah, that's essentially what Wrangler is. It's also used for Cloudflare Pages. And internally, yeah, it's interesting. You chat about the developer experience, cuz it's interesting for me now being on that side where, you know, you have other teams essentially, that, you know, we're supporting now. And in our internal chats, people are like, 'oh, hey, how do I do this with Workers?' 'Can you let me know, how do I wanna spin this thing up?' Or I wanna spin that thing up. And it's like, 'Oh, cool. That's someone internal.' That's exactly the same sort of thing.
And so, yeah, then that drives, obviously drives the developer experience and drives the way that we make tools like Wrangler better. One cool thing, actually, I was thinking about this the other day about Wrangler that I like, that I'm not sure I've seen in any other sort of infrastructure as a code style config is for Durable Objects.
When you want to say, add a new durable object or modify it, maybe you wanna rename it or that sort of thing- you'll do a migration. And you declare these migrations in your Wrangler file. So you'll sort of be like, 'okay, here's version one of the Durable Object. Version two you know, is a rename action. I want you to rename from this to this, version three. And they just sort of sit there in your config file and, you know, in time, kind of, grow. But it's quite cool to then have, you know, your migrations kind of listed there with your config. You can kind of see where things have gone and where they're at currently. And it's a good way of declaratively sort of saying, this is the state of our data, this is what our schema looks like at the moment. Yeah, that was something I noticed the other day that I'd never seen before.Jeremy:
So another thing about developer experience too, is also familiarity, right? When you have to learn something new, I mean, you mentioned NoSQL or data modeling and NoSQL. Like, it is just hard. I mean, there's a lot of different things you have to think about. Of course, then you're limited in terms of how you can query stuff or whatever. But just thinking about familiarity for a developer.
And they're used to running node modules in order to do a lot of things. So there's support for third party modules. You can import different things. I think you can make, you know, fetch calls and all that kind of stuff. So you can interact with APIs and other things external to your Workers. But are there certain types of modules that you can't use because of the model?Michael:
So I guess it's kind of become the defacto, of course, in a way. And that's where NPM started. And so most NPM modules are written for node. Although now that I say that, that might not be true anymore because people have been using NPM for browser modules for a very long time, actually, you know, just as a way, cuz there was no other module system for browser modules.
That's something that is then part of an API standard. And in Fetch's case, it's a web standard, you know, it kind of replaced XML HTTP, you know, the original Ajax kind of way of fetching things. Cloudflare is built as much as possible to be compatible with web APIs, as opposed to node, which was written at a time when those things didn't really exist.
So node wrote its own HTTP client, completely from scratch because there was no real HTTP client or way of making HTTP calls aside from the very clunky way that browsers did it at the time. So node kind of existed at a time when a lot of these APIs weren't being worked on in browserland.
Hence the name Deno.Jeremy:
If I could do it again...Michael:
Yes, essentially, if I could do it again, this is how I'd do it. And it's taken a very similar path of trying to be web API standard compatible. And there are huge advantages of course, to that. There's eventually anyway, because people will know these APIs and they'll be standardized. You won't be kind of context switching between the browser and the server side. But there are some things that you just can't do in the browser that, maybe, if it was only left up to browsers, they would never implement APIs for at all. You know, a classic example might be accessing the file system or something like that, right? You don't ever wanna be able to do that from the browser, but maybe you do wanna do that from the server side. And Deno certainly has a way of doing this in its own Deno name space. So they've had to create their own API for it. But what Cloudflare and Deno and a bunch of others have been working towards is this group called the Winter CG group that was announced recently during our platform week, which stands for Web Interoperable Run Times Community Group.
As I read that out, cuz I'm not gonna remember it. But this is a working group essentially to establish APIs for non browser use cases, but still to be standardized. And I guess, standardized in the same flavor as the web APIs are. So to use the same, you know, where possible, use the same stream APIs and that sort of thing,. But potentially for use cases outside of what the browser would be for.
So that's really exciting because that should enable a bit more standardization in that space and getting back to the original question of so what can and what can't you run in Workers? There are definitely, you know, developers out there that come and they try and create a Worker and they pull in a node module. You know, maybe it's using nodes HTTP or nodes crypto, or nodes Fs module. And those things just aren't available in a Worker. Now, in time people have been writing, especially because node did introduce the Fetch and start supporting the Fetch API. So, in time, people have been kind of updating their NPM modules to support some of these new APIs.
Which would be nice. And it's probably gonna be easier to create standards now that IE11 is dead.Michael:
Yeah. That's certainly true.Jeremy:
The bane of my existence was IE6 for so long. When I was just doing web development.Michael:
Right. So, well, so this Winter CG group. It's super interesting. I mean, web standards is just something that once, you know, what was it? It was the gecko first and then it became the Chrome, the I forget what it was called, but?Michael:
You can probably just look at any browser user agent and figure out the order of like, how it started.Jeremy:
But everything sort of started standardizing around certain things. And I think that was just great because then it allows people to build more things for more systems and more compatibility across stuff. And I think that that's something that I'd love to talk to you a little bit about too, is just open source in general. Cuz you've done a ton of open source projects, including some really, really popular ones like Dynalite and Lambci. I don't know if you ever really did much more with Yumda, but I remember we talked about Yumda way back then. Which was some pretty cool stuff that you were doing with that. And you actually wrote, and I might get this wrong, but I'm pretty sure you wrote the original, like local run time for Lambda functions that the Sam team eventually used. That might be a sore object. So we can you know, put that aside. But I'm just curious, like with all the stuff that you've done, and I know you took a little bit of time off and like you said, you know, when you, you were away for a while taking some time, you didn't work a lot on those those open source projects. I'm the same exact way. I've been so busy. And it's just like, trying to get back to those projects and get my head back into the space where I was working, the reason why I created 'em in the first place, and some of these other things. I've moved on from some of those technologies too. So it's really, really hard, but I'm just curious to get your thoughts on just being an open source maintainer and your perspective around that. Like, what what's that, what's that been like for you?Michael:
Yeah. It's been really interesting. I'm sure you could have like hours long chats with people about this. You guys could be my therapists. Working on open source and, you'll see, I think this is true for many people who have done it, there are so many things that are so gratifying about it.
It's so wonderful to be able to, sort of, contribute to the community and the barrier to entry is so low now. Like, it's very funny to think back to a time when open source wasn't the norm. Like, early in our careers, that was the case when, if you wanted, even if you just wanted a library or something, it could be really difficult to get a software library. You need to pay for a license or even if it wasn't pay for a license, the licensing was sort of a big concern.
And it's fascinating to see since then, just how much open source has taken over the bulk of so much of the plumbing, of software that's built today. And I guess it probably, there's heaps of reasons for it, I'm sure. Part of it is, it just does feel really good to build something and put it out there, you know? And, just the joy of, I think for many people who are in the software world, you get joy out of building things. And that's sort of why you stay in the business and why you keep doing it, is you just enjoy creating software. And you enjoy scratching itches.
You know, a lot of open source software is created just from scratching an itch.There was this thing. It didn't quite do what I wanted. I'm gonna write it, but there's no, you know, what's the benefit in me kind of keeping this just to myself? Or maybe just to my company, you know, I guess things get a little bit complicated there. But certainly if you're just writing something to solve your own sort of developer pain. I think a lot of the time when it is, 'oh, I'm writing this for something that I'm doing at my job,' there's just the question of, is this core IP for my company or not? You know, is this core intellectual property? If not, I think, these days companies are just a lot more open to, 'well, yeah, that's fine.; You know, just release it as a library or as a little helping thing. And people, I think, have seen the benefit of. the branding that comes along with that. Like, 'Hey wow, this company built this particular thing or this company built this particular thing.' Actually, yeah, I'm thinking even today, like we write a bunch of Go code at Cloudflare and there's a particular light, and we use Kafka, which is a messaging service. And there's a particular Kafka client out there, Sarama, written by the Shopify people.
And, you know, we just use that client. But then Shopify's a customer of Cloudflare as well, you know? It's like we're a customer of their code. They're a customer of us. There's lots of cool sharing and I think there's a real community aspect to it that is great. But having said all that lovely stuff, people are people, you know? And we know this from social media, we know this from anything. I guess, once you just kind of, it's very easy to forget when you're using software and you're getting frustrated with it and it's buggy and you're trying to do something in your day job and you can't get past this point because maybe the documentation's bad or maybe it is actually buggy, or maybe there's just something wrong with it.
That's super frustrating. And you're like, 'Oh God damnit, this thing doesn't work'. And you know, in that moment, it's very easy just to go and leave a snarky comment or a GitHub issue or something, and just be like 'This thing's broken it doesn't work.' And I think, plenty of people, of course, they step back and I think by and large, actually the open source community is great in the way that people interact and write issues generally is actually pretty nice and pretty considered.
But it can take a toll after a while, I guess. If you just feel like, 'Oh, I created this thing and the creation was really fun. But now I'm having to maintain it.' Now, yeah, there's this really weird edge case that this person has and how much time is it gonna take me to fix that thing? It's probably gonna take hours and that's not gonna be like joyful hours for me. So what am I actually getting out of this? You know, and there are a bunch of things there's, I guess there's a bit of pride. There's a bit of, well, I feel like I made a promise actually to the community, when I put this out there. I kind of, by putting this out there, I kind of made a promise. 'Hey, people use it.' Even if I didn't say use it. And a lot of time people put stuff out there and they're like, 'Hey, don't use this. I'm just putting it out there. Please don't use it in production.' Then, you know, a few weeks later, 10,000 sites are using it. But yeah, I think there's that. There's this element of, 'Well, I kind of promised people that they could use this thing and so, yeah, with great power comes with great responsibility. And there's a certain responsibility to keeping your open source libraries up to date. If you want people to be using them. And vice versa. If you're using an open source library, you have to keep that in mind that, you know, is this person gonna be keeping it up to date? And if not, what options are there, will you fork it yourself and look after your own fork of it? Et cetera, et cetera.Rebecca:
I was just gonna say, so end of this open source question, I have multiple sub bullets and these sub bullets, it's something that you've touched on, I think, in the last couple minutes. You've touched on each of them and one is ensuring quality and consistency. Are there tips and tricks to doing that?
Is there something that you should know going in as to someone who's gonna be an open source creator? What do I need to know? Do I need to schedule all my time? Does this have to end up being like on the calendar? Like how do I need to even allow myself the time and space to, to actually maintain this?
But then I think we can set that bullet aside for a second, because I think the two other bullets that I have- one is, you know, you called it scratching an itch, or maybe solving a point in time problem. And so it's this bullet around ensuring longevity. So not only how could we do that, but like, should we even try? Or at some point, is it like, 'Hey, I'm gonna let this self-destruct over the next six months to 12 months to two years to six years' or whatever that timeframe is. And maybe it's okay. Like maybe it's okay. That it goes into like obsoletion over time.Michael:
And then the last bullet it was about then how, if someone is going to use a library, right? Like what's the best way for them to test the usefulness or reliability or longevity of one of those projects. Like what would you say? Like, Hey, obviously it's, you know, some people are very clear and they're like, 'don't use it in production.' And then later, like, a month later it's 10,000, but like, yeah, are there red flags that one person should look out for to be like, okay?Michael:
Yeah. Yeah. All very interesting questions. I think as you were talking, I was realizing that, of course, open source runs a huge gamut, right? There's there's people that write libraries and little tools, you know, like Jeremy or myself. And then there's huge projects like Kubernetes or like, these massive projects- Chrome, you know. Like just huge projects run by teams of people at a company.
Now that sometimes means of course, reinventing the wheel a little bit. Or, you know, maybe copying and pasting and attributing some MITor BSD licensed code or something like that. And, so yes, there's duplication of effort there. And potentially if the thing that you've copied and pasted has security issues or whatever, then you are not gonna get the benefit of someone else, you know, updating that.
But for the most part, the sorts of code that I would do that for were very sort of small one liners, very small functions anyway. Your very, very small data structure or something like that. I haven't run into any security issues with that stuff, but I could imagine that it could happen.But the advantage of that of course, is that then when people install your thing, and 6 months down the track, if you haven't made any changes to it. Well, no changes are made to their code base either. You know, the problem can often arise when you install a library. The library itself hasn't updated, but some of its sub dependencies have, and they get updated and then maybe something breaks because, you know, there's just, at a certain point, it gets so far removed from the original library or the original utility or whatever, that they weren't even aware that this sub library was doing this thing that's now broken.Jeremy:
It just gets heavier.
Yeah. So that would be one piece of advice. And I'm sure I could think of many examples where that's not a good idea. But generally I feel like reducing the number of dependencies that you have is a good rule of thumb, if you're writing open source. And if you're picking an open source library, especially picking one that has fewer dependencies, I feel generally as a very general. 'you're gonna end up with less headache down the track 'and less hair pulling out, less issues trying to debug it, less jumping around, even just jumping around the file system, trying to figure out, 'wait, where is this coming from?' Which particular of these hundred dependencies is this behavior that I'm seeing coming from?
Yeah, so I think that's, that's a good rule of thumb and a nice sort of design pattern to keep in mind.
Well, Michael, I hate to cut you off, but we're out of time. And I think we're gonna have to have you back on just to have an episode about open source, because I got a million things that I'd love to talk to you about with this. Especially things like, you always, like, people leave comments and they're like, 'Oh, this doesn't work, whatever.' Or 'I need that to support this.; And you're like, 'Okay, well just, you know, create a PR.' If you've got the time, then you create the PR. And then you look at the PR and you're like, all right, there's no tests. It's like, you know, so then you're like, 'Well, I can't just merge this in and break 20,000 people who have downloaded this thing.'Michael:
I know it's like they did the right thing, but they didn't quite do it a hundred percent, right?Jeremy:
Right. And then you rewrite it. And you're like, 'I hate this. Why is this so tough?' Anyways, open source is amazing and scary and terrible and also amazing at the same time.Michael:
Awesome. Well, we will look out for that. So Michael, thank you so much for being here and sharing all of this stuff. Like I said, I think we're gonna have to have you back for an open source conversation, but if people wanna find out more about you or Cloudflare Workers and all that stuff, what is the best way to do that?Michael:
Google. Google Cloudflare Workers. But I should say Discord’s one of the newer ways that we're supporting people. And there's awesome conversations there. I'm finding it so much better than any of the other sort of support forums or just general chat experiences.
And it's great. It's great to see the community supporting each other as well as, you know, there are plenty of Cloudflare people on there to answer questions as well. So yeah, check out our Discord.Rebecca:
And if you want to learn more about Michael specifically, you can find him on Twitter @hichaelmart, which is my favorite Twitter handle. GitHub MHart. Medium HichaelMart again. You could probably just Google him and find out all sorts of things as well. We're gonna put all this in the show notes, Michael. Usually I let you give all those alias and handles, but I'm gonna roll 'em out for you.Michael:
You knew them, you knew them.Rebecca:
I knew them. I knew them. Of course, I know them. That's part of my job. I actually knew them by heart. I've committed them to my heart years ago. But Michael, thank you for being our final guest before we head out for the summer.
Thank you to all of our listeners who have spent time with us and more importantly, who have spent time with our guests. And I hope everyone has a really wonderful summer. DM us. DM Jeremy or myself or Michael. Cuz now you know all of his handles.Michael:
Yeah, guys. That was great. That was very fun. And have a great summer.Jeremy:
All right, thank you.