Continuous Delivery: Coming To Your Infrastructure

Continuous delivery. CD. It's a term thrown around by dev and ops (and subsequently, DevOps) but until recently, network folk had no reason to consider it -- other than it enabled deployments to be hurled over the production wall faster and more frequently.

But new research indicates that CD is likely (probably, almost certainly) coming to infrastructure near you. A survey from Dzone on continuous delivery indicates that only 21% of professionals have no desire to expand CD to infrastructure. That's close to the 22% who have already implemented CD for their infrastructure, and both are overshadowed by the 57% who want to implement, but have not yet done so.

It's coming, so the first question to answer should probably be, "What is it?"

As with any technology, trend or methodology, there is some variety in definition. In general, continuous delivery is the practice of building software such that it could be deployed into production at any time without disruption. The astute networker just snorted and thought, "what about all the moving parts in the network infrastructure that aren't ready that, when combined with the software, might cause a disruption?"

Which kind of answers the question about why CD is pushing beyond dev, into ops and, sooner or later, into the network. Because some of the network stuff that needs to get done during a push into production is directly related to the application and its operational and business requirements. Changes must be made. Configurations might be updated; services may need to be inserted. Things have to happen in the network to deploy an app.

The issue is that too often those "things" take far too long. Two of the top IT pain points of 2014, according to an EMA research report, were slow provisioning of new applications (31%) and slow manual processes to reconfigure infrastructure to accommodate change (39%). These are serious impediments not just to the software-defined data center, but to the ability of the business to survive in an application world.

Operationalization of the network specifically targets these pain points, introducing programmability that enables infrastructure as code and automation as a viable means to speeding up the "things" that must happen in the network to deploy an app or new version of the app.

This is why it continues to be important for all networking professionals to get more familiar with the programmatic methods already in the network as well as continue to explore frameworks and platforms designed to assist in automating what can (and probably should) be automated. But even before that automation happens, before a line of code (script) is written, it's important to identify what needs to be automated.

And that answer can be found in identifying what "things" have to happen in the network when a new app or app update is "pushed" towards production. There's a critical path of infrastructure and application services in the network that need to be validated and, if necessary, updated based on a "push" from development. It's those services that should be evaluated for automation before anything else, because those services are the ones that will have an impact -- for good or ill -- on the next app push from development.

But have no doubts: CD is coming to infrastructure near you. It will run into the network and become your concern, because the path to production must pass through you.

These are some of the topics we'll be covering in our upcoming Interop Las Vegas workshop, Achieving Operational Excellent Through DevOps, as we offer guidance on how to get started operationalizing application deployments.

Fashion retailer Nordstrom will also tell how its IT organization learned to implement continuous delivery in the session DevOps, Mobile Apps & Nordstrom's IT Transformation. Don't delay -- register now for Interop, flooring April 27 to May 1, and receive $200 off.