The Philosophy of Network-as-a-Service
The Philosophy of Network-as-a-Service
Join the DZone community and get the full member experience.Join For Free
Originally written by Marten Terpstra at the Plexxi blog.
In the world of Anything-as-a-Service (I will leave the acronym to your imagination), Network-as-a-Service is not a new term. In fact, it even has its own wikipedia page which will tell you it has been used for many years now, well before the current set of service related terms in IT have become popular.
Like most high tech industries, we get somewhat carried away when we have some new terminology and quickly overuse and overload them, watering them down to be meaningless or at least highly confusing. But when you cut through the clutter a bit, the as-a-Service terminology most certainly articulates a shift in thought process and behaviors on how we provide and consume IT resources.
The IT organization has always been a service organization, there is nothing much new there. From the days of mainframes and supercomputers, their job was to provide access to these expensive resources and maintain them. They provided environments that allowed the users to conveniently consume these abilities, and the business applications that ran on top of them, whether those were financial systems, email, uucp news (remember those days) or the basic ability to run user created jobs.
With the distribution of compute and storage resources that started in the mid to late 90s, the focus of the IT organization moved towards providing a homogenous compute environment. Networking became a more fundamental piece of the required resources, it was no longer just a mechanism to access these centralized resources. But while the environment changed, the services provided by the IT organization still very much stayed the same.
There are many opinions when and where the responsibilities of IT shifted significantly to what we now label “as-a-Service”. Outside of the continuous cycle of distribution vs centralization, there are trigger points in the datacenter where there was a significant change in what and how IT resources were provided. The desire (or need) of users to run their own applications on the resources provided in the datacenter. The introduction of server virtualization as a mechanism to more conveniently provide server resources as a service. I also believe that the start of the Bring Your Own Device movement forced a change of operations, a change in thinking and providing service throughout IT.
Ultimately, as-a-Service exposes what we have typically considered to be infrastructure components to the end user. We have always consumed these same resources, whether internal to IT or as a customer of that IT team. We have however moved from implicit consumption to explicit consumption. Most enterprises struggled with BYOD not because it was hard to allow users to attach to the network with their own device, but because it was hard to manage authentication and security aspects of that service. There was no explicit device authentication service. User authentication was tied to desktop infrastructures. File and document security and management was built on top of these closely managed infrastructures.
Similarly in the datacenter, providing users with their own servers is not particularly hard. But managing their shared storage, network access, user security and all other parts you require to have a proper service, is. Enter OpenStack and VMWare. They have made it convenient to manage the ability to provide users with their own server infrastructure. The fact that it happens to be virtualized is a way to optimize the available physical resources, not fundamental to the service provided. The end user consumes a server. With all the bit and pieces that come along with it. The IT team no longer manages the server and everything that runs on top of it, it has created an ability to offer the server, but in a way that allows them to properly manage, secure and control this service. Others have created higher levels of abstraction on top of these servers, providing it as a Platform-as-a-Service.
The network has not quite gotten to that same level of consumption. It is still seen as a piece of infrastructure required to glue the consumable portions of infrastructure together. The administrator of the server infrastructure still articulates network connectivity as part of the server service. All of the components exist in the network, but we have not turned it into a user consumable service. The ability to create consumer defined routed environments in some of the public cloud offerings are probably a good first instantiation of the network being consumed and defined as a service. In a typical enterprise datacenter, the network is not so easily parceled out to the users that have been provided other resources as a service.
As vendors we have always been quick to point to the plethora or features and functions that allow you to offer the network as a service. Carriers and Metro Ethernet providers have successfully created network services based on our platforms. But they have spent a tremendous amount of time and energy creating this service themselves, using the basic building blocks of protocols and connectivity we have provided. That model does not work for any enterprise where the network itself is not the primary service provided.
In the past we have talked about making the network more easily consumable. Not by network engineers, but by end users. That is fundamental to the ability to truly create a Network-as-a-Service offering. As a network architect or engineer I need to be able to allow the user to create their own network infrastructure in a manageable way. Many of the components exist in the network devices, and in the server platforms themselves. But they do not exist in a way that I can offer the network as a configurable service to the end user. Allow them to chose what connectivity they require, what QoS they need, what basic access restrictions are required. And beyond that, what type of load balancing service needs to be attached, is a firewall needed and for what types of traffic. Does the traffic need to be encrypted on the network, do I need accounting records back. You name it. Many of these features exist, but not in a way they can be gathered and consumed into a service by an end user that is not the network engineer or architect.
That is what Network-as-a-Service needs to be. It’s a philosophy that creates a different way of building networks, configuring networks, provisioning networks and managing networks. It’s a philosophy that allows the network to become a consumable resource, not just a fundamental piece of infrastructure required to glue things together.
Published at DZone with permission of Mike Bushong , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.