Choice is a good thing, as long as you can decide on the thing that’s best for you in the end. The problem with choice in technology is getting the information you need to do that. According to my input from 88 enterprises who had evaluated technologies to connect hybrid cloud applications, there are a lot of “less than useful” statements out there, and more that are downright misleading than they’d like. Let’s start with some things I think are helpful in baselining the situation.
Most enterprises are not, at this point, trying to replace branch connectivity with the same technology they’d use to connect to the cloud. Of those 88 enterprises, the target applications were those that used public cloud technology as the on-ramp for general remote access to company data and applications, meaning not only “hybrid cloud” but in the main applications dealing with non-employees. Only 12 of the 88 were targeting all applications and workers as well as non-workers, and articles suggest that cloud connections were part of a total move-to-the-cloud initiative, a mission to replace MPLS VPNs (or VPNs overall) or both.
Then we have the fact that cloud connectivity as a mission has a “standard” approach. Users almost always access these applications through the Internet, so there’s an access network in play naturally. Within the cloud, the provider will use a set of private IP addresses to connect the in-cloud components, a strategy that’s also used in most virtualized data centers. Think of this as the “cloud-datacenter-network”. Finally, the cloud provider will offer the ability to expose some APIs in the cloud onto the public Internet, the company VPN, or both. In the case of the VPN, it’s optional whether a direct line to the VPN is provided. This approach, which doesn’t rely on anything new and trendy, is used by 60 of my 88 contacts, and I think that it’s actually the choice of over three-quarters of cloud users.
Building off the standard approach are two other options, but according to those 88 enterprises the choice between them is usually made implicitly. They are SD-WAN and SASE.
SD-WAN is an over-the-Internet VPN option that was originally used to extend VPN access to remote sites too small to justify MPLS VPNs, or where MPLS VPNs were not available. An appliance (or software instance hosted on a server) is deployed in these sites, and they link back to an appliance/instance in the data center or other convenient location where an on-ramp to the MPLS VPN is available. Because a software instance of the SD-WAN device is usually offered, vendors made it possible to host this instance in the cloud to provide a mechanism for traffic in the cloud to exit to the company VPN. This option is regularly used by companies that have adopted SD-WAN to support small/remote branch sites.
SASE (Secure Access Service Edge) is a combination of a VPN service (usually SD-WAN) and additional security features, and it emerged as a solution to the problem of making application security work effectively in the cloud, with an Internet on-ramp. Application security measures adopted in the data center are less effective and efficient because adding in the cloud either strands some components upstream of firewalls (where cloud-resident data would be available) or requires hairpinning traffic out of and back into the cloud, which increases costs and latency. SASE provides a VPN on-ramp (as noted, usually via SD-WAN) but also moves security in front of that, securing the whole hybrid cloud workflow. Thus, SASE is most common where there is no SD-WAN branch connectivity in play and where cloud front-end technology is widely used.
On the surface, it might seem that the whole world is moving inexorably to SASE, but that view is justified only if you think that everything is moving to the cloud, or at least that there is a lot of protected assets moving there. Security-driven technology of any sort should be deployed to protect the stuff that needs protecting. Of the 88 enterprises I chatted with on this, only 19 used SASE at all, and only 3 said they used SASE extensively or exclusively. However, my exploration of these three suggests that all of them retained extensive data center security technology and used SASE only for incremental cloud-centric applications. One example was a company who added customer sales/support portal technology using SASE but all their workers in all their sites still accessed their applications directly via the data center.
That point regarding the actual SASE use by the three enterprises raises another important question, which is whether enterprises understand the whole SASE story and value proposition. Of the 88 enterprises, 12 told me that they “fully understood” SASE and all of them were in the group of 19 that had at least some SASE use. That seems suspicious to me because it suggests that everyone who fully understood SASE adopted it, but it turns out that the twelve all say that their understanding came with the decision to deploy it. Interestingly, there were seven users of SASE that didn’t fully understand it but apparently deployed anyway. These all made the decision based on vendor or cloud provider suggestions.
What didn’t enterprises who fully understood SASE get? Of the 76, the biggest missing piece was the most basic; value proposition. None of this group were “confident” that they could define the characteristics of their application access needs that would be triggers for SASE consideration, though 53 said they were “pretty sure” they could do that. But within that group, the most-cited characteristic was “running in the cloud” (48) and the next-most was “security as a service” (46). The first isn’t much of an insight since the cloud is where SASE runs, and the latter could actually be an indication that SASE vendors are finding the “real” justifications for SASE too complicated to use in a sales presentation or take to the media.
A lot of this may sound surprising, but it’s actually consistent with a truth I learned early in my decades-long effort to survey technology buyers. Enterprises almost never conduct extensive strategic reviews of technology options. They can’t attract or retain the necessary technology specialists and they can’t justify the time and cost required. What they do is address problems and opportunities, by picking an offered option when they arise. That may be increasing their risk of being driven into addressing a problem or opportunity that’s really not presenting itself at the moment. SASE may be an example. It’s a critical technology for companies who are moving the front-end piece of most or all of their applications to the cloud, treating workers and stakeholders and prospects and customers the same rather than presuming the workers are sitting in a satellite location. Most companies, I think, are headed in that direction, but few are there today. Thus, SASE is likely being objectively overhyped.
