@DevOpsSummit Authors: Liz McMillan, Pat Romanski, Elizabeth White, Yeshim Deniz, Mehdi Daoudi

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.

@DevOpsSummit Stories
Daniel Jones is CTO of EngineerBetter, helping enterprises deliver value faster. Previously he was an IT consultant, indie video games developer, head of web development in the finance sector, and an award-winning martial artist. Continuous Delivery makes it possible to exploit findings of cognitive psychology and neuroscience to increase the productivity and happiness of our teams.
As DevOps methodologies expand their reach across the enterprise, organizations face the daunting challenge of adapting related cloud strategies to ensure optimal alignment, from managing complexity to ensuring proper governance. How can culture, automation, legacy apps and even budget be reexamined to enable this ongoing shift within the modern software factory? In her Day 2 Keynote at @DevOpsSummit at 21st Cloud Expo, Aruna Ravichandran, VP, DevOps Solutions Marketing, CA Technologies, was joined by a panel of industry experts and real-world practitioners who shared their insight into an emerging set of best practices that lie at the heart of today's digital transformation.
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addresses many of the challenges faced by developers and operators as monolithic applications transition towards a distributed microservice architecture. A tracing tool like Jaeger analyzes what's happening as a transaction moves through a distributed system. Monitoring software like Prometheus captures time-series events for real-time alerting and other uses. Grafeas and Kritis provide security polic...
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throughout enterprises of all sizes.
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading these essential tips, please take a moment and watch this brief video from Sandy Carter.