How DevSecOps Enabled Kubernetes Service Ownership
While it’s true software development is now among the most important industries in the country—if not the world—it is still undergoing its own transformation—especially with regards to DevOps, security and the emerging role of Kubernetes service ownership. Years ago, tasks were divided based on where they fell in the system life cycle: One team wrote code, another deployed to production and yet another monitored and maintained the service.
As we know, DevSecOps has emerged in recent years to merge these responsibilities into one collaborative, unified effort; free from friction, needless handoffs and bottlenecks. But the truth is, when it comes to Kubernetes, this cultural and practical shift is all summed up in successful service ownership. Why? Because, at the end of the day, DevSecOps is just another name for Kubernetes service ownership. They both strive to achieve the same goal—increased speed, independence and accountability for DevOps teams. Even so, there’s considerable work to be done if we hope to ship code quickly and securely. Regardless of what we decide to call this new shift left, DevSecOps is ultimately synonymous with the secure management of Kubernetes and microservices.
The Birth of DevSecOps
In the past, software development relied on different teams to produce excellent products, albeit with varying job descriptions. While the overall effort was united in spirit, the resulting process itself was siloed, at best. Developers write code; quality assurance teams test it and operations deploys to production.
DevSecOps arose when the industry began to realize that the need for security was not baked into the process but rather bolted on at the end. Security must be present in software development to ensure that the quality and safety of these products meets modern compliance and governance requirements. The goal then became to unite all these roles—and their teams—into one cohesive workflow of secure software development … and voilà, DevSecOps was born.
Siloed teams and workflows, of course, caused unnecessary friction between roles. As a development methodology to increase coordination, DevOps gave way to DevSecOps, creating tighter integration and empowering developers to build and innovate without slowing down production.
The Emergence of Kubernetes Service Ownership
When thinking about the evolution from DevOps to DevSecOps, it’s easy to understand how that paved the way for Kubernetes service ownership. In much the same way, Kubernetes service ownership asks engineers to be responsible for the products they build, at all stages of the software development life cycle.
Instead of tossing code to operations or depending on the site reliability engineering (SRE) team, engineers are responsible for the security and reliability of the code they create—from start to finish.
Further, service ownership in Kubernetes endorses velocity and more unified efforts with customers, who are also expected to take “ownership” of the services they support. In this operational model, service ownership begins at the design phase and ends with managing the sunsetting of the software. Start to finish, a complete life cycle. This model of ownership is scalable and enables teams to deliver what customers expect, quickly and accurately. Operations teams are then free to build a foundation that allows for scalability within the business.
Using the type of best practices seen in the DevSecOps model, Kubernetes service ownership makes this cultural shift possible within the container space, promoting the type of collaborative change needed for a secure and successful future of software development.