DevOps Doesn’t End with Delivery

It doesn’t matter how fast you can deliver if deployment delays release. While NetOps are warming up to automation and orchestration, there are significant challenges facing their efforts to speed up deployment. DevOps is in the best position to help them do that.

DIGITAL TRANSFORMATION MEANS DEVOPS

There is inarguably a link between digital transformation and DevOps. Because of DX, 48% of organizations are moving to deliver apps to production more frequently. 62% are automating and orhestrating IT systems and processes. 52% are changing how they develop apps (think Agile). And 42% are exploring containers and microservices. From the very building blocks of applications all the way to the methods in place to move them to market, digital transformation means DevOps has a way to extend "continuous delivery" to "continuous deployment." Remember, "delivery" doesn't mean to market, it means to production—where the deployment process kicks in and gets the application into a state acceptable for consumption.

That's because "acceptable for consumption" does not just mean "the app is working okay." It encompasses a set of requirements that must be implemented and deployed in the form of application services. Scale, security, performance, monitoring—all must be in place before the application can be deemed "acceptable for consumption." That is what makes up the "deployment pipeline" today.

DEPLOYMENT NEEDS DEVOPS TO REALIZE THE PROMISE OF AUTOMATION AND ORCHESTRATION 

Unfortunately, an altogether too accurate depiction of the state of automation in delivery and deployment is a ski trip with George Jetson and Fred Flintstone. The former, being from the future, rides jet-powered skis while Fred, still living in the past, manages with manual-powered skis. If you guessed George Jetson on his rocket-powered skis is DevOps doing continuous delivery, you're right. And if you guessed NetOps is trying to do continuous deployment with a mostly manual method, you'd also be right. 

NetOps are the folks tasked with provisioning, deploying, and operating the on average 14 application services in use by organizations today. That includes everything from scalability (load balancing and ingress control) to security (web application firewalls and bot defenses) to the more obscure services that improve performance of the entire stack supporting an application.

Now, while they've got skis to help them move faster, they still lack the rocket-assisted skis of their DevOps counterparts.

Disparity in Pipeline Automation Can Lead to Frustrating Delays 

The disparity between automation rates of various application services components needed to achieve "continuous deployment" indicates a need to eliminate the "unbalanced forces" that lead to manual methods still being used by a majority of organizations. This is particularly true for organizations that have automated ZERO deployment components. This is the difference between having rocket-assisted and traditional skis. Even those that have managed to automate pieces of the pipeline have not done so consistently—a mere 21% of organizations have automated all four key components. 11% have only managed to automate a single area, 25% have managed two.

Imagine being mid-flight and suddenly the rockets on your skis are gone.

We can longer depend on the traditional "throw more people at the problem" answer to speeding up deployment. This only manages to compound the delays by adding on more communication layers and process potholes between delivery to production and delivery to the consumer. 

These delays make the business unhappy because they have to wait and worse, often lead to skipping steps (like security) on the way to make up time. To fix this, we need to find and address the "unbalanced forces" slowing down continuous deployment.

WHAT ARE THESE "UNBALANCED FORCES" AND WHAT CAN DEVOPS DO TO REBALANCE THEM?

The unbalancing forces in deployment can be found in the challenges cited by NetOps. Skills, policies, budgets, and integration are significant stumbling blocks for realizing continuous deployment. NetOps can script, don't get me wrong, and they do all the time. But scripting is not automation and doesn't address the need to integrate across potentially 14 different devices, systems, and services. NetOps needs help identifying and putting into practice the tools and methodologies that not only enable integration across these disparate systems but drive the deployment process in a consistent, predictable, and repeatable manner. 

This is where DevOps can help NetOps build a successful continuous deployment practice.

COLLABORATION HAS TO CROSS OVER THE LINE BETWEEN IT AND DEV

Culture is not optional. It has a very real impact on behaviors and practices. Team structure alone dramatically changes pipeline automation, with traditional single-function teams falling behind their contemporary, DevOps-driven counterparts. Push for more collaborative team structures. In that same vein, a collaborative team should be aligned on key metrics. Shared metrics enables NetOps and Security to work toward continuous deployment without penalty. Right now, nearly three-quarters of NetOps are measured on NETWORK UPTIME. Frequency of deployment barely registers for them. They are going to focus on keeping the network up because that's what they must focus on. Shared metrics give NetOps permission to focus on what the business needs—faster, more frequent deployments. 

Finally, empathy is required. You're all on the same team and—it may surprise you to learn—value the same things. NetOps are just as likely to place a high degree of importance on pipeline automation as DevOps. Remember, DevOps has a ten-year head start on NetOps in navigating and overcoming obstacles around integration, tools, and skillsets. Collaborative teams can help by promoting standardization on tools that span from delivery to deployment (like Jenkins and GitHub/GitLab).

Host lunch and learns. Offer to mentor a NetOps counterpart and share insights and links to tutorials and communities that can provide opportunities for NetOps to learn the tricks of the trade. Start an "Automation Center of Excellence" or Community to help establish best practices, share solutions, and encourage the sharing of knowledge that address those "unbalancing forces."

DevOps should not—and cannot—end with delivery. An application isn't really "done" until it's in the hands of its intended consumers. That means deployment—and its admittedly complex pipeline of devices and application services—needs to be automated to reduce the time it takes to get there. DevOps has the skills, the tools, and the experience to help fit NetOps skis with rockets so they, too, can move as fast as the business needs it to.