Managing Software Updates “the DevOps Way”

At a recent DevOps event I attended, I spoke to some members of the DevOps team in one of the largest US banks. The discussion centered around patches and software updates in a Dockerized environment with many files and microservices. It didn’t take long to pinpoint their pain.

“How do you manage software updates in a containerized microservices world?”

This question represents a valid problem which is the complexity of updating and maintaining software binaries. The problem is increasing exponentially as monolith applications are broken down into multiple containerized micro-services, and multiple versions of software binaries are released as Agile development practices lead to shorter release cycles. At the same time, there is a network of interdependencies in which updating a third party binary results in an update for multiple dockerized applications.

This is what motivated me to write this blog in which I will talk about one of the solutions that can be used to manage the cost of updating a software binary, whether for an upgrade, a patch, or even a deprecation.

The cost of an update

Computing the cost of upgrading or patching even a single file has become extremely difficult. Let’s take a scenario where several containerized and even non-containerized applications are running in production, and for some reason, you need to upgrade an rpm package and also patch a jar file. There is one question to ask:

How many applications are impacted by this change?

This change can be due to a major bug fix, a new feature, a security update, the need for legal compliance, etc. Therefore, this question will be asked by many teams: the Ops team needs to know which applications to patch or upgrade, QA teams need to finalize the testing scope, the security team needs to compute security risks, the legal team wants to calculate the impact of legal issues if any, and development stakeholders are looking at the overall scope and even higher depending on the criticality of the change.

To meet the needs of all these teams, you need software that deeply understands all the binaries used in your organization irrespective of their type, whether they are proprietary in-house components or third-party libraries. But more importantly, you need software that can find the relation between the binaries to create a comprehensive graph showing how they are all connected.

Impact Analysis

Once this graph is created, then given an issue or a change, it is easy to know which components are impacted, and this is exactly what JFrog Xray does. It creates a graph similar to the one below by deeply indexing all the files within complex binaries and correlating them.

In this example, a change in component 1 impacts all of its ancestor nodes including App 1, App 2 and App 3. This helps to compute the cost of patching or upgrading Component 1. A more realistic view in JFrog Xray looks like this:

In this example, JFrog Xray lists out the impact of changing scripts.tar. In this case, one of the Docker image layers (identified via sha256)  is impacted along with multiple Docker manifests that reference this layer. Hence it’s relatively easy to identify the impacted docker images or any other complex archive given any change in a binary file.

Software updates are not what they used to be. Containers and microservices have changed everything creating an explosion of binaries that are intricately connected and interdependent thus complicating the update process. Manually identifying all the binaries that are affected by an update is virtually impossible, however, using JFrog Xray’s impact analysis it’s an easy and automated process to find these connections and determine the true cost of a software update.

Ready to do an impact analysis on your microservices? Start your free trial of JFrog Xray.