Parity, Kubernetes and Cloud-Native Security


· ·

Parity may not be on many folks’ lists of hot IT buzzwords. But perhaps it should be. If you want to improve application quality while also strengthening cloud-native security, striving for parity is a simple but effective way to do it.

What does parity mean, and how can you achieve parity in modern, cloud-native app environments? Keep reading for tips on what parity entails and the tools and methodologies that can help you build CI/CD pipelines that feature strong parity.

What is parity?

In IT, parity refers to achieving consistent conditions across development, staging/testing, and production environments.

In traditional application delivery pipelines, parity was not always a given. Developers often worked in one type of environment — often their local workstations — when they were writing application code. Then, their code would be handed off to a different environment to be tested and staged. Finally, the code would be deployed into production environments, which often took many forms — especially for applications that ran directly on end-users’ devices, which could be configured in any number of different ways.

Thus, the environments in which code was developed and tested were rarely the same as those in which it actually had to run. As a result, it was difficult to guarantee that the way an application behaved in pre-production environments was a reliable predictor of the way it would behave in production.


Likewise, in a delivery chain that lacked parity, pre-production security monitoring and scanning were less effective in identifying vulnerabilities that could arise in production, because some security problems might only manifest themselves under a particular configuration of production environments.

The benefits of parity

Fortunately, the shift to cloud-native application deployment (which means that many applications now run in a single cloud-based environment rather than on end-users’ various devices or on different types of on-premises servers), combined with the rise of tightly integrated CI/CD pipelines, has made a better world possible.

Now, with the proper tooling and planning, DevOps teams can ensure that their environments are consistent across the entire delivery chain — from development right through to production. By extension, they are in a better position to optimize the performance and security of their applications, since the testing and analysis that they perform before deployment can more accurately anticipate the conditions that their applications will face in real-world production environments.

Specifically, maintaining parity helps to:

  • Make releases more consistent and predictable, which in turn improves software quality. Performance or usability issues that would arise in production stand a much better chance of being caught pre-deployment if production environments are consistent with development and testing/staging environments.
  • Reduce the complexity required to manage applications by reducing the number of environment variables (such as different operating system versions or different software libraries) that exist within a deployment pipeline. This reduction in complexity is especially valuable in fast-moving containerized delivery chains, which have enough complications of their own without adding environment variability into the mix.
  • Streamline communication between developers, QA teams, security teams, and IT Ops by ensuring that all teams are working within the same type of environment. In this way, parity helps enable the core goals of DevOps.
  • Improve security by ensuring that pre-release conditions are the same as production conditions, as well as by giving developers more time to address security issues (because the issues are more likely to be detected before they reach production environments).
  • Ensure that application quality or security problems are actually fixed before production. In other words, by giving teams more time to detect and address problems, parity reduces the temptation to push subpar software into production just to meet a release deadline.

Achieving parity

Parity might seem like a difficult goal to achieve.  And it is if you build your development, testing/staging, and production environments using legacy technology.

If you run each environment in a bare-metal server or virtual machine without abstracting applications from the underlying hardware and operating system, it is very difficult to keep all environment variables the same across the different environments. Even if you had identical hardware and operating systems for each environment, it would be very time-consuming to keep every configuration variable and software package consistent across all of your environments.

A better approach is to create your various environments using Kubernetes.  When you take this approach, Kubernetes itself becomes the environment that hosts your applications, no matter which stage they are in.  The underlying operating system and infrastructure don’t matter from your applications’ perspective, because Kubernetes abstracts them away. (Well, the operating system family matters in the respect that Windows containers don’t run on Linux, and vice versa; but the specific operating system version or distribution within a given family doesn’t matter, so long as it supports containers and Kubernetes.)

At the same time, it’s much easier to keep different Kubernetes environments consistent than it is to keep different legacy environments consistent.  By creating a common set of configuration files and container images and then applying them to all of your environments, you eliminate the need to fulfill the nigh-impossible task of keeping operating system configurations and software packages consistent.

Secure from the start

It’s important to note that the simple fact of having parity doesn’t magically guarantee quality or security. Parity only delivers benefits if all of your environments are designed to be as consistent and secure as your production environment.

This may come as something of a challenge to some teams.  In the past, development and testing/staging environments haven’t always been as secure as production environments, since the former were not always connected to the Internet.

But this approach must change if you want to achieve parity.  Your development, testing/staging, and production environments must all be designed to be secure from the start.  You need secure Kubernetes configurations as well as monitoring solutions in place — even for development and testing environments.  Whether or not you think those environments face any real security threats, you must still apply the same oversight and guardrails to them as you would to production, simply because that is what parity requires.


Striving for parity is a simple way to help maximize application quality and security, and Kubernetes is an easy way to build parity into your delivery chain and architecture.  But there’s a caveat, which is that parity only delivers benefits if you ensure that all of your environments — from development through to production — are equally secure.

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO.


Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *