🏗 What Launched Today at Platform Week?

Everyone welcome to "What launched today at Platform Week", Day 2. Happy Tuesday, everyone.

My name is Christian.

I'm the engineering manager for the developer advocacy team here.

And I'm joined by a couple of our amazing product people to talk about all the amazing things that they announced today.

So let's do a quick round of introductions.

I'm just going to go right next to me to start with Nevi and then maybe Rita and Kabir.

Hey, everyone.

I'm Navid, the product manager for Cloudflare Pages. Hi, folks.

I'm Rita. I was on here yesterday.

I'm a director of product on the Workers team.

Hi everybody.

I'm Kabir. I'm a product manager on Workers computer platform.

Well, super excited to be sitting with some of my favorite Cloudflare people on a call together.

Fun times. We have a lot of things to talk about.

I think we're going to really run up against the time limit here, so we're going to hop right into it.

Let's start with you, Rita.

Let's talk about Workers for platforms.

Tell us a little bit about making every application on the Internet more programable.

The lofty goal is not, but I think we can do it and I'll tell you why.

So maybe the best way to explain it is kind of to tell a little bit of the origin story of Workers.

So I was working at Cloudflare before Workers was even a thing, and a kind of a thing that companies will go through is, you know, you're signing up larger and larger customers and more and more customers, which is great, but all of them kind of need more customization and somehow every single one is going to be a special snowflake and have their own needs.

And so maybe the previous customer wanted to cache things based on a header, but now the next customer wants to do a redirect and based on the location.

And so at the time we're going in and like in the back end, like hard coding all of this, which is also kind of what you do to unlock all this growth.

And like in parallel, the engineering team builds out features to support these things, right?

So like over the years we introduced different ways to cash all these things and like all of these different types of limiting rules and stuff, but like knowing all of those things takes time.

And so what you kind of want to do in the meantime from, from someone who owns a product perspective is enable developers to service themselves.

And so the way that I've seen.

I don't know.

I'm so sorry. So, so.

So the way that you do that is by building out features or giving developers access to APIs.

And that allows developers to kind of usually add integrations from their end and access your product programmatically in that way.

Right, so that's I think the programmability part of APIs is rather than going through a user interface which is like a GUI right, you go through a programmatic interface which is the API, but in order to do that, there's kind of two things.

First of all, as the developer, in order to be able to interact with the APIs, you have to set all of this up to begin with, right?

So if you imagine building something like a chat bot or maybe like there are all of these things that over the years wanted to do with Google Maps and it's always like, I could use the Google Maps API, but now I have to spin off a new application, right?

And I have to set up a server somewhere or like a Worker even running somewhere.

Right.

That I can call all of these APIs from when really what I want is just to be able to go in and write a few lines of code that say like, Hey, if you're creating a new route for me, then like I want you to like exclude like all of these, I don't know, pit stop that I hate or like not take these particular roads or if I'm building a chat bot that I want to go in and instantly start writing like, Hey, in my channel, like as you're handling messages, if you see like this, like illicit word, maybe bleep it out or if like this user comments on something then like respond with this thing or like all the or if these keywords get typed in, then parse them out and create a JIRA.

And today for all of those things, like I said, you kind of have to go out of your way and spin up a separate service.

And sometimes that service is a Cloudflare Worker, but at the end of the day, that's not what you wanted, right?

What you wanted was to make the feature that you're using going back to what you said more programmable.

So it's all a very long winded way of saying that we are making it possible for any product to be able to build that into their system now, which is really, really cool.

And so we already have some really large customers using this, which we're really excited about and actually how we realized that this was a much bigger use case than, oh, a couple people need this was Shopify is building out their next generation storefront platform called Oxygen for their customers and they want them to be able to do kind of similar thing to Pages, but very specific to ecommerce and create their own storefronts and bring their own logic.

And so we're able to build it on a lot of the stuff out for them and like I said, a few others.

But yeah, a lot of what we built out is so applicable to so many people and comes with a built in way to provide things like logs or like do your own routing in front of or do all of the other things that you need in order to be able to satisfy developers.

Yeah.

This was, I remember, the first maybe two weeks I was working here, sitting in a customer call and someone asked me about this and I was like, I don't think we are doing that, but I'll find out.

And now here we are a couple of years later.

Yeah, it makes a ton of sense.

What do you what do you think is like the the ideal customer for this?

Like, how do they how does a company know like, oh, I should, I don't know, I should pick the Workers for Platforms tool for this.

I think about I mean, a great way to arrive at it is I think about the things that customers are asking for and all of the things on your to do list that you can't get around to and like, okay, how can I expose the right interface for people to be able to self service themselves?

When we originally started thinking about this, it was harder to think about examples, but now literally any tool that I use I can think of, Oh, there.

I wish there was a way to program a Worker into this.

So something that you wouldn't think of, like my Twitter feed, for example, if I wanted to customize it and bring my own algorithm or, you know, today you can build like your list of keywords, for example, that you want banned from showing up in your timeline.

But you could create much more advanced rules, right? Like if these words show up, like maybe only showed me today, maybe only show me to them to me on Saturday, like after the episode of TV airs or whatever.

Or if you're product manager, right?

And like used a whole bunch.

There are integrations that exist, but maybe you want on certain things for them to send you an email or.

Yeah, anything that you use if you think about it, kind of have all of these like product flow points that I think could lend themselves to becoming more programmable.

Same way that if you ask me like, Hey, what can APIs be used for? I'd be like, Anything.

What can't they be used for is the better question. That's awesome.

Okay. I'm going to ask this question as we go through each of these.

It's kind of a wrap up.

Where do people go? What's the what's the call to action?

Where do they go if they want to learn more about it?

So we're still trying to work with a smaller group of customers just because we've enabled a few customers to build things out on this.

And the next phase of what we want to do and the way that generally Cloudflare makes our products better, is we work with some customers and we understand what their next features are that they want from us.

So the way to get involved is if you go to the blog bottom, there's a link to register your interest and we will be in touch.

Very cool.

All right. Should we switch gears to the next one, which is how is it Log Push for Workers?

Is that the right way to describe it or how would you describe that one?

Yes, that's exactly how I would describe it.

So if you're an enterprise customer, you might already have experience with our Log Push, if you're not, don't worry, I'll explain to you.

So what Log Push enables you to do is to, as the name would suggest, push your Cloudflare logs onto a destination.

So whether you saw your logs in the bucket storage like GCS or something like that, or if you're using a logging system like Datadog, we can when Cloudflare receives requests and produces responses, we forward those onto said logging provider.

And so today or up until today, if you were using Log Push, you could get logs and if you were also using Workers, there were a few fields that would show up alongside them.

So you could find out things like how long it took the Worker to execute or whether or not it was successful.

And if not, it would give you a little bit of information around why it failed.

But if you're building your application end to end on Workers, then there's all of this other information that you want about, about how your Worker went.

And the really cool thing, too, is that Workers no longer only respond to requests.

They respond to all kinds of things. So starting tomorrow, or sorry for a while now, they've been responding to Chrome triggers, but in the future there could be so many more types of triggers that invoke workers as well.

And so there's not always going to be a mapping issue per class.

So by being able to push Workers logs onto Log Push, you kind of get two things.

One is you get all types of Workers events, but also you get much, much richer information about what happened in the Worker.

So a really, really long requested feature console.log is going to be in your logs now, I'm going to clap.

So if you're trying to debug something, right, customers writing in is like, hey, I'm seeing this error and you're like, it works in my machine.

You can go in and retroactively see like, okay, what, what got invoked or maybe dropping a few lines of code, but start logging in and start to be able to debug things a lot better.

So I think this is a really huge win for observability and Workers.

And then similarly, like I said, much richer data. So information around exceptions, all sorts of fields around.

Yeah.

Like statuses. What else.

Yeah, I think that's the big stuff. Yeah.

I imagine it's also good for like if you have your Workers running as part of a larger, you know, different services or whatever, running different places, like being able to plug your Workers logs into everything else and seeing how they kind of work as opposed to like literally having to tabs open where like one is all your other logs and then your Workers logs.

That makes a ton of sense and probably be really helpful for diagnosing like weird, weird software stuff.

Basically as like as systems just get weird, especially the multiple services and stuff involved.

Yeah, exactly.

Like you get paged, you wake up in the middle of the night, what you want to do is open up the one dashboard that you have and go like have it be very obvious, like, oh, this is where this graph looks like way off or this is happening.

And yeah, I think having it all in one place just makes it so much more powerful.

Yeah.

I also say one other thing is that this blog post announcing this is in the running for my favorite illustration of the week, too.

Yes, I completely agree.

I was contemplating changing my Twitter background picture to I think it's very cool.

I used it in our Discord community call, Discord has like a banner or whatever kind of like Twitter and I use this picture.

So everyone go to cloudflare.com and check it out.

It's very, very cool.

Like a Workers command center. Maybe I can set it to my background now.

Very awesome.

Cool. So moving on to service bindings.

Service bindings are generally available with efficient pricing.

That's exciting.

Could you tell us a little bit about that? Yeah.

We've talked about this in a little bit before during Full Stack Week if you were here.

But just to give you a top down. We have opened up service bindings which allow you to communicate between your Workers.

And this is a feature that we've definitely heard a lot of requests for in the past.

People have been kind of clamoring for it. There's definitely a big motion towards getting towards today, and I think it opens up a lot in terms of what you can do with the platform.

You are able to say, Hey, I want to talk to this other service, this other Worker, and maybe split them up so you don't have to worry about building a small change in your authentication service and then having to reroll the whole Worker out and your whole API gateway out.

You can just say, I just want to make that authentication service a separate Worker and push updates to it whenever I need to.

We've seen a lot of kind of interesting use cases along those lines so far.

So we had a customer come over to us during the beta and previously they had a really, really big Worker that they kind of jammed everything into.

It made sense for that use case at the time because it was all of their routing and every single request had to go through it, but they couldn't really bring too much more onto the platform and they wanted to bring more of their development teams onto the platform as well.

They had a really great experience with Workers and once we got them on service findings, they're able to say, Hey, let's put let's put this code out first.

But then we can also bring some of the application logic that might sit elsewhere and bring it on to the Workers platform.

And it's owned by a different team and they can make their own updates, they can have their own release processes, whatever they need.

And it's all just works right out of the box with service bindings.

One thing that we also did in moving towards general availability is we wanted to make sure that it works very well with our inbound pricing model.

Just to give a recap, the unbound pricing model is a combination of an invocation fee and a duration charge.

Duration is the amount of time that your Worker has memory allocated to it.

Basically, it's the amount of time that it's running on our edge.

As you can imagine, if you were to make multiple Workers, maybe three or four, that stack on top of each other, that could get expensive really, really quickly.

But with the Workers Platform, what we're able to do is we can share the resources that specifically the compute thread that you're using across all of those Workers.

You can imagine a case where you have an API gateway that's waiting for authentication from auth0 or some other auth service.

During that time, it's really the API gateway Worker is not really doing anything.

It's waiting for that service, and we are able to say, Hey, that's on the same compute thread, let's not double charge you for it.

It's sharing resources.

We're going to flatten all of those duration charges into just one bill.

So it makes it a lot more easy to use and easy to stomach if you want to split your Workers across multiple different services.

Yeah, that is super cool.

To me, it makes me think of like, I guess back when I worked in like RubyLand, we were doing microservices and like the hardest part of doing that was like getting them to talk to each other.

It's like, Oh yeah, it's like, it's fine to start a new project.

Like, we're going to have to, like, plug it into some scary, like, EPS that two people understand and a bunch of like, just weird, I don't know, weird, like, bash like witchcraft that you have to do in order to get these things to talk to each other.

But in this case, I mean, a service binding is literally just like it's like any other variable, right?

You just you combine them and like the UI and you say, like, I want to see this service binding available, this Worker, and then you just call it in your other Worker.

Right? Yeah. Yeah, it's really, really easy to use.

We've kind of taken out the complexity of the microservices world where you have to worry about the interface and the networking and it's basically just attach it to a variable name and you can say fetch and you can create a little request object and send it back and forth between your services.

Under the hood, there's not really any networking involved.

We do just serialization and we talk back and forth between those Workers and they happen within the same COA.

So it's a really, really kind of a cheap abstraction from a latency side and from a complexity perspective.

What's your favorite?

You said that things like it was in a beta period.

Like what was your favorite?

Or maybe like one of the more interesting examples of something like you saw someone using service bindings for and you're like, Oh, I didn't think of that.

That would be a really good use.

cases, is there anything that comes to mind? Yeah, that's a great question.

One that comes to mind immediately is we had a customer who had some legacy code, but they were already using Workers for some of their kind of like request modification that they wanted to do.

They had legacy code in, I think a cloud provider that they were trying to move off of, and they didn't really like it and they wanted to move it on to Workers, but it was really hard to do and they didn't want to stuff all of that code into the same Worker that was handling some of their request modification.

And so with service bindings, they will say, okay, for this particular path, actually just send that request over to this other Worker and we can start to migrate that service off of our old provider.

It's kind of a story that we've heard multiple times, but it was interesting to see that they were able to just cut costs and not have to deal with that external provider anymore.

And they were really excited about it.

Yeah, that's awesome.

So you said it's general availability so people can get started today.

There's no form to fill out or anything like that.

You just go in the UI and start playing around with it, right?

Yeah, exactly.

No forms.

When you open up your Worker within the UI, you can head over to the settings tab, click variables and you'll see service bindings are done there.

You can add a service binding from Worker A to Worker B and then if your other team, let's say another team is managing Worker B, they can see in their triggers tab that someone else is referencing them.

So you'll know on both sides that you have dependencies and you've made dependencies.

That's super cool. I didn't actually know that you could see you another mess around with that.

See, in analytics, that's really cool.

Yeah.

Awesome. It's a great way to just kind of see everything that's coming into your work.

Yeah, yeah, totally. Well, very cool.

Let's change gears our last 10 minutes and let's do the Pages take over because we got a lot of Pages things to talk about.

A lot of Pages, stuff.

Today.

We had a really, really fun announcement. Two of them actually.

The first one was direct uploads.

And I think this is a really, really huge one for developers who maybe haven't been able to use Pages before.

Right.

Pages historically has only been allowing you to use integration. You can use GitHub, most recently you can use GitLab.

And that's really great.

Our users love that developer workflow, but it doesn't work for everyone.

You could have a different provider, you could have a really custom build that you're running and it doesn't always work.

And so I think the really big thing about direct uploads is it allows you to open most use cases.

And so let me just give a little background on what direct uploads is.

So today you can actually bring your assets right to Pages. You can do this in two ways.

The first one is through dragging and dropping your assets onto the Pages dashboard, and the second one is using Wrangler.

We wanted to add a drag and drop kind of feature because I think one of the biggest goals on Pages is to remove those barriers to entry.

How can we get users onto our platform fast and with minimal friction and then, with Wrangler, so for a drag and drop we realize like that's not a very optimal way to iteratively work on your projects, right?

Dragging your assets over and over again doesn't really kind of contribute to that really consistent workflow.

So we wanted to involve Wrangler.

Wrangler is a CLI tool that our users know and love and I think this is a really beautiful way that kind of the Wrangler team and the Pages team got to work together in a really fun way.

And so with just one command, you can bring your directory right to Pages and we'll have it up within seconds and this really nice kind of terminal experience.

So it's really that simple.

It's available on the dash right now.

And the other really thing the other thing that's also really exciting is we've been having a lot of users just today talking about how they're coming from Worker Sites, which is a sister product of ours and it's very similar to direct uploads and are now migrating over to Pages.

So I think Workers Sites and Pages are very similar except with Pages.

You kind of get all of those nice bells and whistles like deployment histories and preview URLs, like setting environment variables within the UI.

And so it's just a really nice kind of package experience that allows a lot of flexibility to our developers.

So handle your custom builds, use your own CI tool and handle the build on your own and we'll take care of the rest.

And so you get kind of get all of those, those nice kind of features that we packaged within Pages and that opinionated workflow that we have already, but just kind of adding a little bit more customizability to it.

So that's that's the one first announcement.

However, if you're not somebody who wants to handle or handle their own CI system, we got you covered because we also announced a bunch of build improvements and I'm so proud of the team for this.

This has been something that has been a long time coming and for good reason.

We definitely weight our options.

We looked at all of the different ways that we could speed up our build times because that was one of the biggest pain points for our users.

And so finally we settled on certain infrastructure and we can now say that our build initialization time was 2 to 3 minutes before and it's now 2 to 3 seconds.

And that makes a huge, huge difference. And this is just the beginning of our journey because we want to make our build times even faster.

So we have a boatload of things that we want to do in the future, which we'll talk about in a little bit.

So speeding up our build times was our first priority.

But again, that's not the only part of the build experience.

So we looked at other places where we could improve and optimize the build experience.

The the second one was being streaming build logs. So at first and historically, you would be able to see your build logs at the end of the entire build and that's great.

You can see what goes wrong, but then you have to wait for your entire build to finish with streaming build logs, at every single step you can see exactly what's going on.

You can debug, you can see error messages and it really, really just helps our users kind of act fast and iterate quickly without having to wait.

And I think that's kind of the big theme that our Pages users used to experience before is the waiting and we want you to act fast.

And then the last kind of improvement that we made to our build infrastructure or just our build experience in general was allowing you to configure the branches that you want to build.

We realize that not every single preview branch needs to be built.

Sometimes preview branches don't need to be built at all.

But if you would like to configure that, you can now.

And so I think using these kinds of skip configurations using CI skip, that command in your commit message kind of gives our users more autonomy over how they want to work, when they want to work and what kind of workflow they want to have.

Pages is very opinionated, but I think allowing that flexibility is a really important part of kind of working with the rest of our developer platform.

So really exciting stuff and some of the things that we have kind of coming up for our build experience and our build in front in general are incremental builds, which is going to be huge for all of our users with really large projects that are just kind of making these minimal changes and don't want to rebuild their entire site.

And then another key thing is kind of our build image. And I think this is kind of caused a lot of issues that we have been addressing and we have been working on.

But we're really excited to be able to kind of rebuild our build image and kind of support the languages and tooling that you guys use today.

So super, super excited about that and really great feedback already today.

Yeah.

I feel like I'm trying to think all you're talking all this stuff. I think that this may address.

Oh, no.

Did we lose Christian? I think we did.

Well, if I may complete his thought, I think this addresses yeah, many of the most highly requested features.

Christian, we lost you for a few seconds.

Oh, really?

I was trying to fill in for what you were saying.

I was like, You all are so still.

Wow.

I was saying it's... This is all just like a home run.

And I think it's is like so much of the feedback that I've seen before about Pages is addressed here.

And I also love the kind of like future looking like, here's what we have coming up next.

I think people are super excited about that.

So, yeah, where where should people like?

Maybe someone hasn't used Pages before.

Like, what's the use like anything, like a clear...

Like, you have to go try this today and you'll really like get why Pages is so awesome or do you feel like the whole platform is just like, I don't know, an amazing place and there's no wrong place to start, I guess.

How do you feel about that?

Yeah, I feel like there's no wrong place to start.

I mean, again, every developer is different.

They want have different goals for their sites.

I think the drag and drop features is a really cool place to start just to see what is Page all about.

What can I do on Pages? What can I do to my site?

And you can literally get your site up and running.

You don't have to install Wrangler.

You don't have to do anything like that.

Literally drop your assets into our dashboard, and that's it and you're ready to go.

So I think if you haven't used Pages, that's a great place to start. And then once you start kind of getting used to our tooling and kind of all the things that we offer, you can kind of get fancy with it and maybe add some functions into it, I don't know.

But another really exciting announcement coming up on Thursday and I won't have too many spoilers, Greg Banville actually just did a little bit of a walk through in his popular TV segment earlier today, but we will be announcing a really, really exciting feature in combination with Pages called plugins, and that's basically these reusable set of codes, that reusable set of code that allows you to work with different third party services.

And so we'll be launching with a couple of partners as well.

So definitely look out for that blog post and some more information about that in our docs.

Yeah, I'm super excited about that.

And I'll also say there was another speaker series talk today that I did with James Ross from Nodecraft.

We actually talked a lot about migrating from Worker Sites to Pages and just their experience up until now using Pages.

It's been a really interesting journey and I think his company is growing up alongside our platform, which always makes me really happy.

So.

Good. And on the Cloudflare side, we've gone through this migration ourselves for our docs, from Workers Site to Cloudflare Pages and man, what a quality of life improvement that's been, especially since those bill times have gotten so much faster, too.

Yes.

Yeah, absolutely. We'll have a blog post on that coming soon.

That is a very exciting internal, I guess, case study on that exact topic.

So we have 30 seconds left.

So I just want to give everyone a chance to say goodbye.

Thank you, everyone, for talking through all their products.

Any last things anyone wants to add?

If I were to channel my inner Michelle, I would say we're just getting started.

Is that the way to wrap up?

Nice.

Yes, I love it. Well, thank you, everyone.

We'll be back around the same time tomorrow with more platforming stuff and.

Yeah.

See you then.