💻 What Launched Today - Thursday, May 18

Hello, everyone. I am Dawn Parzych. I am the Director of Product Marketing for the Developer Platform.

We're in the final stretch of Developer Week. It is Thursday and I'm joined by a few of our blog authors this week or today.

They're going to share some information about what it is that they announced this week.

First, I'd love for everyone to introduce themselves.

Tanushree, we'll start with you. Hi, everyone.

My name is Tanushree. I'm Product Manager at Cloudflare. I've been at Cloudflare almost two years now and I work on our Developer Platform.

I work on the Workers Team.

Yeah, I'm really excited to share what we've announced today with you.

Great. Richard. Hey, there. I'm Richard Boulton. I'm an Engineering Manager at Cloudflare.

I've been here for the last five years working on various software performance and security products and how our network architecture works at the application level.

So lots of fun things to talk about. Great. And last but not least, Ricky.

Yeah. Hey, everyone. I'm the newbie. I've been here a little less than two months.

I am Ricky Robinette. I lead up our developer relations and community work here at Cloudflare.

And Ricky, you were thrown like right into the fire, like six weeks.

We're doing an innovation week and like, can you help us write five, six blogs?

I think it was. So thank you so much for doing that. You've done a lot around AI this week and your announcement today again has those AI tinges to it.

Can you talk a little bit about the Lang chain announcement? Yes, absolutely.

So yeah, I'm a developer and I feel like, you know, at least in the circles I run in, in developers, we're all like playing with all the new AI tools.

It feels like there's something new every week coming out.

And so that is like all my developer friends and I are talking about right now, truthfully.

And so I was very stoked that Lang chain really support for workers and was able to do a post showing how to use that.

If you haven't used Lang chain before, it's a framework for building with language models.

So I like to think like in the same way that Django makes building web apps really easy for Python, Lang chain makes building on language models really easy as well.

And so I was able to put together a little sample that pulls from Wikipedia and lets you ask questions about that Wikipedia article.

And the thing that's interesting to me about this as a developer is like the first time I used a large language model, it was really cool.

And we say it knows everything, but it doesn't know like the things we have that are like not on the Internet or personal.

And so one of the powerful things about Lang chain is called document loaders.

So it lets you load in any content and use a large language model with it.

So, you know, you could load up your emails and then use a chat GPT or open AI with it.

And so that is essentially what the blog post does. And it's a lot of fun seeing what you can pull in and what you can talk to.

So you can string together a bunch of different models and sites and have these full-on conversations and pull all these things through a coordinated interface.

Yes.

Yes, exactly. Very cool. Given this, it's like a great tutorial. It's like what I'm calling it, like walks you through step-by-step how to do that.

What are some of the ways that you see people building applications using this technology with workers in Lang chain?

Yeah, it's cool. I actually had a friend who did something yesterday that I thought was really interesting, which was Lang chain has functionality where you can load a Google drive folder in, and then anything that happens in that Google drive folder, you can interact with.

So you don't have to like tell it new things.

And so it was showing how like if you're a company that uses, you know, Google drive for things, you can create a folder and say anything that we put in here is going to be used by our Lang chain application and you can interact with it.

And I thought that was really clever. Also Lang chain just launched agents.

So I suspect the next thing I'm going to do is with this and what agents are, is there these little processes that you can kick off that you use language to tell them what to do and they figure out how to do it.

So you could say like, Hey, I want to like pull like the NBA playoff scores from this year and like, you know, be able to have a conversation with a language model about those scores.

And agents will then go and they will figure out like, okay, I need to pull from Google and get the playoff scores.

And then I need to put those into like a vector database.

And then I need to do like a Q&A with a large language model on them.

And so it sounds very like magical to me. So I'm super excited to see how it works.

I love magic. It's great. So to industry is Ricky was talking about like pulling information in making things available through other models.

I see some parallels between that and workers for platform, which is where your announcements are because it's providing ways that people that are building on a platform can do other things easily.

So can you share a little bit about the anniversary announcement of workers for platform?

Yeah, workers for platform turns one years old.

We actually released the announcement post this almost exactly to the date this time last year.

So it's really awesome that we get to kind of do a whole like year in review recap.

Let's see what users are building. And actually most recently, especially in the past couple of weeks, I've talked to some customers that are really doing an AI push with workers for platforms too.

So happy to talk a little bit more about that as well.

But just to start, it's a new product. You may be unfamiliar if you're watching and you're tuning in this week.

Workers for platforms is our product to extend workers out to platforms, out to SaaS businesses that want to then offer serverless functions for their end users.

So two good examples that I highlighted in the blog post, and these are customers we've been working very closely with, are Shopify.

Everybody knows Shopify, big e-commerce giant, and then as well as GraphBase.

And GraphBase is a startup. They actually joined our startup program, I believe last year, or maybe it was the end of the year before that.

They're building completely on workers, and then they also have a workers for platforms component to their product as well.

So it's been really awesome to work with these customers, just starting by identifying their pain points.

That's why Shopify was some of the early, were a couple of the early customers that we started noticing these needs pop up for, hey, you don't want to just put workers or build workers for your applications, but you want to give your end developers the ability to do the same without having to worry about infrastructure.

I think the best way to understand workers for platforms is sort of a story that we've had internally at Cloudflare.

So prior to workers at Cloudflare, and maybe Richard remembers this, he'd been around in that time zone, but we had customers using our security, our caching products, and they would have very specific requirements.

You want to set a very specific cache rules for request matches, X, Y, Z, but doesn't match this, then cache, otherwise don't.

Similar for our WAF rules.

If you have very specific custom requirements, and back in the day, we used to have engineers and solution engineers at Cloudflare actually go in and program that right into our edge, which is great, solves the problem.

Not very scalable though. It means that there's engineering time being spent on configuring something, there's back and forth with the customer.

So not a great experience overall.

And that was sort of one of the reasons that we conceptualize what is workers today.

So this is the ability for you as a customer to actually program logic right into our edge, self-serve, you don't need to reach out to someone at Cloudflare to do this, do it all yourself.

So that was the pain point that we solved with workers.

And now obviously we're seeing workers boom and you can build full applications, but that was the sort of the initial cusp of why we had a serverless functions offering at Cloudflare.

But, and then in talking to Shopify, they had similar concerns, they host storefronts, but their customers had very custom needs that they wanted to build for.

And it was either an option where Shopify would say, figure out your own hosting.

And then you as a developer have to go down the route of figuring out what the best platform is, what works with Shopify, and you're sort of steered off the track of what you're actually trying to do.

So Shopify saw this need, they wanted to integrate their own hosting for custom storefronts.

And that's why they use workers for platforms behind the scenes.

So you can see the parallels that are being drawn from multiple of our customers.

So yeah, it's been an awesome journey working with these customers. They don't need to worry about some of the infrastructure, any of the networking, any of the security behind the scenes, sort of build your product and go.

It's really the velocities that unlocks product managers, engineering directors, love workers for platforms as it means they can build less bespoke solutions and can sort of build platforms at scale to their customers' needs.

So along with sort of just a recap of here's what the last year held in store for us, we've also announced a few new features for our workers for platforms customers.

It has been pretty highly requested.

So one of the benefits with workers for platforms is you as a direct customer, so a Shopify or a GraphBase, are able to run a worker before any of your user's customer code is called.

And this is really powerful because it gives you visibility over the request coming in.

You can run any custom logic before and then program logic to call your end user workers.

But the other piece to that that customers also wanted is visibility into requests that are going out from their customer's code.

So they want to understand what hosts are users fetching, what backends are they using for security reasons, also just for general, like something like billing, for example, like depending on the number of sub requests your customers are doing, maybe you want to then be able to structure a billing model around that because that's additional costs for you.

So just getting that extra level of visibility.

So that's something that we're calling outbound workers.

The way that it works is you have the worker that Shopify writes, you have the worker that your users writes, and this outbound worker that kind of sits in the middle between the cloud player infrastructure and then the public Internet.

It's a really, really powerful building block for customers to use. One other use case I've heard for it is sometimes your users want to talk to your own APIs, but then they have to handle things like authentication.

But if you know who the user is, if you know what the script name is, maybe you're able to auto inject that instead of having your users have to worry about some of the like tokens or API tokens there.

So that's another cool use case we've heard. I'm sure there's a ton more that will come up as users start using it.

My favorite part is kind of unleashing and then seeing what people build.

So that's one. Another one that we've come out with is a feature called custom limits.

So think about it. You're a platforms customer.

You want to, just like on Cloudflare, we have our workers free, paid, enterprise tiers.

You want to create your own tiered system. So with custom limits, we let you set custom CPU time and subrequest limits for your users' workers to then kind of shape your own business model.

And also another facet there is controlling your costs.

We understand you're building on us. You want to have some levers to be able to control.

Workers are very powerful, and you may not want to give that to all of your users.

So that's an exciting feature. We've gotten lots of requests for that.

And then the last thing I'll talk about is a feature we have called tail workers.

So if you use workers, you are probably familiar with Wrangler tail or a log from the dashboard.

That's been very, very useful for developers to be able to go in, do some quick debugging, understand what's going wrong.

It means you don't have to go to a third party and understand the logs. It's right there for you.

And we wanted to deliver a similar experience for our workers for platforms customers.

So we have some workers for platforms customers using tail workers to provide live logging to their end users.

It's realtime. Every time your users' worker gets invoked, you get a log line, and then you can then send it off for processing and to deliver that to your end customers.

Tail workers are also something that we're exposing generally to all workers' customers.

So if you want to have more realtime logging, if there's a destination that LogPush doesn't support, you can then pull that in directly into your worker if there's other formatting you want to do.

So it's really powerful, again, another building block that we're providing to developers.

Great.

Sounds like the last year team has been very, very busy building out all of these features, and it's great to see everybody from startups through larger enterprise organizations taking advantage of that product.

And I'm very excited to see where it goes next.

Richard, I hear some commonalities between what Tanushree was talking about with having to run internal workers as well as provide workers for your customers, because Cloudflare is in that same position, right?

We offer Cloudflare Workers out to the world, but yet we're also building a significant amount internally using workers.

And you, I don't know for sure, but it may have been one of the longest posts of Developer Weekly, which is great.

You gave a really detailed accounting of how we are using workers internally to rebuild some of our systems.

Can you summarize that a little bit for us? So I was disappointed to be short of my target of 5,000 words, but only by a couple of hundred.

So it's, I had great fun writing this because really it's a retrospective of what's been, I've been here for a bit over five years.

The post covers some of the things that have been going on for all of those five years.

And it's really, we have so many products in Cloudflare.

We build products very quickly. It's one of the things which when I'm interviewing people who are looking to come and work at Cloudflare, they talk about how do you ship so fast?

How do you build all these things?

How do you keep track of it? And one of those answers is we have great people working here who find ways to be productive and we find ways to, you haven't got a lot of time, you find the right ways to do things.

But the other thing is that we take advantage of the systems we build.

We get the network effect of all the things that we've done in Cloudflare.

So when we're building a new product now, we're not starting from scratch.

We've got so many pieces to put together to build it with.

And really with the post, what I want to do is go back and look at, well, what have we built that has taken advantage of workers?

And in terms of timescale, that's been a little to start with and more and more at the beginning.

But one of the very interesting things I think about as an engineering manager is how can we have a high velocity?

How can we build things quickly? And a lot of that comes down to developer experience, to being able to use the right tools for the job.

And actually, a lot of what I found was that, and then we found this over the last year as we were building out various other things, our internal experience wasn't always the best.

So we have this workers product and I talk about this in the post.

We started using this internally five years ago, pretty much as soon as we had the technology, we started building pieces of our performance products on workers because that was the fastest way we could build things.

We've built things like our waiting room product more recently, but also things like we have our WordPress optimization system, huge amount of workers code in that.

Our imagery sizing project, challenges system for verifying whether a traffic is human or not.

Lots and lots of system we've built internally use workers to do chunks of logic because that allowed the team to have fast developer cycle, all the benefits you get with workers.

You don't have to worry about the operation side of it.

You can deploy new versions. You can run a local copy.

You can run different versions in production for different customers. So you can roll things out carefully.

You can give people who need special features early access to things.

So many powerful things you can do with workers platform. But actually the way we built this originally, we quickly integrated the worker system.

And then all this works happened on the workers product for making the developer experience, building Wrangler, building tooling, building tail logs, building all the things that Tanushree is talking about in the platform.

And we didn't have those internally because we'd done the quick integration in 2018.

And then we'd been using that for a little while. And one of the things that we've done over the last couple of years is come back and look at how are we giving the benefits of our platform to our internal developers?

And if we do that, how much further can we take it?

So I've been running a project over the last year really to work out how do we make the internal experience for using workers for internal use cases better.

And I talk about the whole load of the things we've done in that project.

And that's how we get to the 5,000 words nearly.

So one of the first things we had to do was make sure we can use tooling like Wrangler for our internal use cases.

But our internal workers, they're a bit special.

They have some special permissions. They can access some services which public workers can't access.

So we had to do some work on the security model for that and building the right layers of ability to publish and to deploy things carefully.

So lots of interesting stuff around that. How do we make sure that our workers can access resources that our workers can't and have the right permissions model?

And actually, the workers platform has a lot of that thought has gone into the workers platform.

The whole platform uses this thing called a capability-based security model.

When you write a worker, you say, I want this worker to have access to this resource.

You don't have access by default. Essentially, it's a Zero Trust model internally.

So we don't just build zero trust products for customers externally.

We take that whole philosophy internally as well.

So a worker doesn't have permissions unless it's given permission to that resource.

And you give that permission using a binding. And we've made sure we've extended that system for internal things.

So that was one of the pieces of work we did.

But then there's lots of other work we did which have had effects.

So one of the things we needed to do is make it so that when we write those workers, historically, to have a worker doing internal things, if you want that to come up in the customer logs, maybe in your log stream logs, seeing what has happened to your then, we had to pass data around.

The worker itself couldn't emit those logs.

Other systems had to do that. So we did some work to make it so that you could emit logs directly from internal workers into our logging systems.

And it'd show up in log stream and our request pipelines and things.

And that work was essential for building our internal things.

But it later became the foundation of what we built for the work of analytics engines.

So that if a customer wants to emit a log and have it come out in their logs.

So this is why we do this. Partly, we use our own tools so that we can go faster.

But the second reason we do it is so we can make those tools better.

We refer to it as dogfooding, which, not such a nice, Ricky's expression's right, but that's what we call it.

And we do all this work to use our own products because that way we find the problems with them.

And we find the limitations and we remove those limitations.

And another really big area where we've done some work and we've got a lot more we want to do is on observability.

If you're writing a worker, and it's one of the big things we're working on with the workers platform, is how do you, as a developer, know what's happening in production?

And that means how do I get metrics out so I can see how many requests is it handled?

How long did it take? And how do I get logs out? And even more importantly, how do I get traces and structured logs out?

So things saying, well, these events that happened, I want to have a structured event that happens every time this thing, this piece of code is reached with these parameters.

And I want to get faces where I can see the whole tree of calls and the timings and information.

So we've been building that kind of tooling internally for our own purposes, our own products.

And some of that's already finding its way to the public products.

Some of it will do in the future. We have a much clearer idea of what the capabilities are.

If we're going to build more and more things on top of workers, we know what we have to do.

And that lets us build a better thing for customers.

So the eventual target of this is, well, how far can we go? Can we replace big chunks of our existing systems with workers?

And that's the future. So I'll be writing blog posts about that where I can tell you how far do we go.

And the answer will either be, we can go all the way, we can replace it all.

Or it will be, we found some issues and here's how we're fixing them.

And either of those posts, I'm really looking forward to writing in a year or two's time.

But the one thing is that the more we use the platform internally, the more we find out how to make it better.

So it's been, it was a really fun place to write. I hope some people get to the end of it.

But that's the can summary. Yeah, that's great.

It's one of the themes and visions we had going into this week was looking at like, what are things we can do to improve the developer experience?

Like, what are problems that developers are having right now with our tools, with other tools, and how can we make that better?

So your post was really a great way of saying, hey, we spent a lot of time looking outward at the developer experience.

But in the meantime, like our internal developer experience was being hindered.

And so looking at ways we can help build all of that out has been great.

So we have about five minutes left. I want to give you each a chance to promote, you know, another post, something else.

You know, you've got a captive audience here. What is one thing you want everybody else to know?

Ricky, we'll start with you. One thing I want everyone watching to know is we want to see what you're building.

So that is my call out is like, shout it out on Twitter with the Cloudflare Dev, Twitter handle, join the Discord, the Cloudflare Discord.

But truly, like Developer Week is about getting all of these cool things in your hands and seeing what you make.

So please, please don't be shy in showing off what you build.

So if you want to follow us on Twitter, our Dev handle is Cloudflare Dev.

Our Discord link, you can join that at Discord.Cloudflare.com.

Now, we hope to see you on both of those. Tanushree, what's one thing you want everyone to know before we sign off?

I'm going to shamelessly plug two things, if you're giving me the spotlight, Dawn.

First, we've heard lots of requests to get workers to platforms down to our workers paid plan.

Today, it's enterprise only. But if you're on the Discord and you give me your use case, I might just give you access.

So if you're watching this, you get the inside scoop.

But we have lots of developers eager to build on it. And towards the later half of the year, we're aiming to get workers to platforms out to you all.

So stay tuned on the Discord on our blog for when that comes. And I'm very, very excited for that.

Secondly, I've been working on some stuff and this came out on Tuesday earlier on the week.

But one big push on our developer platform on workers is making it easier and more performant to connect to databases on workers.

So earlier this week, we came out with some announcements around TCP outbound support for workers, which includes native support for Node Postgres, smart placement, which automatically moves your workers closer to your backend services, as well as database integration, so that you can, you know, a few clicks just get going to your favorite database.

No need to kind of hop back and forth between different platforms.

So I'm really excited about that as well and what that unlocks.

And yeah, excited to see what developers build, as Ricky mentioned. Right.

And finally, Richard, what would you like to plug or make sure the audience knows as we sign off?

So I'm going to continue a bit about the theme of my post as well.

So I think it's really interesting for people outside of an organization to hear about how an organization works internally.

And I've been a cluster for five years, but I joined because it was so open about what it was doing.

And actually, I joined because of workers, because I thought the idea of workers was going to be game changing.

And I think I would love to hear what are the questions people have about how we work.

We talk on our blog with so many things about how we work and what we do.

But what would you like to hear is the question I'd like to hear from other people.

If you read my blog post, if that sparks questions, tell me more about that.

I'd love to talk more. I'd be happy to write more blog posts.

So what would you like to know is really the shout out question.

We do so much interesting engineering. We only have 30 blog posts this week.

We could write more all the time. So, yeah, tell us what you'd like to hear about, about how we approach things and how we think about things, because I think there's so many interesting things going on in Cloudflare.

We could talk all the time.

That sounds like a great tweet for us to send out next week after we've wrapped up everything to ask people, like, what would you like to know?

Because, yeah, I guess we can come up with all these ideas, but it's also making sure that we're addressing the needs of our customers and developers that are out there.

I want to thank you all for taking the time to chat with us today, writing these blogs, working with the engineering teams to do this.

It's a huge amount of work that goes into all of this.

So thank you all very much. I appreciate your time today.

Thanks, Dawn. Thanks, Dawn.