SDN Journal Authors: Elizabeth White, Yeshim Deniz, Liz McMillan, Pat Romanski, TJ Randall

Related Topics: SDN Journal, Java IoT, Linux Containers, Containers Expo Blog, @CloudExpo, Cloud Security

SDN Journal: Blog Post

Network Services, Abstracted and Consumable

The network has traditionally been very static and simplistic in its offerings

Perhaps not as popular as its brothers and sisters I, P and S, Network-As-A-Service or NaaS has slowly started to appear in industry press, articles and presentations. While sometimes associated with a hypervisor based overlay solution, its definition is not very clear, which is not at all surprising. Our industry does not do too well in defining new terms. I ran across this presentation from Usenix 2012 that details a NaaS solution that adds a software forwarding engine to switches and routers that provide specific services for some well known cloud computing workloads.

I have some serious reservations about the specific implementation of the network services provided in this presentation, but the overall thoughts of specific network services delivered to applications and workloads resonates well with me. Unless this is your first visit to our blog, your reaction is probably “duh, this is what Affinity Networking is all about”. Of course it is.

The network has traditionally been very static and simplistic in its offerings. The vast majority of networks runs with an extremely small set of network services. Find me a network that uses more than some basic QoS based on queueing strategies, IP Multicast (and many understandingly avoid it as much as they can), and perhaps some VRFs and we will probably agree that that is an exception rather than a rule. And I deliberately exclude the actual underlying technologies to accomplish this, those don’t change the service, just enable it.

And it is not that networks are not capable of providing other services. Most hardware used is extremely capable of doing so much more, and in many cases even the configuration of that hardware is available. Extremely elaborate protocols exist to manage additional services, with new ones being developed constantly. And you can find paper after paper that show that specific network services can greatly improve the overall solution performance. Many of these examples are based on big data type solutions, but I am pretty sure that that translate into just about every solution that has a significant dependence on the network.

So why then do we not have a much richer set of network services available to the consumer of the networks?

There are probably multiple answers, but one that keeps bubbling to the top each time we look at this is one of abstraction. In simple terms, we have not made network services easy to create, easy to maintain, easy to debug, and most importantly, we have not made network services easy to consume. We talk about devops and the fact that the creation, debugging and maintenance of complex network services inside the core of a network is not at all trivial. Per the examples above, getting end to end QoS (consistent queuing really) in place seems like a simple task but is not. And that is technology that has been around for well over a decade. Configuring each and every switch to ensure it has the same queueing configuration and behaviors, adjust drop rates and queue lengths based on where a switch fits into the network and define what applications should fit into which queue is complex not because of the topic itself, but because of the amount of touch points, the amount of configuration steps, and the switch by switch, hop by hop mechanisms by which we deploy it. This is where devops will start.

But you also have to look at it from other side. In the first few slides of the above mentioned presentation, the presenter shows that the network engineer and the application engineer have wildly different views of the network. As they should. The application engineer should not need to know any of the ins and outs of the network and its behavior. He or she should be presented with an entity that provides connectivity, and a set of network services it offers. And it should be trivial to attach itself to any of these services without having to understand network terms. An application engineer should not need to know that DSCP bits need to be set to get a certain priority behavior. Or having to request from the network folks that a set of IP or ethernet endpoints require a lossless connectivity and must therefore be placed onto network paths that support PFC and QCN to enable RDMA over Ethernet or even FCoE.

These types of services need to become extremely easy to consume. The architect of a very large private cloud described his ideal model by which applications (and he supports thousands of them) would consume network services. He envisioned an application registration model (through a portal for instance) where application developers could express in extremely simple non network terms what their application needed. Connectivity between components X and Y. The use of specific memory systems that have been predefined to use RDMA over Ethernet (and thus require lossless connectivity). This application consists of N components that need PCI compliance and therefore need to be separated from the rest of the applications. You name it, application behavior in terms that are as far away from the actual implementation of the tools used to enable that service in the network.

There is lots of work to do on both ends of this consumable network service model. For the network engineer it needs to become much easy to enable these network services in a controllable and maintainable manner. Easy to design, easy to deploy, easy to debug and maintain. For the application engineer, it needs to become easy to consume these network services. Simple and scalable registration and request mechanisms without a lot of network terminology. My post office comparison from a few weeks ago was perhaps very simplistic, but you have to admit, using the USPS is pretty simple. You walk up to the counter, there is a menu of shipment options, each with a price and an expected result, you pick what you want, they charge you for it and off your package goes. And you don’t really worry or care too much how, just that it’s being delivered in accordance with the service you paid for….

[Today's fun fact: Stewardesses is the longest common word that is typed with only the left hand. As a result it has been banished in favor of flight attendant.]

The post Network Services, Abstracted and Consumable appeared first on Plexxi.

Read the original blog entry...

More Stories By Marten Terpstra

Marten Terpstra is a Product Management Director at Plexxi Inc. Marten has extensive knowledge of the architecture, design, deployment and management of enterprise and carrier networks.

CloudEXPO Stories
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next-gen applications and how to address the challenges of building applications that harness all data types and sources.
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments that frequently get lost in the hype. The panel will discuss their perspective on what they see as they key challenges and/or impediments to adoption, and how they see those issues could be resolved or mitigated.
CloudEXPO New York 2018, colocated with DevOpsSUMMIT and DXWorldEXPO New York 2018 will be held November 12-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI and Machine Learning to one location.
DXWorldEXPO LLC announced today that Nutanix has been named "Platinum Sponsor" of CloudEXPO | DevOpsSUMMIT | DXWorldEXPO New York, which will take place November 12-13, 2018 in New York City. Nutanix makes infrastructure invisible, elevating IT to focus on the applications and services that power their business. The Nutanix Enterprise Cloud Platform blends web-scale engineering and consumer-grade design to natively converge server, storage, virtualization and networking into a resilient, software-defined solution with rich machine intelligence.
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.