I joined PacketFabric because it is one of the founding companies behind the NaaS (Network-as-a-Service) concept.
For years, I had been all over SDN (Software Defined Networking); controllers, moving the industry via major vendors portfolios. Yet, things just weren’t going fast enough. I wanted a chance to explain why I joined Anna, Jezzibell, Chad and the team and what I see in the future for NaaS, which is an evolution of the Internet Architecture; in particular from the technical side. Towards that end, a first blog defining what is and what’s different about NaaS may bring some clarity to a seemingly crowded and semantically overloaded term.
With increasing frequency, the analysts that traditional Enterprises have relied upon to provide guidance on technology trends have been focusing on NaaS. Sure, we’ve followed the SDN cycle through their analytical lens and NaaS IS SDN for the wide area network, DCI or middle-mile-to-services that a real-time network requires and that now has their eye because it’s very timely.
Over the last year, PacketFabric has made great strides in moving from its early startup stage by really ramping (portfolio, business and operations) and attracting recognition in recent analysis by Gartner, Futuriom and (most recently) GigaOm. These are all excellent reads, but the perspective of each individual analysis understandably leads to the inclusion of companies profiled with capabilities that are sometimes broader than what I would personally define as NaaS and other times just adjacent to NaaS. The lumping together of overlay tunnel companies, SD-WAN companies, security companies, and more I’ll discuss later, is confusing on both a technical and business level. Sometimes “lumping” things together is easy but, it’s time to sort and match up the socks. It’s time to define NaaS and create a new market category.
How NaaS Started – Way back machine
NaaS is different from other software-defined technologies because it starts with a fundamental architectural shift rooted in how automation and orchestration technology stacks are built. All from-the-ground-up reinvention, no patchwork quilt, natively utilizing dynamic private cloud and public cloud environments. Utilizing any protocol and automation language to “talk” to the boxes, NaaS creates a full on (per the trade marketing arm) “Network Operating System” to power a nextgen Service Provider. In combination with traditional colocation assets, Private Network Interconnect and IXs create a secure, private internet. NaaS is really trying to solve fundamental problems in how networks were managed and presented to customers as a private internet. Summarized in our own “NaaS Operator’s Guide”:
“The legacy model of WAN requires building a private data network or purchasing access from a service provider with a series of complex manual steps through both the business process as well as the technology infrastructure process. This is no longer compatible with today’s modern applications, which require a streamlined and automated process driven by digital technology rather than “pieces of paper and plugs.”
Working with operators and network owners for decades; just about every aspect of the legacy WAN and DCI service model was static and frankly unable to evolve out of its own way. The well was dry on that operational architecture. It was designed around static resource allocation with a slow rate of change (bandwidth, technology, peers/partners). It was hampered by complexity, lock-in, bureaucracy and gatekeeping. What am I talking about?
- Gatekeeping, a common internal infrastructure problem of traditional carrier systems, manifested through inability to easily discover what services were available and where.
- Bureaucracy manifested through complex contracts and protracted wait times for service fulfillment. Seen by the customer as complex MSAs, incomprehensible billing systems that we designed for connectivity of by-gone eras.
- Complexity was everywhere from the acquisition of a basic circuit, through protocol knowledge and vendor equipment configuration expertise that made a WAN hard to expand or reconfigure. And, if you needed an extra-net connection to another business, you introduced a new level of cost and pain.
- Lock-in is pretty common in the industry. It’s the creation of a contract that is so long and so costly (fees) or painful to terminate that a customer will suffer with a poor service. It’s also the business catalyst for stagnation and simply is an economic barrier to moving towards programmatic, real-time, on-demand solutions. It’s the polar opposite of those concepts.
Most importantly, whether your IT team was in DoItYourself or Managed Service modes of WAN operation, adjacent network service consumption was often a limited vertical stack rooted at the connectivity layer. Higher level network services (security, voice and video) and data services (compute, storage and processing) were often bound to a reseller agreement between your “carrier” and a specific and limited set of vendors. More lock-in or worse vertically integrated stacks of second- or third-rate services bundled into an offer. It’s not a marketplace if there are no choices and no flexibility. The new goal: best-of-breed for IT and productivity and that means diversity and change.
The journey at PacketFabric into unleashing the power of a network began a couple years ago, serving companies that strained under the legacy model (like those you might find in media creation, genomic research, storage/archive, DC connectivity) and needed dynamic network resource allocation and pricing models that matched their workflows.
An often overlooked, but important component of those formative years involved proving our operational reliability and transparency as a better, faster, and automated substitute for legacy vendors. The company was founded out of a technical necessity and thus, the platform, infrastructure, APIs, billing are all incredibly solid. The really good news is that the founders didn’t get caught in the trap of the SDN hype and controller and protocol wars. As the industry now has caught up; those are dead end conversations. Instead the team, which came out of the “netdev” community was focused on scale-out, cloud native approach from the start and was chock full of netops gurus that didn’t need to analyze the fundamental requirements; they created the company because they were stymied as operators themselves and could find a solution that worked. They formed PacketFabric to build it themselves.
How NaaS Exploded (in a positive way)
Ok, back to NaaS. The larger and more recent part of the NaaS story is how cloud computing has stomped on the NaaS gas pedal. Cloud consumption altered the concepts of Enterprise resource placement, workflows and the core thinking about the purpose and design of Enterprise networks. Cloud computing and IaaS/PaaS broke the legacy WAN model and created a new “cloud first” Enterprise architecture.
Additionally, “Software is eating the world” and Enterprises are now gobbling up software (SaaS) from and creating software on multiple clouds. Even the smallest Enterprises are now positioning their own line of business applications on multiple Cloud Service Provider (CSP) infrastructures, as part of what analysts deem “digital transformation.”
Third, Hybrid-multi-cloud (aka the use of multiple DCO’s facilities in addition to any on prem and public cloud) usage added some architectural complexity for Enterprise IT that necessitates a physical and logical “brokerage” to enable economically sensitive consumption from multiple clouds without encumbering newfound “agility” and while staying in alignment with goals to contain (or reduce) IT operational costs. Phew, long sentence but the point is this: enterprises simply have to work in a multi-DCO, multi-cloud world due to cost, geo-location, connectivity or access to services. Full stop. There may be a clear notion of Kansas for Dorothy but, there isn’t just one cloud or cloud architecture for an enterprise vision.
Over here, PacketFabric was born because SaaS, SASE, Cloud Storage, Cloud Compute, and Cloud SD-WAN all suffer from the same middle-mile and long-haul problem: connectivity to, and between these services without programmable flexibility, accurate and precise telemetry and guaranteed bandwidth, latency and jitter. This is where NaaS comes into its own.
Happily, NaaS has embraced the newfound agility of cloud consumption built on API enabled automation. This makes a stable, published API the new “standard” for modern networking architecture, and makes complex networks just as user friendly as any cloud or SaaS product. API based network architecture makes the SDN dream of a programmable, secure, private Internet Fabric a reality – a reality far beyond the legacy virtual private networks (VPNs) and Internet services of the past. Perhaps most importantly, it means to program or diagnose a network; the APIs can be integrated into workflows, IT processes and admin tasks and no humans have to be involved. Perhaps a cheesy cliche but, our simplest pitch is really “if the intellectual property of your company isn’t owning, managing and operating a network, why not let us do that for you and you can focus on running your business. You’ll have full control and greater flexibility than you ever had.”
So, What IS NaaS?
First there was a swirling cloud of gas and a big bang. No, I’m kidding. Really. For networking folks there’s a clear connect-the-dots of design patterns that led to the concept. NaaS emerges from three roots – the movement to simplify Enterprise WAN operations, the subsequent move to cloud (both hybrid and multi-cloud) and SDN (Software Defined Networking).
As I mentioned earlier, Network-as-a-Service is the final phase of productivity of the storied technology hype cycle for SDN. NaaS is the technical and business realization of SDN applied to the physical transport and logical connectivity of the Enterprise network to cloud(s) and DCOs. SDN has marched through hype (the Peak of Inflated Expectation), the trough (of Disillusionment) and is now mainstream (on the Plateau of Productivity). Although WAN and cloud connectivity was never a hot conversation in the early battles of protocols, controllers and the foundation of many standards and open-source communities; it’s now the ultimate value coming out of that Brownian motion.
Figure 1 Gartner Hype Cycle (By Jeremy Kemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)
To make it clearer, NaaS is the realization of SDN applied to “the part in the middle” of the network, of the new cloud-centric Enterprise architecture. Many analysts will refer to this as the “middle mile” – a private network that bypasses often less-optimal internet routing and congestion for critical Enterprise resource and service access. We serve middle-mile and WAN networking. We are the first to bring SDN, and all its programmable networking and API glory, to WAN services, transport, hybrid cloud, multi-cloud, Private Network Interconnect, and Internet Exchanges. It’s really quite a big deal.
NaaS is the transport not only between dynamic collaborators outside of the cloud (an update to the classic Enterprise WAN), but also between enterprise resources in private, often multi-tenant Data Center facilities (MTDCs) and in the public Cloud Service Providers (CSPs), including the interconnect between them all in a growing “cloud first” Enterprise architecture. Fundamentally, it’s the concept of an on-demand fabric between needed services for an enterprise vs a collection of static links.
Within that “cloud first” architecture, Enterprises are interacting with multiple Solution Delivery Partners who are delivering “Productivity as a Service” (ITaaS), which is where our shared journey is headed.
I was in all industry conversations, forums, protocol standards bodies, conferences and foundations where NaaS was just stated as “too hard” or full of mucky routing protocols. I absolutely love the intersection of dynamic routing, bandwidth optimization, latency and jitter engineering and scale out orchestration with logic engines (sorry, the industry term is AIOps). There were nonsensical arguments that a network only needed a controller, or that only fully distributed, autonomous networking architectures were pure. All just wasting time and oxygen in the conversation. The industry then turned to telemetry and mucked that up as free-for-all data explosion with no contextualized information of value. Thankfully, we can work with multiple vendors, multiple data formats, multiple protocols and have more accurate and precise data and analytics feeding remediation engines than any of the vendors themselves. It is hard to get this all right and build a solid, reliable, SLA guaranteed network that’s fully programmable; and thankfully we worked through the peak and trough of what SDN was, and came out with the design patterns to build a next-generation Service Provider that’s fully programmable and automated.
Why NaaS NOW?
First, let’s set the table of how we got to NaaS-Now. By 2019, a great majority of Enterprise organizations had plans for their “digitization” journey, driven by an overwhelming move toward cloud consumption and the increasing deployment of mobile endpoints. The simple fact that nothing was delivered, serviced or administered on-prem. The “final resting place” of any good five-year plan placed them on course to have finished what was supposed to be a gradual and orderly transition to a hybrid-cloud architecture (supporting fleets of potentially untethered clients) in 2024 or 2025. Because of this, NaaS was already a tracked growth industry abutting the tremendous growth in MTDC and CSPs. NaaS was an established technology trend with established players and plenty of “upside.” Additionally, cloud providers needed a way to connect their customers and to get access to new revenue streams and everyone was (per norm) on a cost cutting mission.
The coronavirus pandemic of 2020 simply turned the clock forward.
Necessity accelerated the move of enterprise resources to more accessible public or public-adjacent private cloud and immediately substituted “remote worker” for “mobile user” in massive numbers. The old campus architecture just doesn’t exist anymore. Remote working that assumes the campus is the center of the enterprise is now incredibly confounding and creates a terrible employee (aka user) experience. This notion that all users are on a campus and all traffic for an enterprise goes in and out of that campus is not just debunked, it’s positively antiquated.
Many of these changes will be a permanent step forward into a new Enterprise architecture – that will “stick” as the new method of operation. In discussions with major Enterprises, many are now where they expected to be on their journey – three or four years from now. Straight up foot to the floor transitioning to a fully multi-service-cloud, SaaS-based enterprise.
The pandemic atomized enterprise architectures centered/focused on the campus. No one goes to the campus now and trying to build a moat for security there is foolhardy. The new campus is the remote workforce. When that notion that “all employees are on a campus” moved to “all traffic is backhauled to campus” added so much latency vs going direct to cloud; it was all hands on deck to have a network architecture that matches the communication flows. An enterprise in one sense is defined by its communication topology which now is radically changed from campus-core to a cloud multiverse.
For all remote workers, the new Enterprise communication and services architecture became realized as a VPN or SD-WAN termination in one cloud, SASE services in another, storage in another, different collaboration clouds and applications that are dispersed across multiple public clouds. The new highly distributed enterprise campus is what requires and necessitates a FABRIC to provide a mesh of connectivity, not a collection of point-to-point connections going in and out of a single central hub.
Elements of the Enterprise backbone, ZTN/SASE Cloud, Managed SD-WAN and access from there to Cloud Service providers traverse a ngSP (next gen Service Provider) fabric for privacy, availability and agility. NaaS and fabric architectures are now relevant to everyone – Enterprise customers, the entire “new” DC ecosystem and the adjacencies and compliments in the network services layers. There will be no gradual retooling of the legacy telecom model – it is fundamentally broken in the post-pandemic world. Static VPNs, multiple enterprise service networks, overlays and adding DIA and express routes to VPNs and WANs stopgaps like band-aids on arterial bleeding.
For the modern age, the famous bumper-sticker marketing is that it’s all about where you are going with your business. Where “going” is not only new growth and cost savings, but also a new foundation for the business that matches the topology of how a company communicates and the services they use to make their business go.
Therefore, what’s needed to get an enterprise going is an automated, on-demand fabric that gets you everywhere with the bandwidth that you can control, and you only have to pay for what you use. It’s NOT about bandaging outdated architectures, static VPNs or dependency on dinosaurs. “If the intellectual property of your company isn’t owning, managing and operating a network; let PacketFabric do it for you. We’ve made the Internet secure, private, fully connected, on-demand and with guaranteed bandwidth, latency and jitter. We aren’t “next-generation”; we are the future of enterprise Internet.” That’s a serious target.
NaaS Is A Change to The Internet Architecture
NaaS broke the old model of network consumption and is spawning a broad spectrum of re-imagined and new network service technologies – implemented as cloud or cloud-adjacent solutions.
But, because many of these service offers may incorporate NaaS or just don’t fit (yet) into a neat box or quadrant of their own, they tend to clutter the category and confuse the analyst definition of NaaS. For example:
- Cloud managed SD-WAN, where the move to broadband branch access and the remnants of the legacy Enterprise MPLS network meet the cloud cross-connect – can be offered by vendors resident in any of the data center properties comprising the new Enterprise architecture and leverage NaaS
- Similarly, ZTN (Zero Trust Networking) functionality where the work-from-home broadband consumer network meets the public (CSP) and private (MTDC) is a cloud-to-cloud service, that is tossed by analysts into the category
- And SASE, the cloud-based security service encompassing firewall, IOT, and network security among others in front of the CSP and MTDC lives here as well
- Cloud overlay on-ramp technologies which use tunnels over the swamp of the consumer Internet get inappropriately put in the category
The reality that some of the Data Center infrastructure providers also offer proprietary connectivity to their real estate may further complicate the picture for analysts and consumers alike.
For a number of higher-level technical reasons and lower-level business reasons; the CAPEX focus, OPEX expertise focus, even corporate structure (e.g., REIT income limitations) – there will be some persistent, confusing but often complimentary overlaps between service vendors in the new Enterprise architecture. I can live with some confusion but not technical confusion – a platform driven network with SLAs with a cloud consumption model is what I’m calling NaaS. Just like you can on-demand get compute, RAM and Storage infrastructure from a cloud provider; you can get on-demand network infrastructure, services and connectivity from a NaaS provider like PacketFabric.
At PacketFabric, NaaS is our focus and core competency. The beauty of the API-based nature of our “pure play” NaaS model is that it supports the integration with solution delivery partners with appropriate core competencies in adjacent services for enterprises and specific verticals, allowing us to be the perfect complement to everyone in the ecosystem. It’s the realization of the idea that the network is code.
Dave Ward, CEO @ PacketFabric