Delivery and Deployment Toolchains: Still Subject to the Weakest Link Axiom

You can hardly turn around these days without someone mentioning their DevOps-supporting toolchain. Everyone’s got one (yes, even us) and all of them are enabled by the (other) API economy. According to Wikipedia, a DevOps toolchain is: “a set or combination of tools that aid in the delivery, development, and management of applications throughout the software development lifecycle, as coordinated by an organization that uses DevOps practices.”

Now, that focuses mainly on the app, but there’s also the production side of the house – where software generally spends a good deal of its life (one hopes, at least). The same definition works for that, too, with the caveat that its focus (based on my perspective) is on the “provisioning, configuration, and management of network and app services throughout the app lifecycle, as coordinated by an organization that uses DevOps practices.” In the context of traditional DevOps, this focus expands the “release” phase in the cycle, and covers “release related activities” that include provisioning and deployment of software into production. That necessarily includes (or should include) the network and app services required to enable safe, secure application deliver to target users.

The thing is that no single vendor or open source project contains all the tools necessary to achieve the utopian dream of continuous deployment (that’s the production side of the house, by the way). In fact, some of the same tools used on the app dev side of the wall are used on the production side, as well. Increasingly, we see cross-over between the two worlds which is a good sign for “devops” in general, as it shows some normalization between what are traditional two very entrenched organizations with little in common but the app.

So you might use Puppet or Chef in combination with VMware and Cisco to automate a full stack of network and app services to support the need of an app for security, identity, and scale. You’ve created the applicable templates and scripts required to do that and verified they’re correct, perhaps using Postman and its scripting capabilities to test against virtual infrastructure in the lab. You’ve decided that git is a good choice as a repository for configuration artifacts because app dev already uses it and can provide guidance and maybe even hold a training session or two. And you might even go further and start building an app (or standing up an OpenStack implementation) to orchestrate the process and provide for self-service of individual services. You’re essentially defining the deployment toolchain.

And that’s where the Weakest Link Axiom starts rearing its ugly head. You’re familiar with the premise: a chain is only as as its weakest link. “Strong” is emphasized here because we can replace it with other characteristics like “reliable” or “secure” or “scalable” and the axiom remains as true. This is important because as you start to define the toolchain that will support continuous deployment, each “link” in that chain can become a point of failure, where security or scale or availability is compromised.

Just as planning, verification, and monitoring are critical links in the DevOps toolchain, so must they be in the NetOps toolchain. This is especially important for monitoring, where apps and infrastructure (network and app services) cross paths the most in production environments. It is through monitoring (visibility) that a comprehensive view of everything from business transactions to individual requests and responses can be understood in the event of a failure.

Configuration also necessarily joins the toolchains together, as the configuration of network and app services can be (and often is) peculiar to a given application. 

While the packaging and release mechanisms may leverage similar tools, they are separate concerns that often display great disparity in terms of needs. Because network and app services may be deployed on shared infrastructure, tools that assume a single system approach may not be appropriate for NetOps. Conversely, the use of templates is increasingly common for quickly deploying standardized services in production, but are rarely applicable in DevOps, where applications display a high degree of uniqueness.

Regardless, both toolchains share a common thread – that of the weakness of one link infecting the entire chain. Even if you’re relying on mostly manual-driven deployments that take advantage of scripts, there is still a toolchain that represents the overall process of delivery and deployment. People can, and are, links in the toolchains that deliver and deploy software today. And it is the case that when a critical link is missing – because Bob is out with the latest flu – the process breaks down. The toolchain fails to deliver (or deploy).

It’s important as you continue to move ahead with your internal digital transformation that you recognize the importance of the DevOps and NetOps toolchains and don’t overlook any of the links that comprise it. Failure to pay attention to just one of the links as we make headway on the goal of continuous deployment will weaken the entire chain. As business comes more and more to rely on these interlinked chains, a weak link breaks more than just a process, it breaks the business, too.