Name: From Complexity to Simplicity: An Advanced Framework for Enterprise Network Modernization
Uploaded: 2025-08-29T17:56:09.819Z
Duration: 40 min 8 s
Description: From Complexity to Simplicity: An Advanced Framework for Enterprise Network Modernization

Transcript for "From Complexity to Simplicity: An Advanced Framework for Enterprise Network Modernization": Hi. My name is Brian Takayoshi, and I am director of product marketing at for network services at Cloudflare. I'm gonna be walking you through navigating your network transformation. Now the first thing about network transformation, I want to point out that most organizations build enterprise networks, and they build these networks with a great deal of work, effort, and skill. And these networks are beautiful in themselves. I tend to think of networking as being an art form. It is just as, beautiful as painting, as music. Being able to do networking properly is definitely a skill and craft. Now, the thing that about networking is that if you take a look at what a network's designed to solve, it's built to connect users and offices to applications. But the thing is is that over time, these conditions have changed. Because when you think about how users are located, they're not located in offices necessarily anymore. They are app using applications that are not necessarily in the data center anymore. And this is because that the pandemic has rewritten the rules of how work is really done today. When you think about these conditions, how the underlying requirements for networking have been realigned to an entirely new set of conditions, then all of the things that organizations had to do to allocate resources such as office space or desks or even networking had to change. Some businesses were very good at changing and some businesses needed to address this as a space to develop more agility. And that's why organizations, when you think about the network today, had been traditionally built around the firewall. If you take a look at networking and the traditional enterprise had been set up with the enterprise firewall as being the delineation between the trusted network that you manage versus the untrusted network that's exposed to the Internet. With that in mind, that the conditions for how you redo all of this when a greater portion of your users are located outside of the firewall needed to change? What happens when the applications are no longer solely within the data center but also within the SaaS applications that you use today or the public cloud and so forth. These ideas about how to address modernization is why underlying conditions for what organizations need to solve for had radically changed what the design looks like. But because the organizations are from starting from a place where networking looks something like this, they often had to introduce more and more products to compensate with the different conditions that are in there. These conditions add grit to the engine. And what I mean by grit is that if you take any car, for example, and you pour sand into the engine, it'd be able to address some of the dirt because that motor oil has been designed to overcome a some grit. But as you add more and more grit over time, this is destructive, and, eventually, the engine fails. That's why that when you take a look at what grit looks like inside the enterprise network, it is often the accumulation of all these different products that tend to be inserted into the network path in order to address functionality and conditions as the different scenarios for security arise. Each one of these products is another place that policies are being enforced. Each one of these products require the organization to bring down the network traffic path, insert an appliance or insert a service, bring the traffic back up, and then test the various conditions. But as you see, this network that has all of this grip that's been inserted into it ends up being an overwhelming amount of work and effort that must must be sustained as organizations now realize that the fragmentation of traffic has magnets so that we don't really know what policy is gonna be enforced at any given time because it's impossible and indeterminate where the traffic is going to go at any particular time. It's not because that the organization had done anything wrong. They're trying to adapt the network to accommodate the changes in the requirements and security. But the network design fundamentally needs to change in order to address how do we how do we deal with all these different conditions. Now what if you could use a network that is designed for a global delivery service, one like Cloudflares, for example, where the global data centers are capable of being able to onboard traffic, making it so that you don't have to go out and build another data center. You don't have to think about when you're gonna expand into another location about whether or not that I have to build yet another data center to address new sets of requirements. What if instead of having to do all this work to insert the new, appliance, what effect goes away? And use services that are within the network to make it so that we can just turn on new functionality when we need it rather than having to bring the network down in certain appliance and continue trying to operate it over time. What if we got rid of all of that and take the element of trust completely out of the equation as well? Because that the whole concept of having a trusted network in of is in of itself is a risky proposition. Make it so that the network itself is completely untrusted. Now I realize that a lot of these concepts take a lot of conceptual models about what we could do with the network, But let's think about this from the standpoint that this network does exist. It's Cloudflare's network. And Cloudflare, because that Cloudflare has a global network that's designed to onboard traffic in different locations and connect users to different locations, being able to build a way to reach the applications that you are looking to reach, whether that it's in your private data center or it's in SaaS or it's an Internet or in the public cloud. Make it so that your users can connect to the applications they need. And because the CloudFlare has been designed to support the global nature of these organizations, making it so that services can be delivered from a cloud flare data center, making it so that when you have new requirements or conditions change or you need to redo where your users are located or where your applications go, it means that you don't have to change any infrastructure because, again, the delivery of the networking and the security services are done through CloudFlare. This concept of how CloudFlare's network can augment, supplement, and make it so that you can use CloudFlare as a network as your network, making making it so that this is this concept is really what's behind how we address network modernization. Now to start thinking about network modernization, I think it's important to break down network modernization. What's the definition of network modernization? Well, if you come from the starting point that an organization has an enterprise network, they always have four powers of network traffic that they need to address. There's inbound traffic, for example. There's outbound traffic from users reaching, going to the Internet. There's cloud networking with the East West traffic path going between cloud applications. And then there's WAN networking, which is the East West traffic between sites, for example. The thing is that organizations that had been thinking about compartmentalizing their modernization journey tend to look at the very specific products that exist within each of these and make it so that each one of these become a separate technology decision. Remember, it's still one network. We're just talking about the different ways that traffic flow. But because that the industry has built products that are specific about how you address the security around one particular traffic path, then it makes us so that organizations tend to accumulate multiple cloud based products as they address their modernization journey. For example, because that many vendors, many customers may have traffic that is inbound to their network, they may have products that are, such as WAP or CDN, that make it so that they can secure those traffics, but secure that traffic app. But that traffic is being is just one of the ways that your network's being utilized. But and those products don't do anything, for example, for the outbound traffic, which makes it so that the customer now addressing the second project of outbound traffic then has to look at the world of Sassy, Swig, CASB, and ZGNA, and so forth. That's why that because network modernization is actually a multistep journey, organizations that don't foresee the challenges of how these network paths all fit together could end up making a crucial mistake, where the journey for how they address networking for each of these traffic paths makes it so that they end up with a cloud environment that's just as complicated as the network that they were trying to change, to modernize. Now when I think about what can happen, it ends up being that a lot of organizations that maybe address this on a project by project basis may not foresee the event horizons of things that are happening in the future. What I mean by that is if you take a look at that first project, inbound traffic, you can pick any vendor's product and you'll get some benefit from your effort. Why? Because you're starting from the beginning. You're starting from how do I address modernization. So I am gonna pick a product that's gonna help me get some benefit for my effort. So I'll deploy maybe some type of WAF, for example. What is not yet visible when you're standing at the event horizon of the first project is that you still need to address what's going on with the other network traffic paths. You have project two, project three, and project four. And those projects address whether it's outbound traffic LAN networking or multi cloud networking, for example. And as you reach the start of your second project, then you're actually starting all over again. Because, again, the products from the first project doesn't help project two. You end up on the blue path where there's diminishing returns for your effort. Because that as you start project two, you end up having to spend more effort to get less benefit because now you're deploying another platform. You're deploying yet another management infrastructure. Your your effort never goes down because that now you're adding more vendors to the mix with products that were never designed to work together. And then it ends up being that organizations find their benefits tend to taper off over time. The only way that you can achieve modernization's goals and the way that you achieve escape velocity from this is to take that blue line and shift it to the left. The way that you shift it to the left is reduce effort. That's how you get more reclaim more benefit out of this because that if you reduce the effort, making it so that by choosing the right product with the first project and choosing a platform that can use that can support your goals for project two, three, and four makes it so that organizations that are now looking at the long game, the long, goal long sides of of their goals makes it so that now when they deploy project one, all that infrastructure that they deployed is in place to address future projects. It reduces the effort because I don't have to go deploy another product. It's already in place. It's a matter of just simply enabling and configuring the services that I need to address outbound traffic or to address WAN network or to address multi cloud networking. And that's really the key for being able to get modernization done properly, is to perceive where your end game is rather than looking at as a as projects that are independent of one another. With network modernization with CloudFlare, there's really, four key areas, and we talked about those in terms of traffic directions, inbound, outbound, the East West with LAN, East West with cloud networking. These break down into specific projects that organizations can address. The first one that I wanna talk about is network protection and specifically network protection for your data centers. Now going back to our diagram, your data centers are exposed to the Internet. That's very that's the purpose of what public facing applications are intended to do. The public facing infrastructure to support those applications are thus exposed to the Internet and puts the firewall in a crucial location where traffic is diverted to a a secondary firewall, a DMZ, for example, where that it it makes it so that the organization can look at the traffic before it's passed forward to the particular applications in those in the DMZ or in the public cloud. Now the thing is is that a firewall is designed to filter traffic, but it's not designed to deal with the overwhelming amount of traffic that can occur when bad traffic is sent to it, when whether it's just a pure amount of garbage traffic or it is a malicious traffic. When the firewall is no longer able to process the the amount of traffic that's being sent to it, then legitimate users are not able to continue to use those applications. And that's really the underlying problem with DDoS and what public facing networks are dealing with. What Cloudflare does is that Cloudflare makes it so that your organization's public facing infrastructure is protected because that it it filters all traffic before it reaches your firewall. Being able to think about this as a front door is a useful analogy because that it makes it so that instead of the traffic going directly towards your firewall, fire CloudFlare access a barrier to make it so that organizations can have protection against all the malicious things that can happen on the Internet. It's also a useful starting point for the modernization journey because that organizations that are thinking about improving how their networks can be modernized can best shield theirs their network from all the stuff that's being exposed starting with those public facing applications. The way it works is that the customer's public facing prefix is advertised through CloudFlare. And CloudFlare has what is known as what we call Anycast, making it so that all of our data centers are addressable in the same way. So by virtue of broadcasting the customer's prefix from around the world from Cloudflare's data center so that the attacker's, botnet sees one of the Cloudflare's data centers that's closest to them, makes it so that it's incredibly difficult for the attacker to generate enough traffic to send to build, DDoS attack in the first place. Why? Because that the distributed nature of DDoS makes us so that the attacker's bots are located in multiple different locations. They're gonna be seeing a different Cloudflare data center wherever that particular bot exists. And it makes it so that, let's say, the bots that are in The UK would see a Cloudflare's UK data centers. Bot that's in the Eastern United States would see those, data centers that are in the Eastern United States. It makes it again because that the prefix is being advertised from all these locations and our Anycast network makes it so that all all if the attacker thinks it's sending the traffic to the victim's, firewall, it is being intercepted by Cloudflare's network absorbing and diffusing the attack before it can generate a sufficient amount of attack a sufficient amount of traffic to overwhelm the customer's traffic and, at the firewall in the first place. Now that's just one of the key, elements behind what this is how this is all set up. It's also because that we have the in threat intelligence of being able to detect the all the different types of attacks that are happening around the world even before it reaches your network. Next is we can apply our threat protections and our DDoS protections through Magic Transit and Magic Firewall. So a policy enforcement's in place to stop the attack automatically. And unlike any of the DDoS solutions that are on the market today, it makes it so that you don't have to push a button to turn on the traffic. Because many of the DDoS protections, whether they're appliances or their services, are typically kept offline because of the latency that they add to the network traffic path. With Cloudflare, that's not a problem because that all traffic is going through one of the Cloudflare data centers. Anyway, it is the first stop for any public facing traffic to be intercepted and enforced with policy without having to insert a diversion to the protection like other products do. It makes us this protection is always on for simplified management and reduced costs. That's really the first part of the modernization journey. The second one is thinking about zero trust and SASE and SSE. The reason I'm bringing this up is because a lot of organizations have traditionally used the firewall as the the policy enforcement point, making it so that whether users, whether on prem or even over a VPN connection, for remote users would typically connect to a firewall in order to reach all applications, whether it's the VPN to get into the internal data center, but also to reach the firewall, to reach the SaaS, and to the Internet. It's incredibly inefficient because organizations do not have tons of firewalls that they have services running from. It makes it so that there is really a a constraint on where users can connect from because, like, when you are connected from a distant location to a distant firewall, the latency that it adds makes us so that organizations are tempted to leave the protection off as much as possible. That's why organizations are really do grappling with this problem because that they want consistent enforcement of policy, but they don't want the latency and damage to the user experience. The same problem occurs when you start to think about branch locations. Branch locations don't have any applications. Branch locations, by definition, are really just where users operate, and they need to connect to an application over the network. Traditionally, they've been going to the data center. But as more applications shift to the cloud, they still need to get to the enforcement of policy to reach the Internet and SaaS applications. But, again, because of the distant location over tradition hub and spoke networking and the performance speeds typically seen in MPLS, for example, and the high bandwidth demands flow that people have for Internet and SaaS applications makes it so that this user experience is not fantastic either. Now organizations have been super tempted to address these problems by going to direct to Internet. Direct to Internet creates a new traffic path where traffic is either broken out from the VPN for the user, or there's a split tunnel from the branch location so that traffic is not going strictly over the branch router to the firewall, but there is a path to the Internet as well direct from that location. Now with direct to Internet, now you might have a better network performance path because that now users and branch locations don't need to go back to a distance firewall, but you introduce a security problem. Because, like, again, if that firewall was the location that you are enforcing policy, now you have a new traffic path that's not being inspected by policy. So there's fragmentation over what policies are being forced at any given time. This creates secondary problems, third, tertiary problems where organizations are trying to grapple with how do I keep the user experience, keep performance up, but make sure that the security is in play. The way that we can do this is through what we call the secure access service, edge, which is the the acronym for how organizations can use network delivered services for security deep being delivered around the world so that it's not constrained to the number of firewalls that you run, but rather through the services that are delivered from Cloudflare's connectivity cloud. So that from Cloudflare's locations, from over 330 cities where we operate data centers, organizations can simply connect their users, their, data centers, their offices to the nearest location. And the nearest location makes us so that from there, Cloudflare's network access the delivery of network services and the enforcement security policy, making it so that you can connect anywhere around the world no matter where the application is. Being able to do this makes it so that organizations can now address these scenarios without having to without without having compromises between performance and security. They get both because that connectivity cloud distributes the services so that they're closer to where your users and where your applications are located, making it so that enforcement of the policy can be done without the latency normally incurred by sending traffic all the way back to a firewall. The third part about network transformation and modernization that I wanted to address is actually a a consequence of what organizations have been using as a compensating control from the previous discussion that we just had. Now, because that we were thinking about this idea about how organizations are simplifying, it's because that we had been discussing about how organizations are really running their desks. There are fixed resources like office spaces similar to a hotel where you check-in for the office for the day. You get assigned a desk, and then you can get networking not by plugging into a wall, but by connecting just like you do at a coffee shop. If you can work effectively at a coffee shop, then couldn't you do the same thing when you're working at the office? With that realization, it actually provides a, a path for organizations to address complexity at the branch location. It's a concept that Gartner calls coffee shop networking, mimicking the user experience that you see from users that are being at a coffee shop and applying those ideas back to the branch. Now remember, that previous discussion that I we were talking about where users were remotely connecting to a firewall or branch locations that were tempted to use direct to Internet, they were dealing with this problem space of how do I get security and how do I get that into that user's traffic path. The thing that organizations had tried to do was to put firewalls everywhere. And that idea of the proliferation of firewalls, security appliances, connectivity over SD WAN, all of those have led to a stack of devices that had been inserted at branch locations everywhere. And, again, because that branch locations are remote by their definition and there's not a IT staff that's monitoring all this equipment. It's proliferation of a problem space that makes it so that organizations now have a reliable reliable, where reliability begins to suffer. Because how do you deal with these devices that are prone to fail and making it so that they can keep them operating all the time that businesses need them to make the sure that users are always connected to applications. Now the path forward for doing this and the path forward to doing coffee shop networking is to be able to simplify that stack at the branch. And the way that you do that is not by adding more functionality at the customer's edge. It's by delivering services from the cloud edge. And the way that is possible is by transforming what organizations have been thinking about about whether or not good it's a good idea to put more appliances in more locations, but transform transform that idea to put security and networking in every location that you need by using, again, the CloudFlare Networks, global network, to deliver those services. So instead of having to deal with the distant connections that organizations face when connecting users to applications, you can use the a lightweight device to simply take the user, the the office's traffic to a Cloudflare location and get the benefit from the SaaSy services that we just discussed in the previous section. It's building on top of the networking concepts and the convergence of security services delivered through a global network and making it so that the security stack that's actually required at any given location becomes much, much smaller because that you don't need to have to implement those through devices that are inserted into the network path. That's the key behind coffee shop networking. The fourth thing that I wanted to discuss is cloud networking. Now the problem space with cloud networking is that when you look at all the VPCs that your organization operates, for better or worse, they operate like a independent, data center. Each VPC in a any given cloud access a DevOps operated data center. Now it's logical why organizations like this concept because that if the DevOps team doesn't have to go to the firewall team in order to set up a connection problem, connection to another site, then it makes us so that the DevOps teams can operate much more quickly. They're operating their own infrastructure as expressed through the public cloud. The problem space starts to occur when one DevOps team needs to work with a second DevOps team, or one club or one public cloud needs to interface with another public cloud. Because that even though the dev ops team may have full control over the the the mini data center that they created within any given VPC, these constructs only exist within that VPC. It makes us so that the connectivity on how you do, connection and secure the the connectivity between VPCs becomes now highly problematic because that the network team is not able to help. They these constructs that exist only within the VPC need to be configured in order to facilitate the connections outside of that VPC. Now what Cloudflare does is it acts as a conduit so that organizations can understand the underlying constructs so that organizations can facilitate the connections between VPCs. It makes us so that Cloudflare as transit makes us that you can connect your VPCs to Cloudflare and thus establish the understanding of the constructs and orchestration so that or you can now build the connectivity without interfering with what the DevOps team needs for their, autonomy for the things that they manage within their particular VPC. It makes it so that as you deal with the complex networking problems that may exist in a given cloud, or as you start to grapple with how do you build applications that span multiple clouds, You can do so by addressing them through CloudFlare and using very similar concepts behind what we talked about with linking your offices, but applying them to the public cloud so that you can now make it so that you can adapt your cloud infrastructure so that as you go from private cloud to public cloud or you address multi cloud applications, you can do so with the proper networking that's in place. Now with that in mind, that that sums the my thoughts about the network modernization journey. All this is centers around how CloudFlare can CloudFlare's network can supplement the way that you think about networking today. And it makes this all the projects that you're thinking about networking, how can they be supplemented if that infrastructure has already been created for you so that all you need to do is configure Cloudflare's network to do the task that you need, whether that we're talking about inbound traffic, outbound traffic, east west from your branch locations or east west through your clouds. Being able to do all these things through Cloudflare is how organizations can start to take a fresh approach on how to address the full modernization journey. If you wanna learn more, there is a paper for developing a strategy for your network modernization that covers many of these concepts that we just talked about today in far more depth. So with that, that, I think that is gonna be an excellent way that you'll be able to take the next steps to understanding how to address network modernization using Cloudflare.