Transcript for "Recording - Reducing security and network complexity during cloud adoption": Okay. Let's get started. Hi, everyone. Thank you so much for joining us today for this webinar on common challenges during cloud adoption. My name is Martin Sanchez. I'm a member of the platform marketing team here at Cloudflare, and I'm really, really lucky to be joined by my colleague, Dan Kent, who's one of our field chief technology officers. He spends a lot of time talking with customers about, challenges like cloud adoption and then also has dealt with a lot of these challenges himself and his, know, prior experience as a field, excuse me, as a technology leader. So, Dan, thanks so much for being here. Hey, Martin. It's great to be here. I'm looking forward to the conversation. Awesome. Okay. So I'm just gonna share a few slides early on to lend some context before we get into the conversation with Dan. So we're here obviously to talk about cloud adoption, and this is something that we know a lot of you, a lot of organizations in general, are really in the thick of heavily for a variety of reasons. And, you know, as we also know, cloud adoption and cloud migration can look a few different ways. You know, sometimes you're going through what we would maybe call the hosting process when you're just migrating application and network workloads kind of as is to the cloud without any really severe underlying changes. This might be done, you know, in in order to add, you know, better economics, you know, like, to to, you know, improve the economics or to make it easier to control a lot of those applications and and network workloads. But then sometimes, we also know a lot of organizations are taking this opportunity to optimize apps a little bit more to kind of add new services, new arch architectural features, or even to totally kind of rebuild them in order to really optimize them for some very cloud focused features like, you know, serverless and AI, obviously, is something that everyone's talking about right now. So, we just kind of want to acknowledge. We know that cloud adoption and cloud migration is a really multifaceted and complex process. And because of that complexity, something else we hear from a lot of companies is that it takes a long time. You know, obviously, when you're these different types of, migration that we're talking about will have different timelines. But on average, you know, some studies have found that the average, cloud migration projects for large enterprises can take around eighteen months. And, you know, it can be a lot higher than that depending on the sort of adjustments and optimizations you're making. And, you know, this isn't even just like a you know, everyone's preparing and then boom, everything goes live in the cloud instantly. Often, you are moving certain applications, certain parts of that application over to one or more, you know, cloud environments, which means that, you know, during this process and perhaps even afterwards, it's not just a a fact of, like, everything is in one place and the merits in the other. The entire cloud environment is getting a lot more complex. Another thing we hear is that, you know, digital projects like cloud migration don't always deliver falling on their expectations. Even if an organization was hoping to kind of fully, refactor an application for, you know, really kind of complex or or or really kind of clean multi cloud environment for a variety of reasons, you know, it might not fully live up to that promise. You know, maybe the budget for the project changes and they just have to dial back on their expectations. Maybe some, you know, some of those complexities we talked about come up and doesn't mean that they have to, again, just rethink what they were trying to accomplish. Or sometimes, you know, things just take longer than you expect. Organizational priorities shift and suddenly there aren't as many people working on this this migration project as there were before. And again, some compromises need to be made. And so I bring this up not to be discouraging, but rather just to say that, you know, there's a variety of reasons, you know, that organizations might not even be planning for that can still result in a lot of complexity in the resulting cloud environment despite what they may have hoped. And, you know, when we talk about complexity, you know, that isn't just, you know, something that really matters for, like, a reference architecture on a diagram somewhere. There are some real world consequences to this. You know, so I think everyone knows, you know, it's not just about having an application or a cloud or in a data center or in one cloud or in multiple clouds. You obviously need to secure that application in a you know, and secure all of its different attack surfaces from a variety of, you know, different types of threats. I know they're all you know, if data in the or application, elements are living across multiple clouds, you may need to make sure that the connections to PEM are secured as well, those APIs. And then even then, you know, you need to make sure that, you know, during that, you know, kind of transitionary process or just in general, that all of these different aspects of your newly complex cloud environment are, you know, connected to each other efficiently in a way that you can track and monitor and really optimize. And then also making sure that the end users, whether that's, you know, internal users or customers, are having a really good experience, that they're getting good performance, good resiliency, good reliability for all the elements of these newly complex and distributed applications. And so the more the complexity of the application and cloud environment itself increases, the more the surrounding stack of security, connectivity, networking services starts to, complexify as well, which can really make it hard to do a lot of those basic, you know, tasks, securing, connecting, optimizing, improving user experiences. So, you know, this is the problem that we hear about a lot. And so, again, I think this is where we get into the conversation with Dan, who's seen a lot of this stuff firsthand and has been talking with a lot of people about it firsthand as well. So, Dan, you know, this is kind of when we turned over to you, but could you just start a little bit just for context about telling us a bit about, you know, your role at CloudFlare and your your prior experience as well? Sure. Thank you. Thank you, Martin. Yeah. So at at CloudFlare, I'm the field CTO. And what that means is I get to talk with a lot of customers and help them understand how they go through their journey, whatever their journey might might be. Oftentimes, it is talking around cloud migration, application migration, and I've been here for about eight months now. Prior to CloudFlare, I was CTO for three different companies. One was a, I'll say, a secure identity company where we had two or three dozen products that I managed and brought to market. And and then I'd also worked as a CTO for a company that was a solution provider in a managed service, off road. So I've got a lot of experience doing this. I've got a lot of experience talking with customers and other enterprises about how they're going through their application migration and cloud migrations at the same time. So I think, it's an interesting time right now. Now I mean, I'm excited to talk about, all this with our customers, especially as AI comes in. It's it is what I've seen in the past. What you typically are doing a cloud migration is typically aligned with some other form of transformation. Right? And so that you brought up earlier, if your transformation is, you know, I'm creating a brand new application, I I might be also introducing, through DevSecOps methodology with it. That's a person, people, transformation. If I'm looking at how I'm gonna leverage AI and now I need to start to think about how I'm gonna transform, how I build apps and operate apps, how I integrate data much more so with my apps that I have in the past. So that other transformation has another component and it makes it more complex. So I get to talk with customers about, my my experience with that and with, what CloudFlare can do to help them through that journey as well. Awesome. Well, thank you for letting us, draw on your deep experience with this. So to start, you know, maybe we can talk a little bit about some of your own personal experience with this. So, you know, when we were talking before the webinar, you said that you dealt with a a couple of big cloud migration projects in one of your prior roles as as a CTO. So, can you maybe just tell us a little bit about how you kind of structure that migration? And to the point you just made, what were some of the business factors determining how you decided to, roll it out? Sure. And and and like I said, most cloud migrations really start off with application migrations. I think that's first and foremost the I didn't start off to say, hey. I've got, you know, 25 applications sitting in my data center. I wanna put them all up in the cloud. That's not typically what happens. So you're managing or you're delivering applications to customers or to your own environments, and they all have their own life cycle. Right? So some of the applications are, you know, brand new or if it's and and, of course, you got the SaaS application to bring in, but if you're building your own applications, they might be 20 years old, they might be eight years old, they might be brand new. And and depending on that life cycle, just like anything, you redo, refresh, and, try and make it optimized. Right? So, and so I've been through, I will say, all three examples of your cloud migration with three different applications. One, which was a very large application, supporting state governments, was around how do I take in it and address some of the costs associated with these very large monolithic applications that are sitting in data centers. And so in that scenario, it was all about how can I rehost it? How can I put it up into a classic lift and shift model, so I can lower my costs and start to get out of owning data centers? So that was an example of of that. Clearly, it's not going full into the cloud, but it is about addressing some of your, concerns that you have with owning and operating applications in your own hosted data center. And there's value doing that. Conversely, I also had another application that was already in the cloud, but it was a classic model that they could. It was probably a a 10 at the time, it was about a ten year old application, very large application, that was in the cloud. And we, again, looking at how do I optimize that. And so you're looking at how do I optimize, bring my cost down or how do I add new capabilities to the application when I modernize it. And you have to make that decision. Do I, you know, just try to refactor it or do I try to re recreate it? And in in some cases, you make the decision that, hey. It's the life cycle is at a point now. Let's refactor and restart. Or, in this scenario, which is a very large, multimillion user end user application, I had to look at it and add new capabilities to it, and I could do that by, you know, really looking at how I could new add new capabilities without rewriting the whole application. So I had to go into adding more microservices capabilities and and start to put it into containers so that I can do interesting things with it. So in that scenario, that was a very large application. But my previous company that, the customer that we were working with had some constraints, so we couldn't rewrite the whole application because we had time constraints and all that. But we it was made sense to do it at that point, adding new capabilities without rewriting the whole code. And then, of course, the other scenario, I had another application. And by the way, this is all same company. Right? So I'm doing simultaneously these these modernizations. That's that other application, it was 22 28 plus years old. It had a function of being used around The United States and the globe. But it was time to read, and we just made a decision. Hey. Let's let's refactor. Let's redo it. It was on prem. Oftentimes, we could sell it with the hardware that went along with it. We wanted to take it to the cloud. And actually, actually, while we were taking it to the cloud and re rewrote the whole application, refactored it, we actually allowed us to go into another market. Right? Because at a certain price point, it allowed us to go down market with that product. And so the the benefit of doing that, of course, was I can get to a new market that I wasn't in. Leveraging cloud capabilities, I was able to get it up very quickly, much more quickly than if I rewrite the whole thing. I'm not in the cloud because I was leveraging serverless technologies, which means I didn't have to worry too much about the infrastructure in taking that to market. So three different modernizations, three different applications within one company at the same time. And by the way, they were on two different cloud providers. So it was clearly a multi cloud type of environment taking these parts to market. Okay. Thank you. That sounds I mean, it's obviously a lot, and I think you're setting up my next question really well, which is, like, since all that was happening at the same time and then, you know, the overall environment's just suddenly getting so much more complex and remaining complex. Like, how did you think about security? Like, were there any particular security challenges or concerns that emerged in as a part of that transition? Clearly, the the it's always part of it. And I'd like to say whenever you do these, you you have to look at people, process, and technologies. Right? And across the board. And so you're always looking at, you know, what's the value in bringing to my customer or if it's a new product or if it's internally, functionally, what am I doing first? Right? Is it getting is it getting the benefit that either meets my goal with business need or whatnot? That's that's number one. Second then is how do I make sure that I'm not adding more risk to the current environment? So that's where the security aspect comes in. And then how can I do it, I would say, harmoniously together? Right? Because we we back in the day, we we really didn't focus a heck of a lot on security. It was a different group. And so, then now this goes back about six years, five or six years. Just moving the people and organizationally what we had to do to make it better. Right? So that was right around when DevSec DevOps became DevSecOps, and we started integrating the security into the development shops at the same time. So, again, another simultaneous transformation. And that's typically how these these happen. Didn't really have the luxury of starting my own company or, you know, starting something from scratch. Yeah. But when you're in these environments that you have as a starting point already, it it means you have to do other things like look at organizational structure, look at the products that are already put in place, start to really understand where you are. In in in very large organizations, there's a lot of silos and and oftentimes those silos have different product portfolios and tools that are used. So you had to really document all of that and understand what all of that is. So I would say you start with the start with where you wanna go look at the people. Are they in the right positions? Do you have to make changes to the people? Then you start looking at the processes and how you wanna change those to optimize it. And then eventually comes the the products and the technology that you're going in. So that's typically what we did on every product project that we had. And I would love to say that, you know, we standardized across all the platforms with all the single products. Never happened that way. It it over time, it does, but it's usually a a process. Yeah. And so I think that's such a good way of framing it. And so, like, you know and and then I think also I appreciate you just kind of talking about the the fact that it's never as efficient or clean of a process as you'd like. Like, were there any particular hurdles that you found yourself running into when you were trying to, you know, have more that kind of clarity and standardization across the the people process and technology specifically on the security side? Sure. I think the, we'll start with the people. Right? Everybody, every security person, and it doesn't even have to disagree. Every developer, every operator has their favorite tools. Right? And so when you're when you're trying to transform from one environment to another, you have to get through that the culture of, hey. I I I'm gonna need to change your tool into something different. So that's that's first. Then, of course, you gotta look at what is how do these different transformations impact each other? What are the all of the connectivity tissue that's in between them and how does it all work? Oftentimes, once you get there and you make the decision and you start going down that path, then it becomes, they integrated. Right? And that's where I would say a lot of when you talk about, 35% not meeting needs, we always get to the end point where we're meeting the mission typically. I would say that I hope we got 9500% of the time. It's just more of a length of time and how long it gets there. Right? Did it cost? How long did it take? And a lot of times that's because of the I I will say the integrations between the the various technologies, and process changes, take that the greatest of plans and all of a sudden stretch them out. So I'd like to make sure that, you know, you try to get in front of some of those integrations, but you never you never in front of all of them. And and that's what I would say the the biggest lesson learned within. It's not just security. It's it could be the database doesn't work with the new hosted environment that you're in a cloud environment. So, so and and and so yeah. There's always gonna be those issues when you're doing some type of migration. You gotta be prepared. You gotta be planning for it. Have a 10% increase, 10% window of extra time because it's gonna happen. You never know when it's gonna happen, and then then you just act and, and try to address them, whether it's through architectural change or through communications or through, changing a product. Yeah. A couple really good points. I think the part about the integrations is a great one. I think we'll come back to that in a sec. But I think also just start coming around, you know, the meeting your expectations for whether you do it on time or not. You know, I remember my grandfather, he's a former Navy physicist. I love to say, you know, think about what's, like, the longest amount of time that the that a project might take and then double it and there's your answer. So, like, some similar logic. Just maybe one more question about some of those challenges. Maybe on, like, the user experience. Uh-huh. You know, you're talking about these applications that are, again, now, you know, based on a more, you know, you're live living in a more complex, environment even if that environment gives the application itself more flexibility and freedom. Like, did you run into any particular user experience challenges in term whether whether it was, like, for the end user internally or externally? Yeah. I think we all have. Certainly, outages do happen. Right? When you're going through transformations, outages happen and that impacts user experience. So, and those outages could be anything from a like I said, a a core integration of one product that that you have been using, you put in this new environment with other products and other dependencies that it works differently and also have an outage. So we've all gone through that. I think it's a matter of how do you mitigate that as quickly as possible. I think the other area is when you're taking on new technology and and from my past experience, I, I created it, building out a new application that, you know, leveraging everything that was new. We really it was one of my, hey. I get to start from scratch and and really enjoy what we can do and you can get up a product in in six months versus eighteen months or to MVP. And and the new technology didn't quite, or you you found some hidden hidden nuggets that the new technology did that you didn't expect. And so that happens as well. So, in my case, I was using, it was it was not Qualified, but I was using a new serverless technology. And there was some startup issues with the serverless that, you know, we we inherently knew that there were it was a gap in start up, but we didn't realize the impact on the user interface. So, you know, you can work around that. You can do architectural redesigns or, do different resetting of the tools somehow, some way to get around there. But you'd have to expect those are gonna happen. And and like I said, typically, you build into your development cycle. That is gonna happen now. If it's not in development, it's internal product and this happens. You just have to be able to, have the visibility and and insight into what's going on so you may mitigate as quickly as possible. Yeah. And I I appreciate the way you're framing all of this because it's not like some sort of catastrophic success or failure or, you know, suddenly breach or no breach or everyone all your customers hate you or not. It's like or even, like, be just the is the product is is the process finished or not? It's just, like, all these ways in which the time can creep out or it can get better or the way the budget can creep out or it can get better or the ways in which in like, internal adherence to some of these new capabilities can be a little bit better or a little bit worse. And, I think that I would imagine that resonates with a lot of people who are listening. It's not about some catastrophic thing. It's just like, how can I keep optimizing and try and, you know, again, just thinking about, like, the the timing, the cost, and the, you know, the efficacy, all of us trying to get closer and closer to some ultimately impossible ideal? Sure. And and, you know, especially in the public sector, which I now support, you read these very large migrations like it's Social Security Administration with IRS, but those are just enormous massive applications. And you might have something that's much more. It's certainly much more complicated than most of us deal with every day. But if there's like a once in a world, once one one time application, you might see some of the more, I'll say, catastrophic in in the sense that it's not just a a two week or four week. It could be a substantially large delay or outage or something because it's so complicated. But, those are typically one offs. Those are I'm sure they happen. But most I think most of us deal with the you know, we're hired to build things. We're hired to get things up and running and working properly once they're up and running. And so it's it's just a matter of problems that happen. They always will, whether it's caused by an attacker or what's this helping to use, whatever. It's just how you get there quickly and and clearly visibility and tools and, and a good team with communication skills, and and preparedness is what you have to do to make sure that you address those quickly. Yeah. Awesome. Okay. I think this is maybe also when we can draw on some of the the recent conversations you've been having as well. You You know, maybe thinking about it through that lens of just, like, you know, marginal success or failure or marginal complexity or marginal cost. Like, are there any organizations you've talked to recently who you think are kind of in the middle of an interestingly complex or difficult cloud migration? And so it like, if you just walk us through a little bit, you know, like, what what are they trying to accomplish? Some of the challenges they ran into again, like, security, user experience, and then just observability in general. Yeah. I think, there's all sorts of reasons why you would move to the cloud and why you transform your your technology. I mentioned a couple. You got a new application. You you want to, you know, that's clearly one or or you're going through new capabilities that you need. I'd say the two biggest ones that I see other than that are, one, you're going through a tough time and you need to reduce costs. Right? So that's another area that hey. And this happens a lot. And and and and in this environment when I think we're gonna see it happen more, where we need to cut cost out of everything we do. Right? And so how do we do that? Sometimes you you look at getting rid of some of your, assets you've got out of place where you look at simplifying your environments, bringing down costs. If you can bring down your operational costs, it certainly is a a common reason why people will do, cloud migrations. Also, if they don't wanna have capital expenses, they can do it in the cloud and bring down their CapEx and work up with OPEX, for a reason like that. So that's, clearly a reason that I talk with a lot of customers about that. How can we, look at simplifying our infrastructure? You've mentioned me through that had the great drawing. How do I simplify my infrastructure? This gets to the consolidation aspects of the world. Right? Where, you know, most of our large enterprise customers have anywhere from, I'd say, two 20 to 50 security applications. Right? They're just managing, whether it's due to silos or due to, you know, over time by investor breed. And and so just by consolidating into you know, going from, let's say, 40 vendors and 40 applications, maybe go down to 25. If you bring down 20%, that's just a there's an operational savings there. But, hopefully, if you do it right, there's a cost savings in triple licensing. So a lot of customers wanna talk about how do I consolidate, and I'm sure we'll talk a little bit more about that. Yeah. I I think we yeah. We will. I think that's a that's a good kind of, unique sense. Yeah. We can put a pin in that just for a second. I'm curious, you know, if if again, just, you know, without naming any names, if it but if there's any examples you can think of to kind of put it in context for our listeners, like, have there been any companies or or CloudCheck customers you've talked to recently who have been kind of trying any unique approaches to solving some of those security and user experience and the observability trials that you were talking about in the middle of the cloud migration? And I guess, like, you know, what what have they been trying and how well has it been working for them? Yeah. I think everyone, when they go to a cloud migration, observability is really one of the top ones. I would say, security and observability are the are the two that go hand in hand together. And, and, yeah, it all pretty much every customer will talk about how I can if I'm gonna do this migration, let's do these simultaneously and what can I do? And so I would say from observability, again, how can I get more visibility into not just this one application, but all my applications or not just from a, application optimization application optimization, but my security? I wanna be able to see my host security suite and then get visibility into all of my tools. So that happened pretty regularly, with customers. I was gonna say the the other is, obviously, the security suite. Right? Hey. If I'm gonna if I'm gonna do this new application with Tran Tranfdom, let's do it right. Right? Because today, I have on premise load balancers. Right? I have this I wanna go all all in cloud. It just makes sense that that, the security stack goes along with it somehow, some way now. But like I said, most enterprise customers have multiple cloud type environments. And so now they figured they're asking, well, how can I have a a security stack that is not dependent on and unique to each cloud environment? Yeah. So awkward. A lot of our customers are about having a a common security stack in front of a multi cloud environment. It brings cost down from a licensing perspective as well as operational cost down because I don't have to have unique skill sets to manage my Azure environment security wise, my AWS environment security wise in my I have OCI or or Google. So, yes, it's a most customers are looking at, both of those areas in particular when you go to integrations. Yeah. I'll take the last one I wanted to bring up because this is a common one I'm dealing with a couple customers on. This is another reason why they look at cloud migrations, mergers and acquisitions. Yeah. Okay. And so that's another area that, you know, we talked to a lot of our customers that, again, a compelling reason to either go to a common cloud platform or taking some of your applications and modernizing them is mergers and acquisitions as well. Yeah. Okay. Awesome. I think that that is a really good point. It's something that I know, I've heard about recently from some of the folks I've spoken to. Okay. So so you mentioned consolidation or platformization, you know, trying to, you know, make in the security context that might mean, like, having one, you know, single cloud security stack in order to secure a multi cloud environment or even to secure a hybrid multi cloud environment. Or, you know, you could apply some similar principles more on the connectivity and an application delivery side. You know, may maybe, like, the last challenge question I'll ask you is, like, clearly, that seems like such an ideal. Why why did that not happen often? Because I still talk with a bunch of companies who say, yeah, it sounds nice, but, like, I have four different labs. You know? Yeah. I think consolidation is not an event. It is an ongoing life cycle. Right. Right. And and I talked with the, you know, the the CIO conference leading a conversation on on on this just just two weeks ago. And the reality is it it will continually be processed. Right? Because we have new technologies we that are coming up in new Jesus, look at today. They're all over the place. So new technologies mean, hey. I I might need to bring new tech capabilities into my environment and it's not the same company or product that it was here. Right? So that's the reason. I've got new threats, which means I need to have new responses to those threats. So so there's always going to it to be reasons to have new, different capabilities coming into your environment. And and you have to prepare for that. So it it in the course so you get the new coming in, but then you have the other areas that are maturing. In not only maturing from a technology, but we're trying from a integration of technologies. Right? So how do I have a common threat intelligence coming into my firewall, my right, my load balancer, my have common policy engines for my various security tools. All of a sudden, I can start to say, well, why do I need to have five different components here managing my my customer facing applications when that can just be one and take, you know, three or four vendors down to one and have a better experience and and a more effective experience. Because I gotta build I know I'm gonna have to be bringing in new stuff to address the new. So so it's kinda and this is what happens in every customer. Right? We start with let's say, we start with 40 different applicate security applications. We maybe get it down to 20 35, and then couple of new ones coming in and back up to 37. Right? So it's it's a constant, I wanna say battle, but it's a it's a constant, evolution of this. Right? So I'm a 100% about consolidation and and making it through a plan. Like, what does that mean? Document every single security application you have, understanding what you have versus where the market is going, where can you start to consolidate. Have a con I'll call it and this I think it's the best practice that I heard from one of the systems that I was talking with. A consolidation tracker. Right? And and there's so much benefit of consolidation. I think everyone would agree with that. It's it's not easy to do in every case for various reasons. But if you you're you're tracking it, it becomes it's almost like human resources. Right? You have to manage people every day, every week, every month. You should be doing that with these resources, these technical resources. Right? So yeah. How what about have I looked at my little balance through lately? Have I looked at my WAF lately? Have I looked at, you know, my next gen firewall lately? Is it is it time to integrate that into another one? You have to start thinking it that way because there are new ones coming out every day. And, you know, I think consolidation is an ongoing process that we'll all have to live through it, And eventually, you get to a better place. Right? I mean, like I said, if you can cut the number of tools and the number of vendors just 20%, so you still have, you know, 30 or 33 instead of 50, you're gonna save in, not only on the front end for the licensing, but on the back end with your operations because, hopefully, you're doing it right with the operational benefit as you're getting common tools in the back end so the operators don't have to learn different products for different, functions. Yeah. I mean, so thank you. I I really like the framing of consolidation definitely as a process in the same way that card migration is never just like it's not like a switch you flip or a magic wand. You wave same thing. You don't just press a button and then all of a sudden you have one stack with as the exact number of providers or tools that you want. I guess final question for you is, you know, maybe around prioritization because, you know, let's imagine that you have a tracker or that you wanna come up with a tracker to, you know, understand all the different tools you have and to start looking for places to start consolidating and trimming some fat. Like, what would you say to an organization who's like, you know, Dan, tell me about I like, I wanna do this, but, like, tell me where I should start or, like, what are some questions that you would maybe ask them to help them understand what should be at the top of their prioritization of their, consolidation tracker during a cloud migration process as opposed to something that maybe can be at the bottom? You think the, every again, every environment is different. Totally. Right? If you have an environment with lots of silos, it's really easy to see that you can have common functionalities with different products, to or different products doing the same thing in different environments. Right? So so you start low hanging fruit. Right? If I have, three different vendors for a firewall, well, maybe and I and maybe and maybe I'm big enough that I need to have dual vendor strategy. Right? Well, they can go from three to two. Right? If I've got so so it starts with the like for like, and and that's start right there. If I have like for like, go ahead and that's a fine place to start to consolidate. Then you start to see over the years, and and it'll continue like I was saying, these products that are out there that the the next gen firewall today is not the same that it was you know, five years ago. We've added capabilities and and and same thing with cloud there. In every one of our tools, we add capabilities to it along the way, and they start to eat away at some of the other tools that you bought. So if I've built in my load balancer into my my CDN or I build my, some other capabilities into my WAP or API gateway or API or AI tracking. Well, now I don't need to have in any three years ago, I I they were two different types of products. I bought two different duct vendors. It's that you start to see that overlap. Another low hanging fruit. So I think that's where you start. Mhmm. And then you can start looking at okay. Now I have environments that are should be common operating environments. Right? Customer facing applications. Alright. What does that mean? Well, I've got APIs management. I've got, DDoS protection management. I got DNS protection. Okay. So why don't I get all that suite into a common operating model so I can start to consolidate that suite of products. Right? So they're they're they're operationally typically by similar or same groups of people, and then I can go there. So so I that's where I would start. I do. Clearly, you got a 100% overlap and you get the 70% overlap that maybe I can get rid of that and I start looking at where the, my operation teams can be better if they have less tools to manage, because that's they they could be managing seven or 12 tools at a time. And and putting them on a common platform gives me some great capability. And and basically putting that integration effort back on the vendor rather than within my operation. Yeah. Right. That's that's really what I call platforming, a single platform as a form of consolidation. Because you can look at vendor consolidation, then you can look at a single platform for the term platformization. Because a lot of the vendors that will if you go over a single vendor, you still might have different platforms. Yeah. Totally. So you wanna kinda go with a single platform. And, again, it's not gonna do a 100% of your it's it might do only 20%, but it it takes your your 45 vendors down to down to 38. That's the savings. Right? And and and push that, all that integration onto your vendor community revenue doing it. Awesome. Dan, you so much. Really awesome insights, on so, yeah, just the challenges, the landscape on, you know, consolidation strategy where to prioritize. Really appreciate it. Thank you so much. Really yeah. Thank you so much for for sharing all of that. I think we will hope we have time for maybe one or two questions at the end. But for for now, I just wanna wrap things up quickly. So, you know, we've been talking obviously about consolidation, platformization, especially in the context of, you know, cloud migration and CloudFlare certainly has a perspective on that. You know, we think a lot about, you know, how can we help, you know, reduce or ameliorate some of those challenges that you've been talking about around integration, around observability, and just trying to make it as easy as possible for organizations to get what they need on a single platform. You know, in our word, you know, our our term for this concept is called the connectivity cloud. Frankly, it doesn't really matter too much what you call it. That's our word for it. But for us, that just means, you know, having a unified platform of connectivity, security, and developer services that are all built on the same programmable global network. And that is, in fact, what, CloudFlare is. That's that's where we've been, since our founding and been just flushing out the capabilities since then. So, you know, I'll talk a little bit about some of the specific capabilities in a sec. But, you know, at the core of CloudFlare is this massive global network that, you know, lives in over 330 cities around the world. You know, operating in just a massive scale. You know, around 20% of what web properties globally sit behind Cloud Fire, which, you know, means that we are processing, you know, tens of millions of DNS and HTTP requests every second. You know, we're blocking hundreds of billions of cyber threats every day. Really just having, like, you know, incredible reach and scale across both, you know, global public Internet traffic and then also, you know, increasingly a lot of organizations using us for for corporate network traffic as well. And so, you know, in the context of cloud migration, you know, this means that, you know, if you wanna talk about having a single platform, you know, the cloud for network is essentially designed to be that single platform for all the different security and connectivity services, that an organization might need and having them, you know, be manageable in the same place and really living on the same underlying infrastructure. And I think that that last point is an important one because, you know, what we see in a lot of, you know, so called platforms as you mentioned, Dan, is that, you know, they will have a kind of unified UI or they'll kind of stitch together a platform like experience on the front end. But then, actually, all these different services for a variety of reasons will be running on entirely distinct sets of infrastructure, you know, whether it's just like a few scrubbing centers somewhere or, you know, maybe they acquired a company and then just, like, how, you know, that service running in a separate data center somewhere or even on premise somewhere. But, actually, you know, every conference service is built to run on every single location and, you know, all over the world. And, you know, the few exceptions for that not whether that's that's not true are rapidly disappearing. You know, couple years ago, we didn't have any AI, capabilities. Now we already have GPUs running in, you know, over a 190 cities and expecting that gap to close very quickly. So I don't even need to mention that exception at all. But, really, it's kind of having that homogeneous architecture where, you know, no matter what card you're using, you know, matter how complex or hybrid your infrastructure is, sorry. Your environment is, you know, you can put CloudFlare in front of it and just gives you that single point of control. And, you know, when we do talk about services, you know, pretty much anything an organization might need during cloud migration, anything they might wanna consolidate, we offer whether that's on the, you know, SASE and zero trust side, on the application security and performance side, you know, you know, on the networking side, and then even, you know, giving you the capability to build new applications and run logic serverless logic at the edge. So I won't run read through some entire list. But, you know, pretty much any sort of thing you're trying to consolidate, CloudFlare can do that for you and, you know, work with any type of complex hybrid multi cloud environment or whatever. Final just kind of architectural thing I'll mention is is about the management because, you know, I think, Dan, you you mentioned correctly, you know, trying to make it easier for teams to do the thing that they need to do during and after cloud migration. And so that's why, you know, both from a UI perspective, we make it so, you know, you can manage everything that I just showed you here, zero trust application layer seven stuff, developer stuff, network stuff from a single pane of glass. But then kind of even more interestingly, you know, you can manage all of it via single via a single API, and then, you know, even do automations with, like, a Terraform integration. So, you know, allowing you to do, like, you know, DevOps and DevSecOps and infrastructure as code to really just simplify the management as much as possible. And I think there's, you know, one customer example, that I think reveals this really well. This is q two. They're a SaaS company for financial services used by, I think, around, like, a third of US banks last time we checked. And so they were actually, you know, going through a cloud transformation when they were moving to a distributed cloud environment, actually. So the kind of multi cloud setup you were talking about, and they really just wanted to make sure that the management stays the same, I guess. And so they use CloudFlare to secure, you know, both their cloud and their remaining on premise environments, you know, through, like, emails mitigation, you know, WAF, and then also doing a bunch of connectivity, you know, like load balancing and and then CDM caching as well. And so by having that single plane of control that is, you know, really easy to automate and and customize, you know, they've been able to just operate a lot more efficiency, with a lot more efficiency. So, you know, speeding up the network modernization process, having, you know, easier and safer policy updates, and then even just kind of adding a lot of, you know, kind of economic efficiency to to their new environment. You know, you can see here that their VP of infrastructure talking about how they can really distribute different workloads in a very automatic and efficient way across different cloud providers so they can get the best economics there. And then also because Confluence, you bring your own IP, ranges to our network that just, you know, made it a lot easier to kind of get spun up to start with again, Not eliminating, but reducing that sort of onboarding time line that we're talking about. And then, you know, they also use some of our infrastructure as code capabilities to really let any user update network security whenever they need to and still be able to manage and monitor all of all of that in a single place. So just one example of how Hotpepper can help make this happen. You know, that, I think, is getting close to the end of our time. Just wanna see maybe if we have any we have time for one question. And, Dan, I might ask you to keep the answer brief, unfortunately, but I just wanna get to one question. Okay. So, you know, any suggestions on how to handle, like, team members and developers, say, who are, like, not using the new tool sorry. I'm not understanding this. Like like, let's say, like, a developer or a new team member is not using some of the services that you're trying to consolidate onto. Like, any suggestions on how to handle that? Like, are the kind of the people side of it? Like, maybe you it sounds like they're saying, like, you know, you have new you have new services, but people consolidated service, but people don't use them. It's it's a great question, and I I'm I'm gonna probably give a, two sided question to answer here. First of all, I've got some of my best ideas from young developers who prompt them a different way of doing something in the past. And, and so first thing I would say is listen to them. Make sure you totally understand what they're doing and why because they might have the latest and greatest way of doing, securing, your your AI based application that you haven't had time to look at yet. So so first of all, listen because they might be right. Now if it's the other scenario, which is, hey. We've just done an assessment. We've decided we're gonna standardize on, hey. We're gonna standardize on cloud cloudware cloud flare for our WAF offering. And they've got something that they've had and and they're still in a kind of a silo, and so they're not aligning with with the, I'd say the corporate standard is. You have to understand why. And sometimes it's, very unique use case. Sometimes it's I just know this tool better and then it's gonna make me more inefficient and and, you know, it's about my workload versus the the standard. So I think you have to understand where they're coming from, and try to influence. Right? And I always like to say as in my job as CTO and in any executive position, you have to influence, which is internal selling. Right? And and convince them and show them how the value is not just about their their little workload. Nice. Like, their workload and how they're doing it, but the bigger picture and how it's gonna save a lot of money is from the company perspective or add flexibility that we've never had before. Now we can start doing sharing before. So, it really comes down to influencing and convincing the the value of doing this. And and, you know, I would say that 90% of the time that works, and 10% of the time, you just have someone that says stop when you change. You have to move on. Fair enough. But I think it's a really good point about trying to listen before changing behavior. I wish we could keep them, but I do think we need to wrap up. Dan, thank you so much again for sharing all of your insights with us. Really appreciate it. Thank you everyone listening. Really appreciate you taking the time to spend with us. Hope you've learned something interesting, and, look forward to seeing you again soon. Take care. Thank you all.