Zurück 
In the past, there was a clear demarcation between the role of the enterprise network and the internet. Network architects focused on the networks that were under their direct control, and relied on their service provider to provide access to the internet.
With the rise of cloud applications, we’re seeing a shift in the demarcation. That’s because network architects have key business applications that are hosted in the cloud, and now they have to think about network performance in a different light, with access to the applications following traffic paths that are mostly outside of their network’s boundaries. Additionally, each application also has unique requirements around network performance that must be considered. For example, webinar (one-to-many) streaming needs high bandwidth, real-time collaboration needs low latency, and backend systems hosted in virtual private clouds may have very high resilience and redundancy requirements. Further complicating matters, unlike private applications, cloud applications don’t have a predictable set of IP addresses and ports, and are constantly changing and evolving, making them a nebulous and ever-changing target. Perhaps the term “cloud” is even more apropos than we realized!
Security, of course, is a critical enabler of applications, and that’s why the Secure Access Service Edge (SASE) has now emerged as an important conceptual model for describing how to protect users and applications that operate beyond the traditional network perimeter. SASE is a model that recognizes that the location of the user and the application can no longer be thought of as fixed. In other words, the traditional castle-and-moat approach to application and network security doesn’t protect people who aren’t in the castle.
Netskope’s platform engineering team is responsible for designing and operating NewEdge, the private security cloud on which the Netskope Cloud Security Platform runs. There’s a tremendous amount of interest from customers wanting to know how to support and secure their complex mix of applications, managed (IT-led), unmanaged (Shadow IT), on-prem, private apps in the cloud, third-party SaaS, and more. In many conversations about SASE, I find it very helpful to draw upon my decade of experience in the CDN space to walk through the elements that factor into the path that end-user traffic takes under various scenarios. This is because SASE is a new topic for everyone. The architecture of carrier networks, cloud providers, CDNs, and the internet is not necessarily widely understood, and sometimes the language for many concepts is not standardized across the industry.
Take the term “data center,” for example. In my world, a data center meant a physical building with concrete walls, raised floors, and carefully monitored environment controls. I’ve always presumed that if you told me that you have two data centers, you own two such buildings, like the famous NAP of the Americas in Miami, Florida (congratulations!). Today, only colocation facilities, telcos, a handful of managed service providers, and a very small number of enterprises own and build their own “data centers.” In fact, many colocation providers don’t own the building, they just lease space within a larger data center. In contrast, a point of presence (POP) is a location where you have placed servers, but don’t own or operate the data center. Yet in the security space, you will often see “POPs” referred to as data centers, which can sometimes cause confusion.
Semantics aside, I now recognize that the definition of data center is changing, and that the easiest way to facilitate a discussion about points of presence is to use the language that is the most widely understood in the security space. In this article and in the future, I’ll use “data center” to refer to any location where servers or network equipment is present.
As an architect, I love discussions with our customers about end-to-end latency and how to ensure a great user experience. This is easy to do with a big empty white board and fresh box of dry erase pens. It’s a bit harder to have the same discussion in writing, when we need to first check if we are using terms in the same way. This is why I felt that it is prudent to explain the “path of the packet” in this blog.
In the Secure Access Service Edge (SASE) model for delivering cloud-based security services, the “packet” flows through several logical components and boundaries, and it’s useful to provide them with na