SASE Delivery - Is A PoP always a PoP? What to look for...

In my previous blogs I spoke of the delivery-related problems when there are no local PoPs, or the equivalent technology in place to successfully deliver those services, and how this potentially manifests itself in platforms such as SASE.

As, noted, there are – from vendor to vendor – elements of information, including real-time status updates, but the level (and complexity) of that information does vary enormously. So, here are a few pointers to look for when trying to grasp exactly what each vendor offers in terms of a delivery network.

Locations: Most vendors seem to provide at least some PoP/delivery network location information –though not all! In some instances, the number of PoP locations is cited, but with no reference whatsoever to where they actually are. There are also instances of SASE being delivered through PoP locations which have peering relationships, but then with no actual reference to who those actual delivery partners are. This stuff isn’t supposed to be a secret! From my IT manager days, I know the pain of trying to translate “marketingese” into reality – in the old days, IBM were past masters at it! Another point to make on locations – whether these are described as PoPs, Data Centres, or whatever (see next section) is that, on inspection, a so-called specific PoP/DC location does not necessarily equate to a separate geo-location – i.e., an actual separate physical location. In some cases, it might be a colocation, or multi-location scenario, with designated individual delivery points, but actually from the same physical space. And, in some cases, the cited number of PoPs just doesn’t seem remotely credible in terms of providing global coverage – 16 for example?

A final point worth noting here is that, in some instances, there is a reference to a regional surcharge, depending on where you want your SASE delivered to (SEAP was a notable example). Makes pricing up the competition, er, interesting… (with no reference to actual surcharge costs in these cases).

What is and isn’t a PoP?  With reference to the housing market, the common citation – in the UK at least – in terms of the three most important points of attraction are namely: location, location and location. In the world of SASE delivery however, this isn’t necessarily the case, as we’ve already noted. Moreover, given a stated location for a delivery point, it’s often not clear exactly what that location is actually delivering! A fundamental problem here is that different vendors use different terminology to describe their “PoP” or equivalent and, in some instances, even the same vendor cites different type of service delivery locations, such as a PoP or “compute location” or “DC”, or “secure edge services” or “Secure Web Gateway”.

Regardless of the nomenclature, what a potential customer needs to know is what exactly does each location actually deliver? And to where? It might be that different processes are carried out at different country locations, rather than a single location, which obviously suggests potential latency issues, as outlined earlier, as well as consistent quality of delivery from one location to the next. In some cases, a vendor will state implicitly what each delivery point can achieve, which is exactly what we are looking for. As a Gartner-derived service, SASE naturally is expected to follow Gartner guidelines. For example. these include a single pass screening of traffic which is designed around a PoP providing all security functions from that single location, but this doesn’t appear to be guaranteed in many cases, based on published evidence.

Even where real-time status check links are provided, it’s still not clear what the actual coverage (and quality thereof) is, simply the status of the location. Bear in mind also, that not only are we talking specifically about SASE services here, but that those delivery points might also be providing many other services, rather than being dedicated to SASE. What is clear, is that background information is often anything but. While it provides the IT manager with some basic evaluation ammunition, the key requirement is to ask each SASE vendor:

• Exactly what their delivery network consists of and where it is located (including via peer relationships) and what service levels are guaranteed.
• What each PoP/compute point actually delivers and where, otherwise, the full raft of services are actually being delivered from, with respect to the customer locations.
• If there are any additional costs involved, above and beyond what tariffs/prices are quoted – for example, for the aforementioned geographical surcharges.
• Planned future roll-out of the delivery network.

So, it’s not a truly scientific starting point for narrowing down who your SASE provider should be – or SaaS, or PaaS etc, such are the complications of the modern EaaS (Everything as a Service) IT world. Only a live comparison test based on delivering to the customer premise locations can do that, but it is a means of potentially ruling out certain potential providers and escalating others to form an initial hit list.

Good luck!