Enterprises are obviously getting concerned about cloud costs, and according to those I’ve talked with, the concerns are greatest because of usage pricing. While it’s possible to get an IaaS instance on a fixed price, things like scalability and even traffic can introduce at least a usage-price component to the picture. It’s this added dimension that tends to create cost overruns and CFO angst.
The same issue may be hitting network-as-a-service, or NaaS, according to research cited in an SDxCentral article. The article also says that research shows that cloud-native enterprises and startups will be the earliest adopters of NaaS. My own contacts agree with the main point about NaaS costs, but with some important qualifications. They do not agree with the second. In fact, my research suggests that any NaaS use by the groups cited may be more accidental, and due more to a tolerance for usage pricing than any proactive NaaS decision.
It’s always dangerous to generalize, so the old joke goes. Better to say it’s dangerous to make general comments on any hot tech term because you can bet there’s no consistent definition on which to base comments and analysis. NaaS, to some, is just about expensing networks versus basing them on capital equipment. NaaS, to others, is about being able to define connectivity on a per-user, per-application basis. To another group, it’s about pay-as-you-go, and that’s the definition that renders the main thesis of NaaS being held back by costs valid. For the other models, usage pricing isn’t implicit and so the argument that cost is holding NaaS back is invalid.
One thing this demonstrates is that NaaS, like pretty much all those other hot tech topics, needs very careful service positioning in order to succeed. Tossing out the term invites misunderstandings given all those possible meanings, and that’s going to create a world of uncertainty among buyers. I’ve found that a buyer, presented with a vague or poorly understood value proposition, will tend to say they fear cost even though cost may not be the root of the problem. If you’re pushing NaaS in a form that doesn’t expose users to usage pricing, you need to say so.
Even if NaaS has some usage pricing component, that doesn’t necessarily expose users to higher costs, or even unpredictable costs. The problem here is that NaaS providers tend to oversell their offerings, perhaps even sell them in situations where NaaS isn’t a good answer, and perhaps selling a NaaS model that’s not useful for the specific situation an enterprise might present. A “pure usage” NaaS model without other features tends to be valuable when expected traffic is highly bursty and it’s necessary to size the network service to the peaks to assure QoE. If there are features to manage per-user/per-application connectivity, then that may add enough security benefits to mean that some usage-price risk can be accepted.
Speaking of that risk, the article’s statement that NaaS can lead to higher costs during “a massive surge in data flows”, and that’s true. It’s also true that NaaS can lead to lower costs when data flows are limited. Enterprises looking at NaaS to save money should (and do, according to those I’ve talked with) expect to see more of the latter than the former, or they have no reason being NaaS prospects to start with.
What about the contention that startups and cloud-native enterprises are most likely to be early NaaS adopters? The big problem here (as you likely guessed) is that we have our vaguely defined NaaS term coupled with an at-least-as-vaguely-defined cloud-native term. What are the probabilities that two UFOs will collide? How would you know without knowing the probability of even one UFO existing? But let’s press on to look at the technical side.
Realistically, cloud-native applications are ones that exploit the cloud’s unique benefits, which are things like scalability, agility, and resilience. It’s hard to see how you could use cloud features to maximize those benefits without ending up with cloud services that are themselves usage priced. Would a “cloud-native” enterprise who accepted usage-priced cloud services then reject NaaS because it was usage-priced? I don’t think so. I also wonder whether the workflows associated with a cloud-native application would even benefit from a traditional usage-priced NaaS model, since each component of the application would likely have a fairly static traffic flow; it would be the number of components that would generate more traffic.
How about the notion that startups would be more likely to adopt NaaS? I think you have to assume that the startups in question are OTT startups, since it’s hard to imagine a startup business in a traditional retail or manufacturing sector being much more than a single site, and thus not much of a consumer of any network service other than the Internet. OTT startups could be NaaS consumers to avoid having to capitalize network equipment, but OTT services are delivered over the Internet and so it’s far from clear why an OTT would need any “service” other than the Internet, in NaaS or in any other form.
What is the big barrier to NaaS? I think it goes back to the definition, and if we translate that into technical terms it means that NaaS needs some specific baseline feature set. Enterprises can buy VPN services not just because they know what they cost, but also because they know what they are. What is NaaS?
Realistically, NaaS is achieved by using the Internet as the transport network. NaaS is SD-WAN, in other words, at the core technology level. Given that, there’s no reason to think that usage costs would be a barrier to adoption, since the Internet isn’t priced that way. That leaves two questions. First, should we interpret the so-called price resistance to NaaS as a rejection of paying for anything other than Internet connectivity? I think that’s a “Yes!” Second, what NaaS features could then be added to an Internet-based NaaS to create a truly compelling service? That’s a question I think we need to work on answering, and I’ll look at it down the line.