Welcome!

@DevOpsSummit Authors: Pat Romanski, Liz McMillan, Elizabeth White, Yeshim Deniz, SmartBear Blog

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
"Our strategy is to focus on the hyperscale providers - AWS, Azure, and Google. Over the last year we saw that a lot of developers need to learn how to do their job in the cloud and we see this DevOps movement that we are catering to with our content," stated Alessandro Fasan, Head of Global Sales at Cloud Academy, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
Five years ago development was seen as a dead-end career, now it’s anything but – with an explosion in mobile and IoT initiatives increasing the demand for skilled engineers. But apart from having a ready supply of great coders, what constitutes true ‘DevOps Royalty’? It’ll be the ability to craft resilient architectures, supportability, security everywhere across the software lifecycle. In his keynote at @DevOpsSummit at 20th Cloud Expo, Jeffrey Scheaffer, GM and SVP, Continuous Delivery Business Unit at CA Technologies, will share his vision about the true ‘DevOps Royalty’ and how it will take a new breed of digital cloud craftsman, architecting new platforms with a new set of tools to achieve it. He will also present a number of important insights and findings from a recent cloud and DevOps study – outlining the synergies high performance teams are exploiting to gain significant busin...
Enterprise architects are increasingly adopting multi-cloud strategies as they seek to utilize existing data center assets, leverage the advantages of cloud computing and avoid cloud vendor lock-in. This requires a globally aware traffic management strategy that can monitor infrastructure health across data centers and end-user experience globally, while responding to control changes and system specification at the speed of today’s DevOps teams. In his session at 20th Cloud Expo, Josh Gray, Chief Architect at Cedexis, covered strategies for orchestrating global traffic achieving the highest-quality end-user experience while spanning multiple clouds and data centers and reacting at the velocity of modern development teams.
In IT, we sometimes coin terms for things before we know exactly what they are and how they’ll be used. The resulting terms may capture a common set of aspirations and goals – as “cloud” did broadly for on-demand, self-service, and flexible computing. But such a term can also lump together diverse and even competing practices, technologies, and priorities to the point where important distinctions are glossed over and lost.
When shopping for a new data processing platform for IoT solutions, many development teams want to be able to test-drive options before making a choice. Yet when evaluating an IoT solution, it’s simply not feasible to do so at scale with physical devices. Building a sensor simulator is the next best choice; however, generating a realistic simulation at very high TPS with ease of configurability is a formidable challenge. When dealing with multiple application or transport protocols, you would be looking at some significant engineering investment. On-demand, serverless computing enables developers to try out a fleet of devices on IoT gateways with ease. With a sensor simulator built on top of AWS Lambda, it’s possible to elastically generate device sensors that report their state to the cloud.