By Robert Buccigrossi, TCG CTO

If you google “DevSecOps”, you will find many references to deployment pipelines, and one of the most popular is from AWS (depicted in the diagram on the below). The pipeline involves many quickly evolving technologies such as CodeCommit, CodeDeploy, and Kubernetes. I confess that I am envious of the capabilities of this pipeline! The container architecture and orchestration allows developers to scale an application to tens of millions of users and provides the ability to deploy statistical A/B testing (changing the interface for a percentage of the containers and tracking if the change improved user metrics). Developers can even deploy an upgrade on a small fraction of the containers, ensuring that the new features are stable before full release.

Why we don’t recommend Kubernetes and the AWS pipeline for existing non-Kubernetes applications — As you can tell from its capabilities, this pipeline was inspired by AWS’ customers like Netflix who manage gigantic cloud-scale applications. So why don’t we recommend this pipeline for an application that doesn’t currently use Kubernetes?

• Cost: Shifting to a full cloud-scale DevSecOps pipeline takes significant resources and time to move to the new infrastructure.
• Risk: The new tools and processes increase the risk of error, can cause difficult to diagnose issues, and even system outages.
• Loss of institutional knowledge: For existing projects, there is institutional knowledge in the current architecture and maintenance processes. This knowledge would be lost in order to adopt a new infrastructure.

DevSecOps can be achieved without these challenges! The key to successfully implementing DevSecOps is to go back to its core philosophy: A single unified team must be responsible for the development, deployment, performance, security, operations, and maintenance of a system. When a single unified DevSecOps team is responsible for both development and operations, they directly suffer the consequences of their errors, issues, and inefficiencies. The team will then naturally embrace key practices to eliminate disruptive issues, improve efficiency, and save time: Automated Deployment, Unit Testing, System Monitoring, and Continuous Integration.

How to adopt DevSecOps practices for your project — You can get DevSecOps practices to work in your existing project in two steps:

• Identify nearest neighbor technologies to what’s currently in use. By using tools that are in or are compatible to the existing enterprise architecture, you don’t need to upend your whole infrastructure. Even better, you can roll out DevOps practices piece-by-piece.
• Use an iterative approach to transition to DevSecOps practices. This allows the DevSecOps team to adopt practices in an order that addresses the biggest pain points first.

Many of the tools that are already in use for existing .NET, Java, JavaScript, PHP, and Ruby applications are great for DevSecOps:

• Automated Unit Testing: XUnit, PHPUnit, JUnit, Mocha, Telerik, Selenium
• Automated Security Testing: W3af, OpenVAS, Varonis, ExCop, Sonarcube
• Continuous Integration / Continuous Delivery: Team City, Jenkins, Gitlab-CI, CircleCI
• Event Monitoring: Nagios, Zabbix, Prometheus, Icinga

This approach allows the team to adopt practices in an order that best improves the project, and therefore naturally maximizes the near-term Return on Investment.

So instead of your development team asking: “How do we move our existing application to a full Kubernetes pipeline?” we suggest that they ask “What DevSecOps practices are the best to help our project from where we are right now?”