What SLAs are in a SASE service? That’s the question I’ve been asking myself of late. As I look at the shakeups in the SASE space, understanding what you get in a SASE service is of utmost importance to my customers.
Of course, the best way to understand what any provider delivers is to trial the product. But as I’ve pointed out previously, you can’t and nor should you, trial every SASE solution on the market. By the time you reach your POC, you should be down to one maybe two vendors. So how do you narrow the list of providers before testing each solution?
SLAs: The Necessary Evil of the Service Industry
Feature comparisons fail to capture the performance and characteristics of services. For those, we’ve relied on service level agreements (SLAs). They provided the services’ base performance characteristics — latency, packet loss, and jitter of the service as well as the management options around the service, such as time to repair. They were the guarantees that service providers actually delivered the services we expect.
Of course, SLAs have always been a necessary evil in the service industry. Over the years, few of my customers ever believed that an SLA could possibly compensate for the lost revenue and business impact of downtime. But stipulating in writing and backing with any kind of guarantee brought substance to what otherwise was an intangible service acquisition.
SLAs: A Relic of the Past
As we’ve moved from MPLS and legacy carrier services to SD-WAN and SASE, SLAs are becoming a relic of the past. Few SASE players, if any, offer the kind of performance-based SLAs we saw in carrier services.
Yes, SASE and cloud providers talk about SLAs, but these are SLAs limited to availability not the metrics that measure the ongoing performance of the service. Take, for example, Azure’s SLA. SLAs are offered for both Azure Firewall and Azure Virtual WAN but in both cases they only cover availability — <99.95% yields a 10% service credit; <99% yields a 25% service credit. AWS is another example. They have an additional SLA level with 100% service credit if uptime is less than 95%, an unlikely occurrence. It is otherwise the same as the Azure SLA.
And it’s not just the new cloud services that don’t offer legacy SLAs. Take Aryaka, for example. The Aryaka Uptime SLA governs, well, only uptime, promising 99.99% for their WAN and connections to Azure-ExpressRoute, AWSDirectConnect, and Oracle-FastConnect. No other service is supported. Aryaka’s SLA Credit will equal 1/30th of the customer’s monthly service fees for each day they miss their SLA.
Instead, performance-based SLAs are being replaced by technology and trust. The proliferation of affordable Internet capacity allows providers to over-engineer their services so there’s less chance of packets being dropped, and hence less of a need for standard SLAs. This is best seen in the last mile where, in theory, diverse internet connections with SD-WAN should be able to provide the equivalent performance as with an SLA, at a lower cost but there’s no guarantee. SASE and managed SD-WAN service providers say we have to trust them. Take their word for it that their performance will be close enough to that of your legacy network so as not to compromise application performance.
Do you take their word for it?
I’d like to hear your opinion. Ping me at steve.garson@sd-wan-experts.com and let me know.
