Welcome!

@DevOpsSummit Authors: Elizabeth White, Liz McMillan, Kevin Jackson, Pat Romanski, Tim Hinds

Related Topics: @DevOpsSummit, Java IoT, Linux Containers, Containers Expo Blog, SDN Journal

@DevOpsSummit: Blog Post

Network Service Provisioning Speed | @DevOpsSummit [#DevOps]

Inarguably, the pressure is on the network to get in gear, so to speak, and address how fast its services can be up and running

Irrelevance of Hardware to Network Service Provisioning Speed
September 10, 2014

Inarguably, the pressure is on "the network" to get in gear, so to speak, and address how fast its services can be up and running. Software-defined architectures like cloud and SDN have arisen in response to this pressure, attempting to provide the means by which critical network services can be provisioned in hours instead of days.

Much of the blame for the time it takes to provision network services winds up landed squarely on the fact that much of the network is comprised of hardware. Not just any hardware, mind you, but special hardware. Such devices take time to procure, time to unbox, time to rack and time to cable. It's a manually intensive process that, when not anticipated, can take weeks to acquire and get into place.

Register For DevOps Summit "FREE" (before Friday) ▸ Here

Enter virtualization, cloud, containers and any other solution that holds, at its core, abstraction as a key characteristic. Abstraction all but eliminates the time it takes to procure hardware by enabling software to be deployed on any hardware, making the procurement process as simple as finding an empty server in the data center. After all, the majority of networking functions are just very specialized software running on very specific hardware.  Decouple the two and voila! Virtualized, containerized or cloud(erized) networking. Instantaneous! No more waiting for the network. Just push a button and you're done.

Only you aren't.

See, that's not counting the time it takes to actually provision and configure the desired services.

Most of the lamentable time it takes to provision network services has absolutely nothing to do with the underlying hardware. Whether it's commoditized off the shelf hardware or custom designed silicon makes no difference whatsoever in the actual time required to provision network services.  Both proprietary and commoditized hardware support a layer of abstraction - of virtualization - that enables them to be sliced and diced into discrete, consumable chunks of computing power. Within that "container" are the actual network services that need to be deployed to provide the breadth of network services required to keep today's applications scalable, secure and fast enough to satisfy both consumers and business constituents alike.

hardware versus hardware

To point to "hardware" as the primary impediment in rapidly provisioning these services is ludicrous. The hardware has nothing to do with the configuration of the minute and complex details associated with any given network service today. The slowdown is in the configuration of the services and the complexity of the topologies into which such services must be deployed.

This is the nature of application-focused networking. Each service - in addition to the nuts and bolts of IP addresses and VLANs and DNS entries - requires specific settings to ensure the network is able to provide the services upon which business rely to deliver applications. An optimized TCP stack for one application can mean disastrous performance for another. The specific application security details that protect one application may result in gaping holes in yet another application and completely break the functionality of another. The route one application takes through the network may provide excellent performance for one application but introduce unacceptable latency for another.

It is this reality with which network service configuration is concerned and why services absolutely must be application-driven with respect to their particular configuration. One size does not fit all when it comes to applications.

And thus it is these configurations - not the underlying hardware model - that impede service provisioning in the network and slow down application deployments. Manually flipping a bit here and a byte there and writing rules that deny access to that device but allow it from another are time consuming, error prone and terribly inefficient.

Virtualization of network functions a la NFV is only a panacea when one is deploying services that can be configured exactly the same, every time. That happens to be a model which works for service providers, who are concerned with scaling out specific functions in the network and not necessarily supporting new application deployments. In the enterprise, where the focus is on delivering individual applications with their own unique performance, security and reliability profiles, virtualization is nothing more than a means of squeezing out a greater economy of scale across existing hardware resources - whether commoditized or not.

Enterprises whose continued success relies on the fickle and highly volatile demands of consumer-facing applications are not so fortunate. Each network service must not only support the basic needs of an application but provide value in terms of improving performance, ensuring security or maintaining availability. To do that, each service must be tailored to the application - and sometimes to each client device - in question.

That takes time, and whether that service is deployed on a piece of commodity or custom hardware is irrelevant. The configuration is accomplished in software, which is the same whether running in a container, a virtual machine, or in plain old software daemon form.

That's why operationalization of the network is so critical to improving the alacrity with which application deployments are concluded. Going "virtual" isn't going to change the requirement for provisioning and configuration of the services, it only addresses the underlying process of acquiring and provisioning the appropriate resources.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

@DevOpsSummit Stories
"Storpool does only block-level storage so we do one thing extremely well. The growth in data is what drives the move to software-defined technologies in general and software-defined storage," explained Boyan Ivanov, CEO and co-founder at StorPool, in this SYS-CON.tv interview at 16th Cloud Expo, held June 9-11, 2015, at the Javits Center in New York City.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the public cloud best suits your organization, and what the future holds for operations and infrastructure engineers in a post-container world. Is a serverless world inevitable?
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
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.