ℹ️ Zone Versioning GA
Presented by: Sachin Fernandes, Daniel Gould
Originally aired on January 9 @ 11:00 PM - 11:30 PM EST
Welcome to Cloudflare CIO Week 2023!
This CIO Week we’ll demonstrate how Cloudflare is helping CIOs keep data, devices and employees both safe and fast across hybrid and remote environments. We’ll show how Cloudflare accelerates digital transformation and modernizes networking and security towards a Zero Trust model.
In this episode, tune in for a conversation with Cloudflare's Sachin Fernandes, and Daniel Gould for a discussion on Zone Versioning, which is now generally available!
Read the blog post:
Tune in all week for more news, announcements, and thought-provoking discussions!
For more, don't miss the Cloudflare CIO Week Hub
English
CIO Week
Transcript (Beta)
Hi everyone, hello, welcome to another session for CIO Week here at Cloudflare in 2023.
My name is Dan Gould, I'm on the product marketing team and I'm joined by one of my esteemed colleagues Sachin.
Sachin, you want to say hi? Hello, I'm Sachin and I'm an engineer on the API team and we're here for some exciting stuff today.
Indeed, indeed. And hopefully you realize innovation weeks are a lot to take in.
Just innovation abound across the board. If you've kept your eyes on the blog this week for CIO Week, a lot of Zero Trust, CASB, email security, cloud networking, you name it, ways to help CIOs thrive their business, transform their business for the future.
So really exciting stuff. And one of the pieces of news is zone versioning, which is what we're here to talk about today.
So something that's very exciting, something near and dear to Sachin's heart in particular.
So actually we're going to do a couple of things. We're going to talk about zone versioning.
We're going to talk about the news, what it is, why it matters.
And then actually Sachin will walk us through a really cool demo that he's put a lot of TLC into.
So excited to see that. So let's actually just get started diving in Sachin.
Let's talk about zone versioning and what it is. So it's my understanding that customers can basically now manage their zone configurations with safe versioning changes.
That's how I sort of see it at the highest of levels. How do you define it?
So that's exactly it. So today we kind of have this concept of a zone and that's usually what people are most familiar with when they come into Cloudflare.
And a zone has a bunch of settings, right? And Cloudflare will change and do different behaviors based on your settings.
And till today, all those settings apply to sort of one zone, like it's your zone and it has that one version.
And so like you kind of hinted at, the idea is that instead of having this one version of the zone that applies everywhere all the time, we kind of give them a little more flexibility.
And I don't want to give away too much before we get into other things, but that's the idea is safety and confidence in some of the changes that they're making towards their high priority zones or even low priority zones.
All zones need a little bit of love. Indeed, indeed. So when we talk about settings, what are the most common sorts of settings we're talking about?
I think about content caching, I think about security, WAP rules, WAP rule sets.
Is it sort of the bread and butter of what Cloudflare has been doing well for a long time?
Absolutely. So generally you have all of the settings that you're kind of going in and changing sort of manually with your firewall rules and caching and things that you mentioned where you click something and the edge kind of behaves differently for you.
And so zone versioning specifically sort of deals with those zone settings for people.
Interesting. So this, I do want to call out, we've been working on this and thinking about this for a while.
This actually is an improvement and a bit of a renaming from what we've been doing over the past year or so.
Isn't that right? That's absolutely right. So some folks on this video stream probably have heard of HTTP applications and that was somewhat of a V1 iteration.
And this was sort of like a hard problem to solve for us. So we wanted to try our best to get it right for folks.
And so we released HTTP apps as beta and a lot of the feedback we got was, you know, it's a little less intuitive and it's like a new concept and we're introducing something that's different from kind of what exists already.
And so a lot of the work that we did was sort of refactoring the UI and integrating the product a little better into what people are used to in their sort of everyday flow and sort of making it easier to use than to onboard this big concept.
Most of the backend technology is still use the same stuff, but a little bit of UI refactor.
So for anyone that has been using HTTP apps, just note that you can now move over to the zone versioning UI.
Yeah, very, very cool.
So I wanted to dive in a little bit more to something you just mentioned and really it's sort of the challenge we're solving.
And, you know, when are the most common, I guess, times when a customer wants to make changes, like when will zone versioning be most useful?
So think about it in terms of high risk operations or high risk actions in general, where a customer comes in and they want to change something, but they're really worried about clicking the button.
They're like, well, when I click the button, this can either go horribly wrong or it'll go fine.
And having that level of fear is sort of not great.
And so think about someone getting attacked.
So they have a DDoS stack or something else happening, or they just want to introduce a new firewall rule that ends up blocking a certain segment or allowing a certain segment of their traffic, but then they do it wrong and suddenly it's blocked for legitimate users.
And now they're losing traffic or it's not great for them.
So that's one use case where you kind of have these high risk operations.
And also there's certain customers that just want to try a feature, but they're worried about turning it on because they don't know how it's going to affect their traffic.
And I'm going to say a word now, but they're just like, well, I just want to develop on this for a bit.
I just want to kind of try it. And I don't want it to touch anything else.
And that's really hard to do today and not really possible.
So those are generally the two classes of things where they just want to try something and it feels scary.
That moment that you're like, oh, I don't know if I should click this button or not.
That's the feeling we're trying to take away with this product.
And it sounds like if I've got, say, a new application I'm getting near set up in cloud, but this will be really, really straightforward in terms of getting the right protections in place, the right caching settings in place based on maybe something that you think works well in another application.
You want to two degree mirror that, but then test it out and maybe refine it a little bit.
Sounds like this will be a really straightforward process. Yeah. So we'll see this in the demo as well.
Little surprise hint, but the idea is that you make fewer changes more often rather than, you know, sort of big bang changes all at once.
And those usually don't end up going as well. And you kind of want the ability to do these sort of gated small changes over time.
Yeah. And, you know, I know to date there have been some workarounds in place, you know, just to, you know, customers to assuage any concerns they might have before they hit that button.
What have those workarounds typically looked like?
Is it, I think, you know, we're talking about before setting up their own staging.
Yes. So it's really interesting, right?
Like when there's a problem and there's no real solution to it, people always come up with a creative hacky way to try and figure it out.
And so one of the ways most customers use this and including us at Cloudflare, which is why I'm really excited about zone versioning because it makes my life easy too.
You're on the API team. I am on the API team and I would really like to test out my changes before they go out.
So the idea of staging is let's say someone has example.com and that's their production zone.
They'll also come in and sign up a completely different zone on Cloudflare.
So let's say usually it's staging.example .com or dev.example.com, something like that.
And they come in and they will kind of configure their staging zone to be their playground or their place where they do this testing stuff.
And the broad zone will be the sacred place where you have to test stuff in staging and do all the things in staging.
And then here's the hard part, right?
You have to then take those changes that you tested in staging and move them over to your production zone, which if you don't do correctly, now you've broken your production.
So that is the manual process, right? You're like, okay, I've made these updates in staging.
This seems to be working right. So I need to look at this one screen and basically go to this other zone and make sure the caching settings are the same in production as I've seen them in staging, right?
Is that what I'm hearing? Absolutely. And a lot of these things might be a host name related too.
So now you're doing another extra check to be more cautious saying, you know, would it work on example.com even though the sort of host name is staging.example.com.
And so it introduces these little bits of discrepancies that it's not your prod zone.
It's different. And the thing about the staging zone also is now you have two things to keep in sync at all times.
So now if you sort of deploy your staging stuff and then go away for a long time and you've forgotten what you deployed and someone else comes in and like changes something else, now you have this big drift, right?
Between what's in prod and what's in staging.
And so someone else coming in, a new employee or someone who hasn't looked at the dashboard for a while is like, oh, let me like migrate these settings over and now suddenly you have an outage.
So those are somewhat the workarounds that people have been using today.
The other workarounds generally are writing some sort of hacky script on top of their zone to try and redirect traffic or like do other things like that.
Not elegant and extremely disconnected, right? The staging environment has no sort of connection with your production van.
They're literally two separate, completely different zones on Cloudflare and Cloudflare treats them as such.
And one thing I also wanted to ask about, occasionally things go well enough in testing, staging, and you push them in production and then suddenly you realize, wait, this isn't what we anticipated or maybe we need the undo button, the rollback.
I know this is another key feature zone version making that really straightforward.
Just a click, reverting to a prior version, you can breathe easy again.
To date, have rollbacks maybe been as easy as they need to be.
So I read this quote somewhere in a book where it said, everything is better with an undo button.
And it's generally true. That feeling that you have, if you had an undo button, it would kind of go away where you're like, oh, I'm deploying a thing.
And then your undo button is a ton of work to try and undo some of those things.
So let's say we create a firewall. We block all of the US or do something like that.
And we did it by mistake. My undo button, so let's say I go to sleep and I say, hey, this is great.
And I'm on call. I get paged for certain things.
And so as from my experience, you sort of come on later on in the night or different times than when the change was actually made.
And so you have to come in and gain all this context and look through what had happened and maybe even wake someone else up.
And you're like, oh, I have to now wake up this person and either sort of disable the rule, delete the rule, edit the rule.
And that might introduce even more inconsistencies where your zone now is not what it was before you deployed that rule.
It's still edited in that you've disabled the rule, but the rule still exists.
Maybe someone else comes in and says, hey, why is this rule disabled? Turn it on.
And now you have the same incident again. So one of the things we've tried to do here is one click.
You click a thing and your zone just goes back to the way it was, which I think is really cool and fascinating.
And having a thing be one button is pretty hard.
So I'm pretty glad that it is just that one button. And so we'll see that too.
So we're about to get into the demo. I do want to do something really quickly.
There are a couple of key terms that are important to understand. Versions and environments, which we'll see in a second.
So a version, those are the various rule sets.
Is that right for a zone? So all of this stuff, like you mentioned, does run on concepts that are familiar with most of our Cloudflare customers, including the rule set engine.
So we wanted to sort of rebuild on the really cool technology we sort of already have.
And so we came up with two concepts. One of the concepts you mentioned is versions and the other one is environments.
The way to kind of think about that is what is the change I'm making and where does that change take effect?
So in terms of what is the change I'm making, versions are essentially the snapshots in time of your zone.
And so like I mentioned initially, there's only one snapshot of your zone today, where it's just your zone.
So you kind of make a change and it goes out everywhere. And so in terms of versioning, what we do is you tell us when you want to make a version of your zone and you say, hey, this is the snapshot I want.
And we make another snapshot for you with the new version of your zone.
So it starts out incrementally. So it'll sort of be your zone and the zone is called baseline.
So that's sort of just your plain old zone that you have today.
And that'll be called the baseline zone. And then the moment you enable zone versioning, you will make a copy of your zone and it'll get a numerical value.
So it'll be called version one. And version one is an exact copy of your current zone.
And so from there, you can come in, choose to make some changes, make version two, make version three.
It goes down the line. And you can revert back to any prior version at any point?
Yes. And so going back to the deployment pipeline, you generally don't want to revert back to any version.
You want to revert back to the version before because you deployed a certain version.
And then in your rollback button, when you hit rollback, you don't want to think about what your previous version is.
You just want the Cloudflare to do the thing.
You're just like, I'm freaking out. Just do the thing. Roll this back for me to the previous version.
And that's what we tried to do is sort of be in the mindset of the user who would be in that rollback state where they're coming in, they're really freaked out.
Things are broken for them. And they want to come in and just hit a button saying, Cloudflare, please help me out.
I just want one button to click and it goes back.
And so that was sort of the mindset and the thing we tried to do.
And so in environments, in general, we provision sort of sensible defaults for most people.
And it has development staging and production right now. And those are generally the environments that people kind of use.
And so each environment sort of applies to a different slice of your traffic.
So instead of your version applying to all of your zone, it can apply to a slice of the traffic that the zone sees.
And so, yeah. Okay. Why don't we actually, I'm looking, we've got about 13 minutes left.
Why don't we see this in action? What do you say? Okay. It's nothing as exhilarating as doing a live demo.
So I am excited about this. Adrenaline junkies around the world are with us.
So can you see my screen? Does that look okay?
So I'm looking. So yep. You see version management there in the left-hand column.
That's the zone menu, right? So you click on that, right? Right. So today what generally happens is when this shows up on your screen, it'll basically have this version management tab and this different drop-down.
And so most people are familiar with this UI, and this is the zone overview page.
When you come into version management, you'll see a little button over here that says enable versioning, and it'll give you certain prereqs that you need to meet in order to turn it on.
So, you know, meet the prereqs and you should be, the button should light up and you should be able to do it.
Actually, on that note, the first time an enterprise customer, by the way, this is available to all of our enterprise customers.
The first time they log in, fulfill those prerequisites, there'll be a blue button that says enable version management.
Is that right? And the first time they click that and away they go.
And that is it. And what we'll do at that point is, like I said, we'll make this version one of their zone.
And so it's an exact copy.
And we didn't want to sort of roll this out in a way that it just applies to all of your traffic everywhere all at once and wanted people to sort of opt into this behavior instead of just saying, well, now you have versioning and have people be confused.
So you kind of opt into the versioning behavior. And so right now I have, you can see I've been playing around with this.
I have four versions of my suchanf.com zone.
I tried to design this demo in a way that people can kind of actually play around with it too.
So feel free to follow around the world and this will work for you so you know I'm not making any of this stuff up.
So we have versions and we have environments.
So these are the two concepts we were basically talking about.
And we can see there's a development staging and a production zone environment right now.
And development is sort of the general playground where people come in, test out their changes, and they can decide which version applies to the development environment.
And so if I click on the expression value, I can kind of see when this triggers.
And it'll trigger when we have a cookie of true with development in it.
So we also created this concept of staging IPs.
And so basically what people can do to get a staging version of their zone is query their zone and point the, resolve it to certain edge IPs that Cloudflare broadcasts.
And we will serve up the staging version of the zone. And the broad zone is just your production zone today as it lives.
So let's get into this.
So right now I have this endpoint. You can go to it if you want. It's sachinapp.com slash hello.
And there's a name of Sachin. So what it does, it just gives that back to you, whatever you put in there.
And so Chato is my dog. It says, hey, how are you?
So this is great. Now let's say Sachin's being a bad actor. And Sachin comes in, and I don't want Sachin to say hello to my server anymore.
And I want to kind of have it block.
I want Cloudflare to sort of block this user. And so I have version four over here ready to go.
And you can kind of see it has NA in it, which means currently this doesn't apply anywhere.
So what I'm to do is actually assign version four to my development environment.
And you can see a promote button showed up.
And there's a rollback, which means it would go back to unsigned.
But I don't want that right now. So I want version four to be my current development application.
And so what most people will come in here, and they'll see their flow already set to unsigned in all of these.
I already have certain versions promoted to staging and broad.
And so for the first time, we don't apply any of these environments to, or any of the versions to any of these environments for reasons we already talked about in terms of safety.
So what I'm going to do now is I'm going to actually, firewall rules are the most fun to sort of come in and look at.
So I'm actually going to switch to version four, and I'm going to create a firewall.
And I'm going to say, block such.
And I'm going to say, well, you know, if we see a query string of name equals such and then block such.
So now I did this. And I'm like, well, did it work?
Well, it looks like it didn't apply. Well, that's because it's only in my development environment right now.
And so in order for me to trigger my development environment, what I can actually do in my browser, and this can sort of be however you want to set it up and have many different environment rules.
So you can do headers or anything that our edge rules engine and our rule sets engine supports.
So if I now refresh, something magical happened. Suddenly Cloudflare swapped out the hello, and it says, hey, you're not allowed.
And so this is the most exciting piece for me with this demo, where literally what Cloudflare did is it looked at an expression that we gave it.
So I set a cookie and Cloudflare completely changed the configuration that it was using at the edge for me.
And I can go in and just to confirm, if I switch this to false, and false is the same as not existing, it goes back, which means everyone else around the world is seeing the normal sort of such and still allowed.
And the other cool thing about this is you can also come in here and all of the firewall events still work, and all of the analytics still work.
So what I can actually come in here and do is look at my sort of analytics, and I can slice it by zone versioning.
I see, oh, I have four requests on version four.
And if I filter them out, I can kind of see that they go to hello, and they have the block such and rule, and they're right, the analytics are still coming in.
So right there. So we see all the analytics.
So this is pretty cool where I can actually go in and debug what's happening.
And then I can also see my overall analytics and do the same thing.
So I can go in here and I can slice by version, and I can see that version four is 403 right here.
So that's pretty good. It's great for debugging and things like that.
Now, let's say, I feel pretty good about this change, and I want to promote it through my environment.
So I hit promote, I can go to staging, I hit promote, I can go to prod.
So now, even without the cookie, or for everyone else around the world, I'm just going to delete this, and I hit refresh.
And now it's just Cloudflare says, Hey, such and stop what you're doing.
It's not great. Now, let's say such and a good actor.
And such and writes us an email and says, Hey, I was actually testing some stuff out.
And you blocked me actually like saying hello to your server, can you undo that?
And so someone comes in, this is the paging scenario, right?
Someone comes in, and they're like, Oh, let's just roll this back.
And so I said, you know what, just put me back on the previous version I was on.
And it goes back to version two. Right. And so I'm also going to very quickly just do a purge because a Cloudflare is a great CDN, and it'll cache everything.
And so four minutes left, such and I know there's a lot to cover here.
So yeah, and so any second now.
Oh, also, I think I need to do disable caching. There we go. So and then it rolled.
And so this is no slower or faster than just deploying a setting at the edge.
And so it just, you know, in terms of RSLA, every, like, five to 10 seconds, I think we deploy worldwide, which is so for a while there, any zone using version four in production would have blocked you.
Yes. So just roll it back.
So version four offline, right? Right. That's a staging. That's, that's exactly correct.
So you can see version two has gone back to staging. And it still exists in development.
And so it not only rolled back, just that environment, it put your pipeline into sort of the state that it was actually in.
And I can continue testing on staging as I can, you know, go in and say, Oh, man, I messed this up.
Let me try and figure out what exactly happened here.
But the immediate breakage, it has been fixed, such and can now go in and check the website again.
So yeah, that was that was the demo.
And I hope people played a lot played along and had fun. Yeah, no, for sure.
For sure. So just to recap here, this is available today for all of our enterprise customers, right?
As we're seeing in that left hand nav menu, you'll see, you know, zone versioning.
If it's the first time go in, there'll be a blue button if you fulfill all the prereqs.
What again, were those prerequisites or a couple of things you need to have in place?
Yeah, so we, you have to be enterprise, we sort of mentioned that, but you also need to use the new WAF.
We didn't want to sort of encourage or support this, the older technology, and we don't currently version the old WAF.
And so we didn't want to allow that just in case we wanted to block in case certain settings didn't get copied over, things like that.
So new WAF, you have to be on the new WAF to use this. So be on the new WAF, it's great.
Yeah, good, good, good. So yeah, go in there, check it out.
Just in terms of more information, there are DevDocs for this, correct? Yes, the DevDocs are available.
Look at the blog post, the blog post link went out today as part of CIO week, the DevDocs should be in that as well.
And if you just search for Cloudflare, versioning, zone versioning, it should show up as well.
Indeed, indeed.
So with that, Sachin, demo is great. Thank you so much for joining me.
Really exciting piece of news for CIO week in 2023. So thanks for this, and hopefully we get a chance to do this again soon.
Thank you, Dan. Okay, see you. Talk soon.
Thanks, everyone.