Lunch Break: Building a Platform On Workers

So, I'm Cara. If anyone's listening, we're just waiting for Scott to join us. So yeah, the goal of this segment today is just to talk to a customer on a workers platform, understand what they're using workers for and what their platform is, find out what they're doing and why workers was a good fit for them.

I have Kabir with me.

Kabir is an SE at Cloudflare as well. Hi guys, Kabir Sikand, Solutions Engineer here at Cloudflare.

I've been here for just north of a year now and I'm specifically focusing on a work related to the workers platform.

So definitely excited to talk to Scott today.

Once we kind of get the meeting room sorted out.

Yeah, so Scott did just ping me. He's joining now, but essentially like me and Kabir's jobs are to work with customers.

So I'm in business development. So, oh, great.

Scott's here. Scott, can you hear us? Yeah, I can hear you.

What's up, Scott? Thank you for joining us today. Hey. So I've got Kabir with me.

Kabir is a Solutions Engineer on the workers team at Cloudflare.

Hi Scott. And super excited that Scott from Type is joining us. Scott, why don't you tell us about your company, why you started it, what you guys do?

Yeah, so Type is basically what we call a headless CMS.

And that's like some term that some people made up.

Hopefully we can change that term. But basically, what we do is we allow people to structure content and then deliver that content to any platform to any app over our API.

So you can think of it as like a CMS, like a traditional CMS, kind of like WordPress, but like detached from any app.

So it actually doesn't know or doesn't care what app you're consuming the content on and you can structure it however you like.

Oh, cool. That's really great. And so I think maybe kind of diving into that.

I definitely see some use cases there. I mean, I've built personal blogs in the past and things like that.

And certainly like using tools like WordPress, it's really great, really easy to use, but sometimes you want something a little more complex, you want to apply your own front end to it, things like that.

So I guess maybe to start towards the top of your interaction with Cloudflare, like what made you come over to Cloudflare?

What were some of the initial thoughts around building on the workers platform and why workers?

Yeah, so, I mean, I've been using Cloudflare just personally and at other companies I used to work at for close to six years.

So it was kind of just, for me, like when I was learning to code, Cloudflare just seemed the easiest.

So I always kind of gravitated towards Cloudflare.

So like when I started this company, it was just like, it actually, we didn't really have use cases for anything work related when we first started type.

It was mostly we actually, so we have like a CDN, right?

So we host content, we host images, videos, things that our customers need to send down to their applications.

It was like, oh, we need a CDN sitting in front of these assets, right?

Like they got this S3 bucket and we need some really dope CDN sitting in front of it.

And it just was a lot easier to get set up with Cloudflare since we were already doing DNS with our domains and stuff there.

So we're like, let's just put it there versus going with something else.

So that's kind of where it started.

And then like, as we transitioned on to really discovering what the product was, as we started talking to customers and really just figuring out new patterns and stuff like that, we knew that it was clear that we needed to be able to do like some type of computation on that CDN.

And that's literally around the same time you guys started announcing like data for the Cloudflare Workers.

And we were like, oh, this is legit.

This is literally what we were just talking about. We were just trying to figure out how to do this.

So yeah, and that's, and when we played around with that, I think we actually reached out when we got that email, we were some of the first people to actually try it out.

And we played around with it and did some of our prototypes, initial prototypes and stuff.

And it was just, it was great.

We were like, yeah, this works. This makes sense. We like the fact that it's all on Cloudflare, you know, and we kind of knew that this is what we were going to use.

Yeah, that's really amazing that the timing kind of worked out perfectly around when you guys are talking about some extra computational power and maybe doing some transformations and things on the platform.

You know, since then, the platform has definitely come a long way.

It's obviously, I would imagine your experience now is very different than it was, you know, eight months ago, a year and a half ago.

What has kind of, I guess, evolved on your end? And then in line with that, how has your workflow evolved as you've been kind of using the platform?

Yeah, so for our end, it's evolved a lot.

It's like to the point now where, you know, traditionally, like you're building an application and, you know, let's say you have a market service architecture and you're just like, you know, what layer do I have this logic?

You know, am I adding it here? Am I adding it all the way, you know, on the origin somewhere?

Like, where can I put this logic where, you know, my customers can benefit from it?

And now we have this additional layer, which is, you know, Cloudflare Workers and increasingly finding ourselves going to that layer.

Like, for instance, you know, we build on a per usage basis on our API from like, you know, how many gigabytes of assets you transfer, how many API hits you do, things like that.

So having the ability to do that on the edge is really great, because like, if we didn't have that ability, like, it'd be really hard to, you know, calculate how many times you were hitting our API.

But at the same time, we don't want you going origin all the time.

So it's like, well, where do you do that? Whereas, you know, like doing this on the edge, it just makes sense, because it's right there on the cache.

So like, that has changed a lot of like, just our code and just how we think about things.

We see ourselves moving a lot of logic there, things like how we manipulate images, how we like transform them, how we keep track of things, stuff like that.

And then like, as far as our workflow goes, as soon as you guys, you know, allow us to basically, you know, write the code, however we want to push it up, that like completely changed it.

Because before I know, when Cloudflare Workers first came out, you had to do it in the editor, you had to do it there.

And I know that was just a prototype. I know you guys are going to change it.

But when that did change, it kind of just was just amazing for us. It kind of just really, because it was a lot of times where like, we would go in there, we would just like mess ourselves up in there sometimes.

We would just really mess ourselves up.

We might have like a Cloudflare worker that's looking at this route, but then we'd have a page rule somewhere else that's looking at this route, and it's like conflicting.

Whereas like now, like everything's in just one place on GitHub, and we can kind of just control from there.

It's made it less of like a infrastructure thing and more of like a target, like I'm deploying to AWS, I'm deploying to Heroku.

It's just a target that we deploy to. It just fits in seamlessly.

So yeah, it's been pretty great. of the team has been working specifically around the developer workflow over the course of the past year.

And it sounds like that's definitely gone in the right direction.

But I imagine, you know, just in tandem with seeing a product evolve, what are the challenges that that presented maybe early on and maybe even now?

Yeah, I mean, we've had a lot of challenges, for sure. And I would say some of the challenges that came up with that, like just, you know, adopting workers early on and then watching it evolve for the better and like keeping up with some of that stuff.

It actually ended up working out for us pretty well, because throughout the early days of type, like pretty much the first two years, like everything we were building was basically like a prototype.

Anyway, it was like a test.

Like we were just testing modders, trying to figure out who our customers were, what did they want.

And so we never really went in full intention thinking that what we were making was going to be it, it had to be perfect.

So although like you guys are making all these updates, and it was changing our workflow, so were we.

So like it was, it was totally fine.

It kind of just went hand in hand. So, you know, we might spend two months building out this new way of our product and releasing it to a different, you know, persona in our market.

And then two months later, like, oh, we're going to try a different prototype.

And around that time, something new from Cloudflare Workers come out, you know, key value store or this or that.

And we're like, oh, let's just try this this time. So it kind of just like gave us an excuse to just pick something else back up when we were making changes anyway.

So it didn't really affect us negatively too much with all the changes and stuff.

It actually just worked out. And I actually think, you know, it actually like encouraged us to stay up to date with what you guys are doing, because we were in this constant cycle of just making stuff and making new things that we will always check back.

And we saw that you guys were keeping up too. So it felt like you guys like building stuff for us.

It was kind of crazy. So yeah, it just worked out.

That's awesome, Scott. So would you say that workers has made it easy for you guys to scale or to scale with you like as you've grown?

And is there a next steps or something that you want to see from workers that could help as you go into your next phase?

Yeah, I mean, workers is definitely, I'll say this, I don't know how we would do some of the stuff we're doing right now without workers.

We would have to sacrifice a lot. Like we could probably get some of the same functionality, but with the sacrifice, whether it's a speed sacrifice, whether it's a cost sacrifice, there's gonna be something we have to give up in order to get what we have now.

So it definitely made it easier. I also think it creates a better experience for our users, because our platform is dynamic in nature.

We literally allow you to change content in the shape of that content whenever you want.

And being able to cache that is really challenging on a traditional CDM. You actually need to dynamically cache these things and stuff like that.

So yeah, I don't know.

It would be really tough without Cloudflare Workers if we couldn't do that.

So yeah, it's definitely made it easier. And as far as where we want to take it, so right now we're still in the early days, but we're already talking to some customers that are just looking at advanced workflows and different things that all these technologies combined can enable.

So for instance, if you take something like some type of Jamstack application, just some JavaScript that's SEO index or whatever, and then you take something like a Cloudflare worker, and then you add a CMS to it, well now with those three tools combined, you can do things like dynamic AED testing on the edge.

You can take someone's IP address and change the hero title on the page, but still have the SEO index, right?

Because you can do all that stuff where you couldn't do before, and it's just not possible without something like Cloudflare workers.

So for us, we're just trying to figure out what are some of those use cases, what are some of those advanced workflows that really big teams are looking for, and how do we build that into type, into Cloudflare Workers?

Yeah, that's a pretty interesting use case that you brought up there.

Towards the end, when you kind of combine a Jamstack, a CMS, and edge compute, suddenly you're able to do things like dynamic rendering of content that is unique to certain request heuristics, so things like the IP address, the geolocation of that customer.

Maybe certain headers or cookies or request bodies that you're seeing, and it starts to make it really powerful.

And so in that vein, we recently brought out tools that allow you to interact with the DOM.

Have you guys been able to take advantage of tools like the HTML rewriter, or is that something that's still kind of down the line in the exploratory phase?

Yeah, it's still an exploratory phase.

I built out a little project with it not too long ago, just trying to stay current and stay up to date.

It's kind of just like a habit of mine as an engineer.

But yeah, we haven't applied it internally yet. We use Cloudflare Workers internally for our product, but we're also leveraging Cloudflare Workers to add value for our customers.

So there's two ways we're using it.

Internally, I don't see there a use case for us there, but I definitely see a use case for us leveraging it to add some value for our customers.

And for that, we just need to talk more to our customers and really figure out what the problems are.

And what we do is we just reach in our bag of all these things that we've seen, kind of like what you're describing, like, oh yeah, this is the perfect technology to solve this problem.

So we're just waiting to hear about more problems, and most likely we'll probably reach for that.

Yeah, I've personally seen more and more clients and users of the Cloudflare platform start to think about building out workers instead of in a use case of transformation, instead building out applications and application logic at the edge.

And, you know, as you mentioned early on, one of the big benefits there is like, I am a developer and I want a really quick way to kind of kickstart some project that I'm working on.

Maybe be it at, you know, a large company where we have maybe like a labs team that's working on that or, you know, in the back of your garage while you're working on the side, right, or if you're focused on a specific project on your own.

So definitely on like the ease of use side, it's interesting to start to see more folks like use the newer tool sets that we've had to build out full application infrastructure.

And it sounds like you guys are doing that too, right?

You're driving some of your application with the workers platform, and then you're delivering value on the delivery side to customers.

Yeah, absolutely. Like, I feel, you know, like, if I was going to get started right now with something quick, you know, just thinking differently.

And, you know, I mean, you're just a front end engineer, right?

You're just a front end engineer, and you want to get started, you want to build something quick.

Maybe you understand DNS a little bit.

Maybe, you know, you got to host a domain somewhere, you know, you got to do that routing, because every hosting provider tells you to do it, right?

So you follow those instructions, you land on Cloudflare. And then you're just like, well, now I need a server, I need to host something, you know, I need to, I need to have this form submit somewhere, I need to do something, right?

So you start thinking about a back end. And I think that's where a lot of like front end engineers, or even unexperienced engineers, like runs into this blockade of just like, oh, what do I do for back end?

Like, how do I get there? And I think Cloudflare Workers are moving in a direction where they're like, well, you can consider us for a lot of that stuff now, right?

We're not just like some proxy that's sitting in between your origin, like you can actually build full apps here now.

And it's getting better every day, right? So I think moving in that direction and building abstractions around that is just trying to make the developer experience just very seamless for, you know, even a new developer to pick it up and consider it to build like sophisticated applications and not so much just adding more value to an app that's already there, but literally being, you know, their only source of like logic on the server.

Yeah, that's, that's a really interesting point there.

Like, just from the perspective of, I used to be a developer myself, right?

I've mostly focused on, on front end technologies, and making the jump from some of that front end technology to a lot of the back end server technology, it's very different world.

It's not always a smooth transition.

There's been a lot of attempts at like, what's the right way to build from a front end engineers mindset, a back end technology, there's, you know, tools like NPM, and and, and technologies like that out there, right frameworks that allow you to kind of think of things in that way.

And now you're kind of starting to bring that over to the network edge.

And you're saying, Hey, I have very similar technology here.

And it's not a completely different language. It can be if you want to talk in a different language.

And we can, you know, use WebAssembly, we can webpack, whatever is needed to be done to bring that over to the Cloudflare Workers environment and run that.

But, you know, from your perspective, is that made it easier from the perspective of a business owner, in terms of hiring even folks like developers on your team?

Does that make it easier to say I have more flexibility around who I can hire?

How I onboard folks? How I allow them to build on the technologies that are being used within the company?

Yeah, I mean, absolutely.

Our product is driven around JavaScript. So if there's any platform that's going to enable anyone on my team to write JavaScript, it's definitely going to make it easier for us as a team to get things out.

So like, that's why I'm like, I'm pretty stoked that, you know, you guys did add the webpack support.

And because I mean, even like just going from writing JavaScript to browser, the JavaScript on node, and then like, trying to understand how web workers work, which, yeah, it's JavaScript.

But it's also like a different environment. It's a new thing, right?

You got to learn it, you got to understand it. And you have this documentation everywhere, and things like that.

But just being able to use the tool that we're used to, and just deploy to like a different target, like this output here, like that's been pretty powerful.

Like, it's distracted away enough to where most of the people on our team just see it as it's like, it's literally just another platform, right?

You just you just run this command, and it goes here.

And they don't really have to think about it. But the people who understand it very well, can get down deep and like do like very intricate networking things.

And, you know, conditionals on the edge that do optimizations and stuff like that.

We do a lot of crazy stuff with because we use we use image X for the image transformations and stuff.

But we actually put Cloudflare in front of the image X, even though they have their own CDN, right, we still put Cloudflare in front of it, because we do other stuff to those images and assets that we can't get.

And but but we can do that really easily.

So but at the same time, anyone can go in and just like, write some basic logic on Cloudflare and like not have to worry about they didn't have to go like learn a whole new thing.

So yeah, it's definitely makes it easier.

And like, so far, like I've been, I've been pretty impressed with how someone's skill is able to like transfer over to use something like Cloudflare Workers.

That's amazing. Sorry. So would you say that because it's in JavaScript, is it easier than other similar companies like workers?

Yeah, I mean, yeah, I mean, there are a lot of, I mean, a lot of the edge technology out there use JavaScript, and they all have like their own flavors, right, like, you know, that edge does.

They just use Node, but like their thing is kind of kind of weird.

There's a lot of stuff out there. They mostly all use JavaScript, but Cloud workers in JavaScript is a little different than browser JavaScript is a little different than Node in JavaScript, although it's all the same language, it's a different environment, which means there's like different ways to do things.

There's different There's all this stuff that's completely different that for someone who's just trying to get something done can be like, oh, it's a whole new thing I got to learn.

And then for, you know, for most engineers, they don't really want to learn something new that's only going to be applicable to this one thing, right?

They're not going to go like, All right, you want me to go learn this new thing that I'm only ever going to use here, right?

Like, I only plan on being in this job for two years.

So like, what am I going to do with this? So like, but what the way that you guys have abstracted it being able to use webpack and stuff like that.

That's no longer the case, right? You can just write the job the way you need to write it.

It's just another target. So you don't have to worry and think about that you're learning some, you know, proprietary thing that's only going to be applicable here.

It's not the case. Sure. Yeah, I'm not a developer at all.

But I took one computer science class my senior year in college, and they taught us HTML, JSS, and JavaScript.

So we could build our own website and embed like a little game on the website.

My game is GTA 6. You mean like Grand Theft Auto 6?

Yeah. But it's just a little car like weaving through some obstacles that give you like negative points.

I mean, it was very simple, like, like algorithms or, you know, JavaScript commands.

So definitely was nowhere, nowhere near anything you would ever want to play.

But that's my only cutting experience.

So the fact that workers was a JavaScript, and that was the only thing I knew coming into Cloudflare.

I was like, this is great. Like, I actually do know what that is for myself.

But I did want to bring it back to you, because I knew you are a developer at heart, and you build this platform for developers, when there are similar platforms out there like WordPress with the front end.

Was there a specific functionality gap that those types of companies aren't providing that you saw a need for?

And that's why, you know, you created Type? Yeah. So one of the biggest reasons we created Type, like we didn't like just sit down, it was like, Oh, we just want to make a, you know, better CMS.

And we're definitely not the first headless CMS out there.

It was so before I started this company, I had a, I was running a consultancy where it was mostly me and my friend where we did a lot of open source stuff.

And we kind of like, we did a lot of stuff, open source, especially in the JavaScript community, we spoke at conferences and things like that.

And we ended up just doing like consulting, like fortune 500, where we would either go train them on something or help them convert some site over to some new technology, or just just be there for architectural reviews, things like that.

And we did that so much that we saw a pattern, like a lot of these companies would like hire us to convert their legacy PHP, WordPress, Drupal stack over to something like Angular or Vue or React.

And, you know, whether we were hands on or not, sometimes it would take over a year to even get there because it's just all the politics and the size and, and just so much with these big companies.

And then they would get there literally like the day before pushing the button to go live.

And they'd be like, so how do we get the content in here?

And I'm just like, what, what do you mean?

Like, you guys didn't, you didn't think of that? And I was like, oh, we just thought WordPress was still going to work.

No, like, you can't, it's not going to work anymore.

Like WordPress was, you know, a kitchen sink, it did everything for you.

You can't, I mean, you can, you can have WordPress to get it to work, but it's not built for that.

And they just were shocked. So then we noticed that a lot of those companies would just, you know, get some more contractors, do another contract and spend a couple million dollars building out another CMS solution to take a whole nother year to get their content and it just never stops.

So we were like, wow, this is a really big problem.

And if, you know, these big companies are having it, that means, you know, SMEs were already having it.

Right. And, you know, they probably solve it themselves, which is why we're not hearing about it.

I bet they have some really nice solution. And so we did our research and we found there were other hella CMSs out there, but what we found was that the people that were creating these hella CMSs, they were treating them as like a marketing tool, like a traditional CMS is, right?

A traditional CMS is seen as a marketing tool for your marketing team, for them to go build out the marketing site and the developer maybe adds a plugin here or there, but from there, they're done.

They don't do anything. And that's how these hella CMSs work, whereas we saw it as a developer tool.

It was actually a tool for developers to enable them to get back to writing code.

And we wanted to empower, we wanted to give them everything they needed to empower their team to edit whatever content they wanted versus just going straight to the marketing people.

So that's kind of how we saw it, because everything was switching to this like microservice front-end architecture where everybody's using Jamstack this and API that.

We were like, yeah, you got to fit in there.

And from that perspective, you're actually a developer tool. And that completely changes your go-to market, you know, the customers you're going after, your brand, you completely change everything, your sales, everything.

And that's the difference that we saw with other hella CMSs.

So, and that's kind of what we're doing.

That's awesome. That's, that's really cool. And I can imagine that you can do a lot more things on the developer side than you can with like a fancy UI like WordPress and that, you know, that probably makes developers a lot more excited to do their jobs.

That's the plan. Yeah. We're, our goal is to basically, and most of our product is open source.

So at least this new version that we're coming out with like more than 70% of the product, actually all the product is open source, except the API, the part that's, you know, sitting behind Cloudflare and our data stuff.

Everything else is open source and you can do whatever you want with it because we realized that's just what developers want.

You know, at the end of the day, you can get you, you, if you went to your team, if you were the product manager and you went to developers on your team, like, Hey, you guys can build a CMS.

They're going to do it. And they're going to be like, yes, finally we can build a CMS.

They're going to want to do it. Like, cause that's just how they are.

Cause they can't find the perfect one. It doesn't exist. They're going to want to do it.

So we're just giving them that. Like, we're just saying, Hey, we're going to let you build your CMS, but with like literally one line of code, because we built it all for you and the defaults are already good.

And if you want to override everything, go ahead, but you don't have to.

And don't worry, we'll handle all the hard stuff on the server.

Don't worry about it. And that's kind of like our approach to really just, you know, have the developer own this thing and make it look and feel the way that they would if they made it themselves, but without having them to spend four months doing it, they can do it in like 20 minutes at most.

So that's our approach. It's pretty interesting. And, you know, a little bit, um, kind of something that I'm noting here is that you guys are really building a developer platform on top of a developer platform.

Yeah. A little bit meta.

But, you know, I guess maybe from that perspective. It's pretty interesting to see someone be doing that and kind of delivering on top of that type of stack right there.

Yeah, it's, it's really confusing to us like I can't tell you how many times like we'll be having conversations internally and we confuse each other because we'll be like, because we'll say something, but it's so meta that the other person doesn't understand it.

So like we all have to write down like arrows that point to other things like okay we're making this that makes this, but it's for this and then it makes that and that's what we're doing.

And they're like, okay, now I get it and it's so confusing.

But we know that in order to reach our goal of, you know, letting developers have that extreme flexibility, but yet being able to just get something out of the box that just works.

This is how it has to be done. Someone's got to bite the bullet.

Someone's got to do the dirty work and we're doing it.

That's, that's great. So, thanks for the time today. Scott, I think this was really useful for, you know, just myself personally, I hope the folks watching on the Cloudflare TV side have found some interesting new use cases and ideas around how to build on the workers platform.

And you know if you're, if you're looking for a headless CMS.

I'm looking for a developer tool, look towards types direction.

I think I took a look, I think we're about one minute away from the next segment.

I'll let Cara kind of introduce that one. Yeah, so thank you so much Scott for joining us.

This is the second time I've spoken with you and it's always a pleasure.

So thank you very much for being a part of this with us. This is the first one that we've done.

So super excited to see like what else is out there.

The next conversation we have on Cloudflare TV is with Michelle Zahlin and she will be talking about MentorFlare and how students without internships, working from home this summer, how you can get involved and, you know, offering mentor opportunities through that so everyone stay tuned for that.

And thank you very much Scott and Kabir.

All right. Take care. Thank you.