Transcript for "3 Strategies to Modernize Applications and Build for What’s Next": Hi, everyone. Thank you so much for joining. We're so excited to talk to you all today about how you can modernize your applications. This session is meant to talk about just general strategies related to application modernization. We'll talk about three paths to app modernization, specifically rehosting, replatforming, and refactoring, and some pros and cons of each of those types of strategies. Today, I'm joined by Cloudflare's chief information officer, Mike Hamilton. My name is Catherine Newcomb. I didn't introduce myself, but I focus on application security here at Cloudflare. And I'll hand it over to Mike to introduce himself. Hi, everybody. I'm the chief information officer here at Cloudflare. I've had about a twenty five, twenty seven year I'm starting to lose track career in IT, and, I'm really excited to be here with you today and talking about that modernization. Awesome. Thanks, Mike. So before I dive into some of the specifics about app modernization and this fireside chat style conversation we're gonna have today, let's get a little context about the last five years of app modernization because, of course, we've been having this conversation since at least the early two thousands. So why is app modernization, new and different today? Why is it on the top of our minds in particular here at Cloudflare? So since 2020, organizations have seen even greater appetite in the world for digital services, of course, with the pandemic and whatnot. And in 2025 in particular, AI isn't just a future thought of an investment. It's actually running in production in a lot of the customers we see. And edge computing isn't experimental anymore. It's powering real time customer experiences. And these news articles I've clicked here just showcase how some of these app modernization projects are touching a variety of industries and different types of apps. Things like web apps, internal apps, SaaS apps, and more. And so app modernization isn't just about cloud migration or lift and shift or some of those things you might have traditionally heard or where your app is hosted. You can also modernize things like app infrastructure, like delivery and security wherever that app may live. And in this session, we'll discuss how Cloudflare can shorten the time to value, for your app modernization strategy, whether that's rehosting legacy app infrastructure, report platforming across multi cloud environments, or refactoring and building new apps. So let's look at some of these key trends that are driving application modernization. So, as I mentioned, app modernization, obviously not new, but most of the projects that we're seeing are often failing due to things like complexity, cost overruns, and security bottlenecks. And the stats on the right here show that 70% of orgs want to be able to modernize their apps to improve their security, agility, and scalability. Yet most organizations are recognizing that modernizing their apps is critical to their survival. So it's not a surprise that 30% or 37% of orgs have increased their IT spend in 2025 after, many years of flat or declining IT budgets. So exciting times for app modernization for sure. Let's talk about these three routes to app modernization. So when we're talking about app modernization, what do we mean specifically in this context? Well, we're referring to the transformation of existing applications and their infrastructure and building new ones using modern technologies so that organizations can do things like stay competitive or provide delightful user experiences or maybe be more agile as markets change and be able to respond to those market changes. Often, organizations will have, multiple such types of initiatives in play, including the three most common ones we see, which are rehosting, replatforming, and refactoring or building a new app. And we'll talk about more of, in more depth about all of these strategies as we get into that fireside chat. So to kick it off, I'm gonna ask a little bit about, rehosting. So here's where we're gonna start. Some of the most important things regarding rehosting. What we're talking about here is migrating app and app infrastructure as is the cloud with no code changes to the underlying app. You might hear this referred to often as lift and shift. So, some people might do this when they want to be able to take advantage of cloud technology. Maybe they just want to be able to, not have to manage on prem infrastructure related to app hosting or app infrastructure, not have to have data center and hardware costs anymore. So this is one reason why we see might see people do this lift and shift type thing. So, Mike, I have a question for you, which is, what kinds of IT projects and architecture are used to, seeing for organizations at this stage of app transformation? At this stage, because of the cloud capabilities that are out there, what I mostly see is not rehost, but rather re replatform and and and, refactor. Rehost is generally something that gets used to keep something alive, but it's usually not the thing that's driving a ton of innovation. Re rehosting in my career goes all the way back to, oh, the server is out of warranty, and we probably need to put it on a server if it's not, you know, out of warranty. And then later, it became a p two p transformation. Like, I can move this physical machine to a virtual machine and keep it alive longer. There's a lot of challenges that I saw organizations face, including ones I worked for when they tried to move in the cloud, though. And the difference was the cloud architectures from an availability perspective changed the way that your application has to work to some degree. So this notion of the architecture that worked on prem has to be modified to some degree to work well on the cloud. As an example, if you had a in a, in in a cloud, you know, a hyperscaler environment, the database was hosted on a physical server at some point or a virtual machine at some point, you'd probably wanna switch to a cloud database because you're not getting any of the advantages of a cloud database by hosting it on a virtual machine. It needs to have some infrastructure that's gonna work. And so rehosting wasn't exactly lift and shift, but that didn't stop companies from doing it. And they were usually pretty surprised when it's like, oh, no. What do you mean one of the data centers is having trouble and one piece of this application went down? So it's been a bit of a bumpy transformation for companies to try to rehost their applications simply by moving one architecture into a different environment. Cloud cloud architectures are optimized around these notions of regional availability zones. They have multiple data centers within an availability zone, and application has to be broken up in a certain way to maintain your business continuity needs. So I think the thing is that mostly fit this, this kind of scenario or applications that you wanna keep around, but you need to move them for various reasons. And you hope that you don't have to rearchitect, but you should be prepared for a little bit of change to take advantage of the cloud environments. The other thing that makes it painful for a lot of companies these days that it is that each of the hyperscalers has their own challenge in terms of what they consider the right path to high availability. And so once you you might think, we'll have a multi cloud strategy, but it's not as simple as it sounds. Multi cloud strategy for an application will require knowing the nuances of each cloud environment that you're in and understanding what the ramifications are for your application. So rehosting has probably never been ideal. It's nice for keeping systems alive, but it's it's, you know, pretty antiquated in terms of like, hey. It's probably not gonna help you scale or or do the things that businesses are trying to do in the modern era. Yeah. So that leads to a great question. So given that this is really not an ideal state of being for many organizations, what kind of factors would actually lead an organization to choose rehosting over more mature app transformation projects like replatforming or like refactoring? Well, hyper the cloud is still a better place for certain workloads that you need to keep alive. As an example, I've had I I did this once for a workload that was, it's something we need to keep it around for records reasons. It was like record retention. Like, there was it was an app that hundreds of people used to every day used to use every day, and then we had moved to a more modern version of the application, but they needed the old version to live for quite a long period of time for record retention until they could figure out how do you wanna handle the the difference between the two systems, the the old system and the new system. And so it's it's not that you never choose this. There are benefits to keeping things alive, but it's probably not the thing you're betting your business on. The thing you're betting your business on is the thing that has to scale and be responsive and have a great user experience. Rehosting is probably not where most people are going for that. And and and having said that, it may seem like the cheaper option. And and and I would warn companies to be careful about thinking about it that way. It might not be the cheaper option. There could be efficiency loss in terms of choosing the wrong architecture in the cloud and not thinking about the other two options as part of your strategy. So, like, I would say don't get super comfortable with it. It's a great way to keep things alive, but it's probably not the best strategy for everyone. That makes sense. So let's talk a little bit about replatforming. So we've discussed that rehosting is definitely not ideal for most people. Let's talk a little bit about what this next stage or phase of app modernization might look like in that maturity curve. So when people are replatforming, often they are doing this to optimize their app infrastructure. Maybe they're looking to take advantage of technology like containers or serverless or managed services. Maybe they are looking to move to multi cloud and hybrid environments. Anything you'd like to add, Mike, about what replatforming is and how you see it in your business? So I think this is a really popular trend for good reason. When I think about hyperscalers, I think about I mean, let's just be honest for a second. Like, what hyperscalers do is they take a a lot of open source products, and they make them available as services. But what that gives customers is the ability to say, hey. I I can choose which building blocks I want to leverage to make this application scale and to use the scalability of the cloud and, you know, horizontally and vertically to to say, like, how do I get my application to work better and perform better on the cloud? Replatforming then means taking your application and taking advantage of all of the different pieces that are in use in cloud environments to rebuild it in a way that supports all of the advantages of these things. So, like, automatic database replication if you're still using a database or maybe a different database technology that you've never run on prem before. Object storage is obviously a key, component of this. There are certain security features that each of the clouds offer that give you some kind of coverage. But replatforming and and and where I think of Cloudflare and the replatforming story is that replatforming and and multi cloud strategy should have a common edge. And I see Cloudflare as a key part of the common edge that like, if you're thinking about, if you're thinking, for example, about a multi cloud strategy and we're gonna replatform into a multi cloud strategy, the the thing I would suggest you think carefully about as well is that how do the different cape security capabilities of these clouds affect your overall strategy? Because they're let's say you were go multi cloud between GCP and AWS. Their products are gonna differ from a differ from a security perspective. That's two different tools to watch. It's different scalability, different performance, different service tickets that you've gotta open up if you're having an issue. I like to think more of replatforming as a have is establishing a common edge, and that's where I think Cloudflare Cloudflare gives you the most strength. With Cloudflare, you can say, like, look. I may have a multi cloud strategy when I replatform my app, but I'm gonna have the edge be the common part. And and there's a lot of advantages to doing it that way. Using us, for example, for object storage would mean that you're not paying egress fees for either of your cloud providers to to close your application. You have the advantage of our edge computing and having the fifty milliseconds from all the eyeballs on earth, is is one of your advantages. Yeah. I I think that's a that's a differentiator that nobody else can offer our customers, and it's a it's a key part of the strategy. So to me, multi cloud really means, like, multi cloud common edge. Multi cloud in a single environment, you're still setting a lot of, you're betting a lot of your eggs in that one sort of basket. You're putting them in one place. Like, if if Amazon's having an issue, chances are they're having an issue across the availability zone and and it's gonna affect your product in some way. And so I think multi cloud is is a common and proper way to think about it, but the common edge is is a strategy that I would not overlook for sure. Yeah. So that leads me into my next question, which is what kind of factors would lead an organization to choose to replatform an app versus rehosting it or refactoring it? Replatforming is typically gonna be less cost costly than refactoring. I mean, in in refactoring, when we talk about this specifically, I can go into some of the benefits of why you would wanna refactor or why you would think about it that way. But modernizing your app by taking advantage of cloud scale is pretty critical for any business, and and I think it's typically a better choice over rehosting. If the thing that you're re you're you're trying to move generates revenue for you, as an example, as a core part of your brand. So think about your brand first. Right? Like, re replatforming is a key part of your brand. Your your application has to be available. It has to be performance, and you wanna use the pieces that that can help you deliver the service to your customers. The that's a good reason to think about why you would replatform. Take advantage of the cloud capabilities. Take advantage of what they can offer you from a from a services perspective. When we talk more about refactoring, though, edge computing is really driving usage based, more than more than anything else. And I think that there's a natural there's been a transition I've I've been able to see in my career. You know, everything used to be on physical servers, and then we moved to private virtual servers, and then we moved to public virtual servers, and then containers came on the scene, and then serverless came on the scene. And I think most people would agree that serverless is where everything will go. At the all the tech companies that I've worked for for the past ten ten years, as serverless started to show, a lot of progress, we all agreed. I've I've seen it happen over and over and over again. They're like, serverless is where things are going to be because it makes sense. Your customer's getting the latest version of an app at real time. The code deployment's interactive and, like, then the next person that spins up to the next version. It just goes along with this idea of, like, move fast and and get results quickly. Right? Like, you can see these changes go through. It helps you respond better to security issues. As an example, our our data shows that that a a bad guy can release an exploit for a CVE within twenty minutes of the CVE being announced. If you think about that from a patching perspective and the infrastructure we maintain in a replatforming scenario, that's a lot of work, actually. And and I think most people on this call will probably know how much work is involved in that. But what you also know is that it's not twenty minutes. So, like, no matter what I tell you about how much work it is or how much I say, how much work goes into to to responding to a security issue in your environment. The reason that serverless has so much potential is this idea that, like, I can respond much quick more quickly. I don't have as much underlying soft software supply chain dependencies, and I'm able to respond a lot faster to security threats and have things rolling in in real time. So I do think that for again, if we boil it back down to brand, this starts to become a brand decision. What's the best architecture to represent not only the brand that I have, but the user experience and the performance that I'm trying trying to drive? What platform gives me the best way to secure my environment without having to look at different dashboards and chairs level? So, you know, these are things that people should be thinking very carefully about as they think about the strategy behind how their brand shows up on the Internet. Yeah. That's a great point. So you talked a little bit earlier about different paths to replatforming, like repat platforming with a multi cloud versus multi cloud with single edge. There's also a single cloud replatform that people can choose. Let's talk a little bit about some of the ways you've seen organizations go about this and maybe what's worked in these types of different platforming, replatforming projects and what hasn't worked. Yeah. I mean, I've seen I've seen companies go through quite a bit of of different strategies for this. One example would be a company that is going from colocation to higher to to cloud public cloud. And, like, single host to public cloud. And there was a need for a while to have, like, some of the infrastructure still be in the colocation facility. Like, we're we're gonna gradually move. The strategy was usually start to move the edge out, start to leverage object stores more. You can imagine I mean, probably a lot of people in the room right now would would would would this resonate with them. Like, I'm moving from a NAS or a SAN to an object store. Right? Like, I'm thinking differently about how I list my application. And so I've seen a lot of this type of transformation. And it's it's hard because there's cost to doing this type of transformation. The benefit isn't necessarily transformational, though. It shows up in, like, hey. My availability is great. I think a lot of people resonate with what I'm about to say in this room. In fact, there's a whole bunch of things when you're in operations that you get no credit for when they work amazing, but you're like, your your phone is ringing off the hook when they're not amazing. Right? And and, unfortunately, with replatforming, that whole migration path is your life right there where, it will perform better. You're gonna get more flexibility. You're gonna get what you want, but, like, that transition doesn't get you a lot of, a lot of kudos for the most part. It puts you a little bit of risk. It's worth worth the effort. I'm not seeing some companies straight up just do a green to blue switch where they're like, hey. We were in colocation today or we were in cloud a today. We've done a bunch of work. We've, to to get into cloud b, and now we're ready to relaunch in cloud b. If you're gonna take the time to do that, what I would recommend is is trying to, get to a state where where infrastructure as code is a key part of your strategy. So one of the things that companies tend to miss is it becomes kind of a click fest. They're like, oh, look. I'm gonna, like, provision all this stuff, and I'm not gonna take advantage of the Terraform capabilities of all these tools. That's a mistake. Wanna make sure like, you should actually treat your infrastructure as code, and I need to be able to spin up in cloud a or cloud b and and and make this work. That's that's part of the beauty of Terraform, but, like, that should be part of your strategy. Don't get click happy. Don't don't, like, use the technology for for what makes your operational life better. It's worth the extra effort because it will help you troubleshoot it later. I think companies have a tough time too. Like, nobody likes to do documentation, but but, like, it's it's a little bit easier in the cloud world to kinda have self documenting sort of our architectures where it's like this is this is something that we can reproduce because the Terraform and the the automation around infrastructure as code allows you to kinda have a self documenting infrastructure. This is how this is how it's deployed. You didn't have that before. You have the chances to do it now. So it's totally worth that investment or making sure that that you treat everything as if, like, I could blow it up and redeploy it and it would still work. That that's the target you really wanna aim for. Yeah. That's that's a great point. So I know you talked a little bit about replatforming in a single cloud earlier and and one of the risks there being availability. If there's an outage, you know, it's likely happening across one availability zone. Any other risks of replatforming in a single cloud that you would caution viewers against? I think that it becomes, and it it it's hard for me to say this without sounding like a little bit salty, but but I think it becomes a little bit hard to manage your margins, when the cloud provider knows that they've got you. And so not investing the time in being able to have a multi cloud perspective at a minimum. Like, how would I move clouds if I needed to? And and and I wish I could tell you that, like, that's a that's a zero effort thing. Thing. They're like, if you don't like one cloud, you just spin up on another one, but that's not really the truth in terms of most hyperscalers. It's not the truth at all. In fact, their their building blocks are different. The way you configure their building blocks are a little different. It's it's not an a to b natural switch that you just flip the lever. Even having an active active multi cloud strategy requires some planning and it risk it requires understanding the nuances of having having a multi cloud strategy. So so it's it's really important not to oversimplify it and to focus on what are you trying to achieve. If the availability zone architecture of a particular cloud provider doesn't give you the comfort you want or you have the issues that you had, again, going back to the common edge thing, Cloudflare is a common edge and using our storage layer would be a good strategy. And we can certainly talk with anybody that wants to talk about the right pieces to bring into the puzzle for it to establish a strong common edge. That would be my recommendation. It's like, put the put the pieces in the best possible players. Really, your your your customer doesn't know how you have your your application platform. What they know is it's either working or it's not. And so what you need to be able to do is make sure that you feel comfortable that your architecture is supporting what you need to to show your customers. Yeah. So I'm sure a lot of people on this call are, you know, responsible at least some level of the chain for disaster recovery efforts. So let's talk a little bit about, you know, obviously, you know, a single cloud replatforming can pose some challenges for disaster recovery, but multi cloud replatforming without a single edge can also pose some challenges to disaster recovery as well. So what sort of challenges do you see for IT teams there in terms of, recovering from outages or security incidents, when they have a multi cloud replatforming environment without that single edge? Without the single edge, I think steering becomes really difficult. And when I talk about steering, what I'm talking about is, like, you you should be able to redirect your customer's traffic without them knowing they're being redirected and they don't know any different when it happens. That way, if a cloud environment is having an issue, you have not only the ability to manually respond, but ideally to automatically respond and steer traffic is necessary. And so a steering test would be the the the the thing that I factor into my mind when I think about this world. Like, the single edge, you're not gonna have as much of a steering test. You might you might have posted some tool somewhere that's, like, single purpose tool that you're using in between, but that single person tool single purpose tool might be a single point of failure as well. And so thinking about, like, having a, you know, an elastic edge that that can service you better is is a is a good part of your strategy. What I like about it is that give if you think about again, Cloudflare is kind of the center of this. They're like if Cloudflare is my common edge, I have a very high available service that's not running on any of the other clouds. It's no port no part of it's running on a cloud. Think, for example, about the cool tool that you bought from the security vendor that you're using for your what you think is your shared edge that's like a third party is actually running on the same cloud infrastructure that's having trouble right now. Because it's true. Some of the companies run on other people's cloud infrastructure. Cloudflare doesn't do that. That gives us this ability where we're not affected by someone else's outage. Amazon's outage wouldn't affect us. Azure's outage isn't gonna affect us. Them having issues isn't gonna affect our edge. Your third party tool that you're using could be at risk of that. So know where your stuff's hosted. If if you're think about anything that's coming in your environment is like, if it were a single point of failure, do I know where it's actually running? And the vendor will usually tell you. I'm just like, yeah. We've bet hard on Azure. We've bet hard on AWS. But you don't wanna be in a situation where you're having lunch, you know, with your colleagues and your phone goes off and it's like, why is this not working? And it turns out that, like, the the host the provider you're using for services on the same, you know, infrastructure that you're on. And then it's like the strategy didn't really give you the coverage that you wanted and and it was a missing piece that that you didn't know was was in place and at risk. Yeah. Thanks. That's great advice for people focused on disaster recovery. So let's look at the final, maturity phase of application modernization. So we're, talking about this as refactor. Sometimes people will build a new app from scratch, or or build, you know, a new app that didn't exist before to use, new technologies. But when we're looking at refactoring, this is where we're talking about rewriting existing apps, building new app architecture to use modern technologies. Serverless is definitely relevant here. Microservices architecture you might see, AI architecture and whatnot. And this is one of the best solutions that we see for people who are looking to manage tech debt, especially with sort of rehosting projects. We'll get a lot of tech debt, for organizations. So, and for and particularly, when people are interested in, you know, fast growth, whether that's a younger organization or a more mature one, a lot of times organizations will simply build a new app here instead of refactoring one. So, let's look at sort of refactoring. Mike, why would somebody choose to refactor an app as opposed to rehosting or replatforming? So the application scale, it becomes a lot easier to maintain the scale of the application if the p the the this overall application is broken into smaller pieces. So microservices is a way to think about this. And if let's let's pick on replatforming and rehosting for a second because it makes it a little bit easier to have the refactoring discussion. There everybody's familiar with the three tier app web app architecture. Right? You have a web layer, you have an API layer, and you have a database layer. And that was very prevalent for a long time. A lot of applications have been built that way. The the the way that rest works has made that scale pretty well over time. But even in the replatforming world, that doesn't totally live as well as it used to. It's not necessary it's not microservices at all. It's still a three tier architecture. There's a lot of services running on the same tier on the same infrastructure. And so issues with a particular layer or some percentage of servers within a particular layer can cause issues with the entire application. When you think about serverless and you're moving now compute all the way to the edge where it's as close to the end user as possible, you don't have to say I have to get there overnight. Like, I'm not gonna take this application that are built in house and get there overnight, but I can get there in pieces. I can move this microservice that's been a part of it, you know, running with other services on a Kubernetes cluster, for example. I can move this one piece somewhere else to serverless, to be event driven, etcetera. And I can move them one piece at a time. Thinking about microservices, there's there's an entire art around thinking about microservices, but it certainly allows you to have much more maintainable chunks of code where iterating on the overall performance or the overall architecture of your application is just a matter of software. It's no longer a matter of, like, I have to think about the hardware. I have to think about how this is hosted. It literally becomes a software architecture problem, which is a lot easier to solve in a lot of ways. It takes the complexity out even though initially it might seem a little bit scary to get into it. But what what it also adds is that as capabilities at the edge get more sophisticated, those become microservices in your pallet. So I want you to think now, in a microservices architecture, you can re you can replatform your app or re refactor your application to have microservices, to run serverless, to run at the edge, to have the front end, back end, and the data platform all sort of working together in great orchestration. But then as companies like Cloudflare, for example, are spinning up things like Workers.ai, where we give you the ability to rent a GPU to do AI inference, with our with with whatever language model you like at the edge, you don't have to build that. That's just a service that you could take advantage of. And, internally, we use this strategy a lot to help us start building chat apps inside the company and and only pay for what little cycles that we're using for each transaction. The transactional nature of this is part of what makes it so appealing as well. So I want you to think backwards to the other two architectures for a second, and it's always been sort of my my peeve with with, hyperscaler environments is that the meter is just running. It's just always running. Every server that gets spun up is running the meter. Every database that gets spun up is running the meter, and that meter never stops. It's 24 by seven. So demand is high. Great. Probably the intersection between demand and supply is pretty decent from an ROI perspective. But it gets pretty tricky when demand is not high. You know, eight hours a day when people are sleeping, for example, if if that's your key market, you're paying for something to be running that's barely being utilized, and serverless gets rid of this. And and the entire idea starts to become, hey. Hey. I'm only paying for something when an event is happening and there are CPU cycles being spent to do that. Now as it's elastic. As demand goes up, so does supply. When it goes back down, it gradually decreases. Now you might say, my god. That sounds familiar. I think that like, didn't Netflix sort of pioneer this horizontal scaling concept and the other architectures? Yeah. Totally. But that was a full VM. That's like this full VM spins up and this full VM spins down again when it's not needed. In the world of microservices, in the world of serverless, that's not necessary anymore. We're really just dealing with the fact that the code auto deploys. It's ready. The events drive the demand. They drive the performance, and then it'll it just scales back down automatically because it's usage driven. There's literally almost there's practically nothing running if demand is low. And when demand is high, all the capacity you need is there. I think that's what makes it really special. So, again, kinda to summarize, you don't have to get to refactoring overnight. Don't don't think that you have to get there overnight. Don't pressure yourself like, oh my gosh. You have to do it. Think about what services can we break out, what can become serverless first. What key capabilities of my common edge can I start to leverage that I don't have to build myself? Right? Like, these are key things. And then and then gradually getting into this mode because it's gonna start to reduce the overall cost that you're having to run things. That way you're not paying for infrastructure that's just sitting there waiting to be used. Serverless is much better. And it's kinda magical, actually. I mean, the c the CICD process for serverless is so seamless and transparent that once you start to get into it, it really becomes kind of addictive. And it's like, wow. This is this is a lot easier than the CICD processes that I've been dealing with in the past. So, like, I I'm really bullish on this strategy. And quite frankly, with your core business, it's the right way to go. Yeah. That makes sense. So, you know, in terms of refactoring, obviously, this is the most sort of labor intensive of all of the types of application modernization we've talked about today. And you've sort of alluded to the fact that, you know, people can do refactoring projects sort of piece by piece, and that's one of the beauty of, like, being able to utilize my microservices, for example. But let's talk about what could somebody do or an IT team do to make refactoring an app more palatable, and less labor intensive for their organization. I mean, it really depends a lot on the application, of course. Right? Like, specifically the application. But to make to make the work more, effective, it helps to start with the microservices sort of breakdown. And thinking about like like, if I were if if I were counseling someone today, I'm like, how how can I get the best value out of this? And and I have let's say you have a three three tier architecture today. I would say, like, what APIs can you break out of the API layer that could be microservices and running separately as serverless code? How does the event driven piece of it work, and what could you break out where nobody would really know? And and you can start to percent send this percentage of workload to this event driven API that's that's all circles. I think that's the right way to think about it. It's breaking it into really small pieces that show value. This helps you trim your cost of running the service as well gradually. Right? So we can start to take these things that are heavier lift. You might even wanna start with something that's completely behind the scenes that drives some kind of capability that your your site is running, but but do it in a way that, like, moves a a chunk of the workload off of the layer that you have it on today. So, like, move this this heavier workload into the microservices layer, test it by starting to send a certain amount of traffic to it using, you know, various technologies like an API gateway or something or or a load balancer to get this technology to, pick up some of the workload and measuring that and and and calculating the success. And then measure the ROI. Like, you're not you're not initially if you start with the heaviest workload, you're you're gonna see a lot more yield in terms of, like, hey. Maybe we don't need as many full time, servers with a meter running twenty four hours a day because we took the heaviest workload and we moved it to microservices. So my my advice is to start with things that are materially going to impact the cost that you're spending today because those dollars can be reinvested in continuing to to approach the refactoring, strategy. That definitely makes sense. So, you know, obviously, we've talked about how fantastic refactoring is in terms of the things like performance and whatnot, and being able to use these modern technologies. But, obviously, you know, as we create additional technologies in our apps and whatnot, security is always a concern. So let's talk about briefly what security risks might be more prevalent in refactored apps. Something that comes to mind for me is things like MCP servers, or agentic AI, that type of thing. I mean, there's, you know, there's layer there's risks in everything, of course. If we go back to the to the refact like, the replatforming, for example, there's a lot of eggs in one basket in terms of how many services is a single server running or a container running, that might be vulnerable and that might have software supply chain issues. And so I can poke at that quite a bit, in terms of thinking about software supply chain because supply chain attacks are kind of on the rise. So sorry to defer your question for a second, but I did wanna go back and rethought. Do. I I'd love to hear about that as well. And really think about, like, hey. You know, software supply chain attacks are still a real problem in in in that layer. And then on the on the on the the refactoring side so I think part of what you're asking is is as MCP becomes a thing that we in a to a and we're seeing these new new, trends emerge, it's really, a key part of our strategy now also to have an opinion that is expressed through actionable, like, capabilities. Right? So how are you supporting MCP in in a way that, helps you add to the security of it? And and, really, we are at an unprecedented stage in human history where the velocity I I I've been in tech for a long time, and I would say it's been a really fun journey to see what it's like to go fast. Again, I enjoy that. I like being in tech companies because it feels cool to go fast. And and even I as a career having had a career at very high velocity companies, and watching AI in awe, where it's just like, wow. The the you know, MCP is a relatively recent announcement. We've had some products that go along with that in in some really clever and exciting ways. But but we all have to keep on our toes, at this point in terms of, like, what are the implications? Because you can't you can't sit on your heels anymore. We can't say, like, I'm just gonna ignore this and wait to see how it shakes out. We all have to start to develop opinions pretty quickly, whether that's on internal applications or external applications. And so I think my advice is is to find ways to to wade into the to the water in terms of, like, some of these new AI capabilities. I also think it's important from a bot management perspective to look at your application and say, like, hey. Do I really want these scrapers going crazy? Are they gonna are they gonna, you know, honor my, robot's file or not? Do I need to have a better protection in front of it to make sure that my intellectual property is not being used without me getting credit for it or without, you know, me like, is the is the scraper increasing the load on me without me getting any benefit of actual traffic and serving ads and things like that? There's a lot of pieces. And I know we started on the security question, but, like, security is is a broad thing. It's not just about attackers. It's also about, like, you not getting the value out of your site that you wanted to. That that's a form of an attack. And so we all have to be a lot more close to the edge. And I think it's really important to follow our blog. Like, I know I do to try to keep up with it because our blog is prolific. Like, we have a lot of people to contribute to it. It's become one of the best places that I jumped you to to find out what's going on out there right now. Yeah. That's a great point. There was recently an announcement that you alluded to related to the sort of AI scrapers and this bot problem here. So for people who are, you know, content creators, like, say, for example, creating pieces of writing, creating photography, art, things like that that they're posting on their website. One of the big challenges with things like this generative AI is, you know, their art getting used to to create generative images or whatnot. So this is something Cloudflare has been looking to address. You know, we've been dealing with bot scrapers for a really long time here at Cloudflare, but, you know, looking on how we can identify those LLM scrapers or generative AI scrapers, and make sure they're not actually using your content, in order to basically power, you know, their generative AI. Something we've been doing a lot along a lot around lately that I would definitely recommend looking into as well. Yeah. We one thing about company is that we are we are extremely mission driven here and build a better Internet is our mission. And so you you can, we have millions of free customers. We have hundreds of thousands of pages of your customers, and we have many, many, many enterprise customers. That footprint gives us the, the opportunity to be very opinionated, and we take that responsibility really seriously. So when I say, like, our our blog is an important place to go, like, I if if I even if I wasn't working here, I would take Cloudflare's opinion very seriously as these these topics emerge because our mission is to build a better Internet. And as as the uncertainty of this landscape continues to evolve, it's important to be opinionated, and and we're not afraid to be opinionated. Yeah. So that's actually a great segue into some of the stuff we're doing related to app modernization. So I'll touch a little bit on some of that security stuff. Of course, that's my area. So it's where I, tend to want to spend most of my time. But let's talk about AI a little bit first. So, as Mike mentioned, we're doing a lot related to AI right now. One of the main reasons organizations are choosing to refactor apps is to take advantage of new technologies such as AI. Of course, things like microservices and whatnot really relevant as well. Being able to have more developer agility also really important. But being able to to use AI, like, a lot of people really wanna use a AI right now. So I know this is top of mind. And we're offering products at sort of every stage of that AI life cycle to help you, you know, we've released full stack tools to support AI development efforts, from things like storing training data without those cloud egress fees, to doing things like running inference at the edge, which can help you run inference both cheaper and faster. Mike talked about that a little earlier as well. We also help you observe usage and behavior of your AI models to prevent things like unbound consumption from happening. And then finally, we're also focusing on once that model is deployed and in production, securing that model and usage of the model, to things like, you know, making sure the model itself is secure and things like, you know, jailbreaking or prompt injection aren't happening, to also making sure that that model is not exposing things that it shouldn't be to the end user, whether that's through things like content moderation guardrails or things like, making sure that the LLM is not, for example, exposing, PII in a response phase. So one of the key products we have been talking about lately and launched lately, in this space is a product called firewall for AI. We've really recently released this in beta in, Cloudflare has these innovation weeks that we do, around different topics every year. We had security week back in March, and this was released in beta during security week. So, firewall for AI, you can think of it similarly to, basically working in line like a WAF does. And so, it focuses on securing AI based apps, and it's a protection layer that sits in front of LLMs or other types of generative AI or apps that use AI components, to identify abuse before it reaches the model and validate the responses and prevent them from exposing things like harmful information or PII to the end user. And it works in line like a WAF rule set like I mentioned, but it focuses on blocking attacks that LLMs are vulnerable to, that traditional web applications are not, like prompt injections. Of course, AI and LLMs are also, you know, vulnerable to traditional types of attacks, things like, you know, data exfiltration from the model, things like DDoS attacks, still relevant on a model. So we're making sure we're running all of these, like, LLM specific detections or GenAI specific detections, alongside those traditional web application detections or other types of application detections so that you're getting all of those traditional detections like DDoS mitigation, alongside these more advanced, OAuth top 10 for LLM type attack mitigations. So, anything you'd like to add here, Mike, on sort of what we're doing around this AI security space? I would just add that it's continuously evolving and and kinda going back to the blog since that's why it helps to pay, pay attention to what we're posting because it's it's rapidly evolving. You the the artificial intelligence space, if you just look at the data on it, is evolving faster than any other technology has in the past. Companies are hitting a hundred million users at an unprecedented rate. They're hitting a hundred million in revenue at an unprecedented rate. And what this brings for us in in the environment is is challenging because we have to we we live in a world right now where as leaders, we're all challenged to say, you know you can't miss this bus. Right? Like, you know you can't do nothing right now. You can't just wait and see. Nobody's got that luxury because the competitive advantage is being driven by these technologies. We all have to be on deck. We have to run experiments. We have to be engaged regularly because the landscape is continually changing. And the the way that we do this quite frankly is together. That we share, that we talk, that we find ways to to to collaborate, to evolve into this new era together. Yeah. Thanks so much for adding that. So one other thing that we're doing, Mike talked a lot today about CICD, and things like infrastructure as code. And and, obviously, this means developers getting involved a lot more in, things like security as well. So, one other product we release, recently released is a product called Secret Store. And this is a secrets management product that allows developers to, basically use secrets and variables to create, encrypt, and update the values of environmental variables and secrets across, all different types of scripts from a centralized location. And this is all done within Cloudflare. And for security professionals, this allows them to do things like control access to those secrets with, role based access control. They can do things like audit visibility of the secrets, making sure those developer secrets remain secure and sensitive information is safeguarded. So, Secret Store is part of that overall security admin toolbox on top of other Cloudflare application services like WAF, bot management, API security, and whatnot. And one important thing to note here is that so once a secret is encrypted, that secret value is never readable by anyone. So if you're worried about, you know, secrets management within the Cloudflare dashboard, you don't need to worry about that sort of being viewable by a bunch of people. We take, you know, security and privacy very seriously, so that's just something to note here. You know, as you're thinking about all these different types of refactoring projects, like making sure your development security and securing developer, access to infrastructure, really, really critical throughout that life cycle as well. And all the stuff we've been talking about today is is not just theoretical. Right? We're helping customers with this type of projects like rehosting, replatforming, and refactoring today. And one customer that's doing such type of project is a customer called q two software. I had the privilege of speaking with them recently, and, they are a customer who has a lot of had have has had a lot of success modernizing their apps with Cloudflare, and they're a financial services SaaS provider. And what they do is offer IT and security services to financial institutions. And those IT and security services that they offer to those institutions uses Cloudflare as a back end to do so, with a product we call Cloudflare for SaaS, and SSL for SaaS. And, they, of course, because they are sort of an IT digital native services company, they've always been digital native. But during the pandemic, they shifted to a distributed cloud environment, to improve agility. And, while they were doing so, they needed to ensure adequate security and availability for all of those Internet facing applications, that similarly took advantage of edge and serverless technologies so that they could provide the highest level of availability for their customers and users. Right? Because they're a SaaS provider. You know, via this customer q two software, we're able to protect financial institutions like banks and, you know, mom and pop credit unions that are using q two, software as they're basically financial software. Cloudflare is protecting those sort of, like, our customers and users via them. So, with Cloudflare, q two was able to shift their application security and performance infra to the edge, and they were able to implement infrastructures code approaches. One of their their folks on their team, I think he was the, like, Cisco was telling me that they were able to have developers actually submit and write and suggest firewall rules, via IAC integrations, which was really valuable for them. Of course, they're not doing that without guardrails. Their security architects are still able to review all those firewall rules and whatnot, but there are many use cases where the developers needed to submit certain firewall rules, because they'd observed something in the app that they needed to be able to block, etcetera. And so they were doing that. And they're improving a lot of sort of rules automation, being able to do things like, use IC and Terraform to, like, identify and create rules automatically, based on their traffic patterns and whatnot, which has been really valuable for them. So with Cloudflare, overall, they've been able to achieve a lot of scalability and, refocus their efforts on strategic business initiatives. And when I was talking to their CISO, he was just saying he doesn't know any of his peers, that have been able to actually focus on strategic business initiatives in his org rather than just simply keep the lights on and focus on, you know, just like security incidents and sort of, you know, backdated fixing all the stuff that's broken. So, very sort of happy overall with how strategic his organization has been able to pivot as a result. So looking at overall, we've talked about some specifics of the Cloudflare platform and some key launches we've had in the last year or so related to application modernization. But at a high level, if you're not familiar, Cloudflare, platform, what we call it, is our connectivity cloud. And it lets our customers connect and protect their employees, apps, and networks. We've talked mostly about apps today, but we also deal in the space of, you know, network infrastructure, security, and performance. We deal with employee access, and, you know, CR trust type use cases. And we also help our organizations our our customers do things like build apps. We have a really, really strong and vibrant developer community. A lot of people, you know, trying personal projects, building on Cloudflare and whatnot, and a lot of, you know, large scale enterprise organizations doing so as well. And they're able to build those apps using a modern serverless architecture, and delivering really performant experiences for their end users as a result and at lower cost, because the architecture. And all of these services that I've talked about are delivered on our programmable edge network, which, you know, has we have presence in over 300 cities, and it allows our customers to identify threats as they occur closest to, where those threats actually happen. Right? So the threat doesn't have to go and traverse the network a bunch and potentially create a bunch of damage. Like, we're actually mitigating it closest to the source of the threat. And so it is not even sort of traversing your infrastructure. And then, of course, making sure that that content delivery is happening as fast as the customer and the business demands. So we'll take a little bit of time right now to answer some questions. I have one question for you, Mike, which the first one is, what advice would you give to somebody who is choosing what type of app modernization project to focus on, rehosting, replatforming, or refactoring? As a reminder for our audience, those are the ones we talked about. What advice would you give to somebody who is deciding which of those three they should go with? So I'll I'll start with, kind of the goal you're aiming for, which is what what's your real endgame? Like, what's the goal of the goal? Are are you trying to get a more reliable site? Are you trying to take advantage of of protections? Are you trying to make things faster, cheaper, etcetera? Like, start with the goal because that that tells you where you need to be. The second thing I would say is don't assume you have to go straight to one or the other. Like, if you're in a case where you're like, hey. I'm partially in this cloud right now, but I'd really like to be fully serverless, work on a migration path to get there because you don't you don't really need to boil the ocean. Try not to boil the ocean. Microservices are a natural outcome that are going to give you a lot of longevity. Every microservices services project I've ever worked on has given us the flexibility, the longevity we're looking for. And there's elements of ways to work micro services into other strategies. Like, so you you can say, I'm not gonna refactor right now. I'm gonna replatform now, but I'm gonna work on micro strategies to get myself where we wanna be. So, like, don't assume you have to go fully one or the other, but it should be something that's driven by revenue and driven by a capability you're trying to build. So think about it this way. The capability you're trying to build might be the skill set required to break things down into smaller pieces, at which point maybe you don't start with the money making part of your company. Maybe you start with something simpler that you maintain, that you can build the microservices skills and understand what your team needs to be capable of to do that, that you can kick the tires on the tools and explore the the extended edge and the common edge for multi cloud strategy. Break it into those kind of pieces. Don't pick something that's gonna put pressure on yourself while you're exploring this, but get to the architecture and get yourself to a a comfortable place where you can be at the bleeding edge. I like to make the analogy that the technology industry is like that snake game from the phones years ago. Right? Like, every time a new technology comes out, the snake gets longer and it moves faster. And so you it's it's hard to justify implementing something that's already antiquated. Try to avoid doing that. Try to to feel the pressure like a serverless and microservices and AI at the edge, and it's it's all where we need to be. How can I get the skills and the comfort level with all these technologies in my team to get where we need to go? Because it really is about the human doing the work. Then, of course, the business priority comes into play. What's making us money? How do we make sure that we we improve our, you know, improve our cost of goods sold by making sure that these these things are costing us less? So, like, serverless gives us ton of advantages. AI at the edge gives us ton of tons of advantages. By the same token that I was cautioning earlier on, don't rent a server and have the meter running twenty four hours a day if your demand cycles, Like, don't justify that. AI is the same way. Don't rent a GPU full time. Like, if you can borrow it on a cycle by cycle basis from us because we sell it that way, and it's way more affordable. Like, there's ways to get the business case to kinda pay for itself. But but it's start start with, like, do does my team have the comfort to get to the place where we need to be, and what actions can I start to take to to move the needle and get that to that position? Yeah. That's fantastic. So I saw a question in the chat as well about, what measures does Cloudflare recommend to help reduce the risk of third party security concerns, and are there any, content security policies or, sub resource integrity? So great question. I'm so glad you asked it. That is what I spend most of my time talking about. And I know Mike had mentioned earlier, you know, supply chain risk is is still, you know, alive and well today, of course. So Cloudflare has a product called PageShield, which deals with, browser supply chain security and third party supply chain security, related to third party components in applications. So, yes, it does have content security policies, but we use a two pronged approach. So content security policies is just sort of one prong of that, approach in that sort of supply chain security, solution here. So, of course, we do, inventory of all of the third party and fourth party components on your website. We inventory, third party scripts. We inventory the connections that those scripts are making, and we inventory all of the cookies on your website. That's a really big use case for people who are in Europe. GDPR requires things like cookie monitoring. So really big use case there. So that's basic, just what's required, obviously, knowing what's what third parties you actually have in your app. After that, you can create an allow list with a content security policy of what type of, you know, resources you allowed on your website. And anything that's in violation of that policy, you can go ahead and, you know, see who added it. And say, for example, somebody in marketing went and added, like, a chatbot and didn't discuss it with security team, you can see that in the violation reports, the content security policy since it will be automatically blocked. And then you can go ahead and try to, like, validate if that's a a third party resource you actually want in your website or whatnot. So it's a good tool for security teams to be able to evaluate, new third party tools that are coming in maybe without, the security team being consulted potentially. It prevents, you know, teams like developers or marketers from potentially circumventing, security in that way. And then, of course, this is a really important sort of component of that second prong of detection that I talked about. So when it comes to supply chain mitigations, just simply saying a script is trusted is not enough. Right? Say, for example, you use a third party payment processor that you trust, like, say, you use something to process credit card payments on your website if you are, you know, an ecommerce provider or maybe you are in, like, you're a local city government and you're processing credit card payments for park reservations or something. Many, many people have to process credit card payments a lot of times rather than building, something to process credit card payments from scratch, people will consume a third party component. So really common use case here that I'm just using as an example. Say, for example, that third party component, that company gets compromised. Maybe something like phishing happened, and that library that is used across, you know, hundreds of thousands of websites gets compromised with a data obviously, that would be pretty catastrophic if it was a commonly used library, like, for payment processing. But, with new regulations like PCI DSS four, which regulates everybody who takes credit card payments, both on their, you know, digitally and otherwise, merchants are actually liable under PCI for basically, the third party components they're using for payment processing purposes. So, if a third party component gets compromised, via supply chain issues, then, you know, you as the website owner are responsible for protecting your end users from things like data exfiltration calls or say, even, like, a malware packet, gets inserted and, like, they can download key logging or, like, turn somebody's laptop into a crypto mining, like, network. We've seen that happen, unfortunately. So, those are just a couple use cases. With Cloudflare Page Shield, which is the product, that I'm talking about, you can we basically use a combination of, like, threat intelligence fees and machine learning models to identify, if those third party components, whenever there is a change to that library that you are pulling into your website, we basically download it, on our edge network and run it through an ML classifier in sort of a quarantine environment that's separate from yours, check it for things like malware, data exfiltration calls, mage cart style attacks, those types of things. And we basically say, okay. You know, like, there's an attack or a sort of, like, malware or whatever that was detected in this script. Do you want to redirect it to another page? Do you wanna block it? What do you want to do? We don't automatically block it for you because if we do, it would break your website and you would be very upset at us. So, we don't do that automatically. But, basically, it's a really good tool for folks like SOC analysts or security admins, to be able to identify when a supply chain attack is happening in real time, redirect that third party component, or quickly find another third party component to use. So, that's an overview of how we do that sort of supply chain, security. And, let me go ahead and just real quick paste a resource on that because I got asked about it in particular. You'll see lots of resources on this web page about what this product does and, how we relate to things like PCI compliance, and how we help our customers with that. So if you're interested, definitely go ahead and check that out. And while I'm talking about resources, there are also a number of resources in the docs section of Goldcast related to application modernization. We have an infographic there for you about the ways Cloudflare helps with application modernization. We have a sort of a brief overview of our recommendations, sort of similar to what Mike and I talked about today for organizations looking to modernize their apps. And we have, so definitely go ahead and check out all of those resources. If you're interested in learning more and just reading up a little bit, or if you wanna get on the phone right today, you can scan this QR code and somebody will reach out to you to talk about how app modernization works in your environment. So thank you all so much for attending. We really look, really enjoyed this conversation with you all today. Take care. Thank you all.