💻 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, and 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.

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

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.

Lots of fun things to talk about. 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.

Ricky, you were thrown right into the fire.

Six weeks, we're doing an Innovation Week.

Can you help us write five, six blogs? I think it was. Thank you so much for doing that.

You've done a lot around AI this week. Your announcement today, again, has those AI tinges to it.

Can you talk a little bit about the Lang chain announcement?

Yes, absolutely. I'm a developer. I feel like at least in the circles I run in developers, we're all playing with all the new AI tools.

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

That is all my developer friends and I are talking about right now, truthfully.

I was very stoked that Lang chain released 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.

I like to think 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.

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

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

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

One of the powerful things about Lang chain is called document loaders.

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

You could load up your emails and then use chat GPT or open AI with it.

That is essentially what the blog post does. It's a lot of fun seeing what you can pull in and what you can talk to.

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 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.

You don't have to tell it new things.

It was showing how if you're a company that uses 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.

I thought that was really clever.

Also, Lang chain just launched agents. I suspect the next thing I'm going to do is with this.

What agents are, is they're 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.

You could say, hey, I want to pull the NBA playoff scores from this year and be able to have a conversation with a language model about those scores.

Agents will then go, and they will figure out, okay, I need to pull from Google and get the playoff scores, and then I need to put those into a vector database, and then I need to do a Q&A with a large language model on them.

It sounds very magical to me, so I'm super excited to see how it works.

I love magic. It's great.

Tanisha, Ricky was talking about 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.

Can you share a little bit about the anniversary announcement of Workers for Platform?

Yeah, Workers for Platform turns one year old. We actually released the announcement post almost exactly to the date this time last year, so it's really awesome that we get to do a whole year-in -review recap.

Let's see what users are building.

Actually, most recently, especially in the past couple of weeks, I've talked to some customers that are really doing an AI push with 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 Platform 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, 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, 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 conceptualized 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 sort of the initial cuff of why we had a serverless functions offering at Cloudflare.

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 velocity that unlocks product managers, engineering directors love Workers for platforms because 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.

These have 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 users' 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 customers' 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 Cloudflare 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 it and 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 log. 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 real time. Every time your user's worker gets invoked, you get a log line and then you can 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 real time 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.

Right.

Sounds like in the last year, the team has been very, very busy building out all of these features.

And it's great to see everybody from like 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 Tanisha 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, 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 hundreds.

So, 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 know, 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 wanted 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 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, our challenges system for verifying whether a traffic is human or not.

Lots and lots of systems 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.

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.

Actually, the way we built this originally, we quickly integrated the worker system.

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

We didn't have those internally because we've done the quick integration in 2018.

Then we've been using that for a little while. 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?

If we do that, how much further can we take it?

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

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

That's how we get to the 5 ,000 words nearly. One of the first things we had to do is 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. 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.

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?

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.

We don't just build Zero Trust products for customers externally. We take that whole philosophy internally as well.

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

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

That was one of the pieces of work we did.

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

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 thing, we had to pass data around.

The worker itself couldn't emit those logs.

Other systems had to do that. 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.

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.

If a customer wants to emit a log and have it come out in their logs, this is why we do this.

Partly, we use our own tools so that we can go faster.

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

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

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.

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, 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?

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

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

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

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

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

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.

That lets us build a better thing for customers.

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

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

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.

It was a really fun post to write. I hope some people get to the end of it.

But that's the canon summary. That's great. One of the themes and visions we had going into this week was looking at what are things we can do to improve the developer experience?

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, 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 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.

So 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. I'm very, very excited for that.

And 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, 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 the, 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 that 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 what we, 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 is, if you read my blog post, if that sparks questions about, 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, we could write more all the time.

So yeah, tell us what you'd like to hear about, about how we, 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, 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.