Welcome!

@DevOpsSummit Authors: Liz McMillan, Elizabeth White, Pat Romanski, Yeshim Deniz, Flint Brenton

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

@DevOpsSummit: Blog Feed Post

The Inevitability of Idle Resources

Scalability's dirty little secret: if your architecture is designed to support elasticity, you must have idle resources

Proponents of pure software infrastructures often point to rapid provisioning (like right now, push a button and blam! Instant scale) as one of the reasons to "go software." Superficially this is true. If your infrastructure is all software (or virtual, if you prefer) then when you need more X you can simply grab some available resources and provision more X. No procurement process, no PO, no approvals, no waiting.

But did you notice what's ultimately required for this to happen? Available resources.

The dirty little secret of on-demand scalability is that no matter what, you need available resources. You need a pool of available (idle) resources from which to draw in order to provision, well, anything. Whether you need to scale server, storage, or  network services, those services have to be provisioned on some kind of hardware.

Let's pause for a moment while I say that again: All software requires some kind of hardware on which to execute. For some reason this basic truth seems to get trampled under the rainbow hooves of the software-only unicorns that start dancing every time someone says SDN or NFV. I emphasize this because it's important. Software can't run without resources, and resources come from hardware.

Available resources ultimately means idle resources. Unless you were planning on freeing up resources on-demand by decommissioning some other service. I'm sure the consumers of that other service would have something to say about that (and what they might say probably can't be repeated in polite company).

Which ultimately means that if you think you might need to scale X, you'd best have a pool of available (idle) resources appropriately allocated for the service at the ready (We'll explore that further at a later date). Whether that comes from appropriately sized general purpose virtual machines or appropriately sized purpose built virtual instances isn't the point today. Suffice to say that you need the resources when you need them and that is the point - they need to be available, which means sitting idle when you don't need them.

idle-is-still-idle

Idle is idle, regardless of its source. And there must be idle resources available somewhere if you're going to successfully execute on a capacity-on-demand plan. The only question is whether those resources are appropriate to the task you'll put them to or not.

The moral of the story is that there is no technology or architecture today that eliminates the "waste" of idle resources without sacrificing some other data center requirement.

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
Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-Ops have limited insight and answers to who, what, when, why and how across the DevOps lifecycle. This impacts the ability to deliver high quality software at the needed velocity to drive positive business outcomes. In his general session at @DevOpsSummit at 19th Cloud Expo, Eric Robertson, General Manager at CollabNet, will discuss how customers are able to achieve a level of transparency that enables everyone from Planning-to-Ops to make informed decisions based on business priority and leverage automation to accelerate identifying issues and fast fix to drive continuous feedback and KPI insight.
It is ironic, but perhaps not unexpected, that many organizations who want the benefits of using an Agile approach to deliver software use a waterfall approach to adopting Agile practices: they form plans, they set milestones, and they measure progress by how many teams they have engaged. Old habits die hard, but like most waterfall software projects, most waterfall-style Agile adoption efforts fail to produce the results desired. The problem is that to get the results they want, they have to change their culture and cultures are very hard to change. To paraphrase Peter Drucker, "culture eats Agile for breakfast." Successful approaches are opportunistic and leverage the power of self-organization to achieve lasting change.
For far too long technology teams have lived in siloes. Not only physical siloes, but cultural siloes pushed by competing objectives. This includes informational siloes where business users require one set of data and tech teams require different data. DevOps intends to bridge these gaps to make tech driven operations more aligned and efficient.
"Venafi has a platform that allows you to manage, centralize and automate the complete life cycle of keys and certificates within the organization," explained Gina Osmond, Sr. Field Marketing Manager at Venafi, in this SYS-CON.tv interview at DevOps at 19th Cloud Expo, held November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA.
DXWorldEXPO LLC announced today that the upcoming DXWorldEXPO | CloudEXPO New York event will feature 10 companies from Poland to participate at the "Poland Digital Transformation Pavilion" on November 12-13, 2018.