0:03My name's Alex. Thank you for attending this talk today. It's called From Intent to Infrastructure, Rethinking CDN Resiliency with AI. And the word of the day is going to be intent. So I'm going to say it a lot. And I had a slide, but it got messed up. But the definition of intent is like, what do we agree upon as the outcome? And so what we're going to focus a lot on is how we use. intent and this framework that we're building around intents to define CDN behavior. So a little bit about me. I've been a Cloudflare for a few years. I focus on our strategic segment of customers to deploy large CDN architectures onto our All right. So let's take a step back and define the problem statement that we have right now.

0:50Managing CDNs at scale is hard. It's hard for three. boiling it down three reasons first is migrating complex um configurations one from one cdn to another has a lot of layers to it the second is that oftentimes what i have seen in practice is that there's this a concentrated team of engineers who are deploying these configurations for hundreds of application teams and the third is when you have a multi -cdn setup um having parity between these different CDN. So, and then another quick aside is that this talk is actually going to be around a specific segment of our customers who have multiple CDNs in place. And so we're going to be focusing on the operational side of that. But anyways, of these three challenges, by show of hands, who has these challenges today? I want to see. All right. Very cool.

1:41So we're all in the same boat here. All right. So taking a step back at the problem statement, why are these actually challenges for us. First is that over time, CDN configurations kind of become the default specification where we have years of behavior defined as rules. And then there's also provider defaults baked into those rules as well. And those kind of, you know, those configurations plus those defaults is the CDN being. that we come to expect and so when we go and package or investigate that we have to like re um uh we have to reverse engineer kind of the configurations that we have in place in order to figure out what is the actual behavior that unique the second big problem that we have is around ongoing maintenance around cdns and and just edge configurations in general there's this one you know we can put a lot of effort up front into kind of the initial deployment so day zero where we might take a set of configurations and then migrate them to or build an equivalent Cloudflare one.

2:56And that's like a one-time project. It ends at a point in time. But then there goes, it transitions to this phase where we have this ongoing maintenance that has to take place. And that transition to like day one and beyond is a whole set of challenges in itself. So we got two challenges. One of them is that the behaviors kind of locked into. a specific CDN configuration and the second is that it's very hard to update and maintain over time. So the kind of big idea that we've been working on with some customers is kind of separating out that behavior from the desired CDN behavior outside of the specific, outside the CDN configurations themselves. And so that's where we call this idea of intent and then this other idea of tests.

3:43So to go through kind of this framework that we're creating, an intent is like a requirement that captures the expected behavior. Tests are how we define that behavior will be observed. And then from that, that will be our source of truth on the left side there. But then from there, we will go and generate maybe a provider specific configuration. And so what's neat about this is that the same intent can guide multiple providers for us, where when we have kind of these requirements and tests separated, then we can actually use that and put it into AI, which is really good at generating configurations. But it's good at making these configurations when we define the specific behavior that we want. And so in this mentality of instead of just directly configuring a CDN, instead, if we can go outside and define these intents, define these tests, and then use that to factor in the types of...

4:40that we want to build. And what's really neat about this is that after we feed it into some models to do the translation to, so we have the intent and test, we put them into the, you know, whatever configuration translation tool we might build, then we get a configuration out, but then we can use those same tests that we started with and run the new configuration that we've generated as kind of a feedback loop back to the thing that initially created that configuration. And so, What was neat is that when we were in the session earlier this morning, Eric Yu, who was presenting on the test and kind of the infrastructure that he outlined, he outlined the same kind of things that they're doing at VoidZero, which is like building the test infrastructure that you can then iterate deployments on.

5:30So it's a very similar kind of pattern that way. And under the hood, actually, we're using the technologies that he and his team built. So then from there... So actually, to take a step back, the whole kind of test-driven workflow that we have here then is that at the first step, what we're doing is we're going in and defining behavior. And this is led by a very human -centered approach where we can go in and, you know, say these are the types of things that we want cached or these are the types of headers that we want added or whatever configuration you have. This can step one. be augmented with AI tools as well where we can take like an export of a configuration and then have that analyze it and say this is the type of behavior I expect from that. So first is defining kind of a collection of the of the behaviors that we need at a CDN edge.

6:17The second is that then we take that behavior that we've defined explicitly and we generate and test from that behavior. And these tests have assertions in them that say, for this type of behavior, this is how you measure it, and this is the output that I'm expecting. And so that is what we've also found with our customers is using AI to take the behavior and then recommend tests to validate that is a pretty quick workflow. And then humans go in and then do that approval of it. And then we'll see you next time. finally we can take that behavior and those approved tests and then build that configuration layer and then when we have that output from there we can validate the behavior of it and if there's any modifications that we need to do to that behavior we can go back to step three and build additional configurations and any changes that we might need and then finally there's a way to capture like a report around the evidence that we want to collect to validate and show that a a test has or that a configuration is valid and that we can then make a promotion decision around sending that to production.

7:35And so we at Cloudflare have built a tool called CFSpec that applies this model, this testing framework, where we take out the behavior and the test and then create a framework around and then use that as an input and then create a Cloudflare configuration and then run that kind of feedback. back loop. And so CF spec turns human readable requirements in a reviewable test. Users can approve tests to generate Cloudflare configuration. And the third is we can validate behavior in a dedicated development zone at Cloudflare. So I'll go to the next slide if we want to switch over to the demo real quick. Sweet. So now we're looking at my screen here. All right. So I'm going to go through this video and pause it a few points. So first we're looking at the this is a the the tool that does that translation layer for us um there's a several uh components of this the first is the configurations themselves the second is reports so after we run the test we'll have um evidence that shows how the test ran and the types of and whether or not the configuration passes it fourth is the requirements themselves so that's the intent that we talked about previously and then finally is test and so then cf spec takes uh each one of those components and maybe generates the next one and so if i proceed here we'll see that um the first step we're going to do is modify one of

9:06the requirements so i have a very simple example here and i'll pause this so right now what we see is under here it says requirements response header tests and then the requirement is clapler must add the response header cf spec test with the value false to every request on a zone and then the context is this is where we're actually going to test that particular endpoint i'm going to change that requirement and turn it to true i'm going to save the file and then the next step i'm going to do is say cf specs sync so sync is now evaluating that test or that that new requirement and it's deciding whether or not a new test needs to be generated and this will take a moment to run

9:51and then we get an output here and under here our tool will then go through all the requirements and then build a respective test for that individual requirement and right here we can actually look at I think I highlighted in the next step you'll see that the assertion that we're making actually is for any for a get request on this particular path return with the response hetero cs back is true And then this is the actual code behind the test framework that is verifying that that header is present. So then we're going to go in, and this is kind of a critical step, which is that we want to approve the test. We reviewed and said this is the behavior that we actually want. So we go ahead and click approve.

10:39So at this point, we have the requirement and the test, and now we're going to generate our configuration. So what's happening? behind the scenes now is that Cloudflare is taking that behavior definition and the test. We are using LLMs to generate Cloudflare configuration. And then right here, I'll pause actually. What we're doing is we are taking that configuration that was generated and actually applying it to a Cloudflare zone, a development zone. And so we generate that configuration, we're applying that configuration to a zone. and then this tool will then go and run those tests against the zone that we just deployed the new candidate to. So right now the Terraform is being applied and then we are running the test and I'll pause it again.

11:30So the test ran and it passed the test and we can go in and do a little more detail here but the configuration candidate was found three changes to three files. were changed uh and we have a bit of information here where the report is around how the test actually performed um and the requirement that we had and whether it passed and what's neat about this is that we can actually define how many in how many loops of the validation test that we do so if we in this instance uh it passed on the first one but if it failed in that scenario it would take that feedback put it give it back to the general phase and it would use that new feedback to iterate and then and then build a new configuration um so if i proceed here we'll see that we can then review the candidate and there's a diff we'll see the diff on it we'll see that here's the new one and in fact we'll see that the terraform here does say that the cf spec test header is true um and then we proceed and then we can go and review the form file itself and we'll see actually just the same thing we just saw um and you'll see the same thing with the value header true there i'll skip ahead a little bit here and then the final step is that we can actually run the validation step uh independently and that will generate a report um as to what how each requirement requirement was able to pass

13:03in um as part CF spec. So what's happening here is it's taking the configuration, reapplying it to the zone, running the test, and then generating a report. And then that report is just a nice little readable document here. So going back to the slides then, we'll wrap up in just a minute. Well, one second. Cool. So we'll go back here. And so what this framework gives us is it addresses this kind of ongoing challenge. that we see with operating CDNs at scale. First is that it gives us this portability around when we preserve expected behavior across migrations and when we preserve the behavior and the tests that we want, you can then actually take that and maybe apply it to a different provider if you are in a multi-CDN setup.

13:55So having these as independent things allow it to be portable. The second is that you... this framework gives us a lot more scalability in that we um can help automate the uh the the feedback loop around like changing behavior and growing it from there and the last is it's verifiable because uh each test is able to be approved in a visual way so um so yeah so guided by explicit intent and approved tests we can use ai to shorten the path from intended behavior to infrastructure at cdn cdn deployments at cloppler so the One key takeaway I want you to have is like, by using natural language and then having a test suite behind it, we're able to build this whole other infrastructure that helps us configure things like Cloudflare.

14:41And this can even extend beyond CDN. We use this a lot because multi-CDN setups are common with our customers. But if you have other types of applications, you can do the same kind of feedback loop in order to give our tooling better data on how to improve. a cloffler configuration. So thanks everyone.