Think like a Dev, act like an Op and harness Security

Creating software is a perpetual journey. Just like relationships, technologies start young and reach maturity over time as they evolve through several phases of completion. Some of them don’t reach adulthood because they’re ahead of their time or simply not practical, while others refuse to go quietly due to their massive popularity in the business world.

Regardless of industry and activity field, truly ground-breaking technologies are designed with a sole intention: to transform the customer experience in ways that no one has done before. With most businesses, however, change doesn’t come naturally, just as habits (good or bad) die-hard in a long-term relationship.

Disrupting an established mindset, toolset, and skillset often sets-off a wildfire in any organization that will take its toll on those who are not willing to adapt. Why learn to operate a machine, when I’ve been a mechanic for so long and I know how to assemble the pieces by hand? On a similar note, why should I - as a network admin - be required to learn programming, or why should I - as programmer - have this role added to my job description: “in charge of developing secure applications”?

This is just one of the many debates fueled by the rise of the DevOps ‘breed’, which is viewed as a cultural shift (or a logical outcome) of the cloud era, while we’re told of the promise to reshape the face of IT. There are numerous ways to define this movement and to nail-down a DevOp’s role within an organization, starting from the compound label.

Start_Coding
Generally seen as a melding of engineering (Dev) and operations (Op), “DevOps is a means to achieving faster outcomes and more satisfied customers”, says Gartner in a report dedicated to the subject. I think this is superbly summarized by the analyst, with highlights on ‘faster’ and ‘satisfied customers’. I’ll further explore the concepts presented in this paper in my next post.

In an extended meaning, DevOps is where the programmatic, puzzle-solving minds of application developers meet the disciplined IT teams focused on stability, and the security pros driven by CIA principles (Confidentiality, Integrity and Availability, not the agency). Let’s consider each segment as an independent silo.

Application delivery teams, most often Agile practitioners, are motivated to ship fast, with constant innovation, while also looking to automate their work to accelerate the efficiency of delivery.

Infrastructure teams, on the other hand, aim for robust and secure systems that are no longer defined by their source code alone, but rather are able to comply with various stability, performance and usability criteria.

Between the two, there doesn’t seem to be much overlap in goals. For instance, operations teams are traditionally not engaged in the application delivery process; they’re usually faced with new applications with either very little, or entirely without, previous synch-up on how to support or secure the new systems.

DevOps have a great opportunity (and responsibility) to mitigate all that hassle by aligning cross-functional teams for the realization of commonly-assumed goals. This, particularly, is one of the major benefits of DevOps’ framework: feedback loops become tighter and everyone is invited to take part, including (or especially) security teams.

Another dimension introduced by this shift has to do with continuous delivery and testing. It helps build an “automated deployment pipeline” (source: Gartner). Although this may sound like a fragmented approach, the continuous delivery model brings significant gains from at least three areas: security, automation, and quality.

By continuously applying security within small releases of functionality, DevOps can identify security vulnerabilities or code errors early in the lifecycle and mitigate the effects before the release enters production. This way, security becomes an ongoing process and a powerful tool in the hands of software delivery teams; capable of leveraging what was so-long seen as the ‘anchor’ slowing-down the speed of innovation.

Breaking down these barriers in organizational culture won’t be a walk in the park for a number of reasons, some of which I’ve highlighted above. It will take time for technical teams to embrace the concepts and apply the best practices to foster collaboration between development and operations teams. Chances are that this ideological shift will have a loud echo in people’s perception of security and how it’s regarded by business development, from an architectural standpoint.

I will continue to explore the DevOps reality, and its implications in the software development of today, with my next post.

In the meantime, I invite you to download this paper on AWS and the use of Gaming Strategies.