Extending DevOps visibility to balance security & scale

This is a guest post for the Computer Weekly Developer Network blog ‘penned’ by Jason Kent in his role as VP of web application security at Qualys.

Yin Yang application options

Application developers have new options available to them for delivering services at startling new paces of innovation. From public cloud and hybrid IT environments through to use of containers, applications can be implemented faster than was possible a decade ago.

But how does a healthy DevOps approach ensure speed without sacrificing security?

The DevOps equation can be looked at like a “yin” and “yang”: seemingly opposite forces that are actually complementary. While Agile development approaches preach the “yin” of innovation and agility, IT operations thrive on the “yang” of stability and consistency. Hence, IT operations teams are often perceived as being wedded to old ways of doing things, and not for enabling innovation to thrive securely and at scale.

Despite perceptions, DevOps doesn’t have to be a lopsided balancing act. Often, the key to collaboration across these teams is simple visibility. In the brave new world of DevOps, that starts with the fundamentals of operations and security. By applying the principles of continuous visibility and IT asset tracking to applications, DevOps teams create cross-team visibility that fosters collaboration by teams who together innovate and operate securely at scale.

Common goals

Collaboration between developers and operations, based on a mutual understanding of how each team traditionally works, encourages better working practices around delivering software. One way to foster that understanding is by ensuring teams create joint goals that improve application development without compromising operations.

Joint DevOps team goals create a common visibility between the wider team. A team that understands what justifies faster speed for development and the IT production requirements of security can strive to achieve both. Anything else is not true DevOps. If Developers might benefit, but operations can’t scale or is forced to cut corners, the wider team fails – and this actually runs contrary to the whole goal for DevOps.

An essential initial goal for DevOps teams to work on together is creating visibility of a project and how it scales. Application developers and software architects can gain an advantage in rapidly developing scalable apps by looking at how IT teams cope at scale.

The basic requirement of scale is to first and foremost know where everything is, plus its current status or latest update. This is such a fundamental element of stability and consistency for practices like IT security, yet new developments in application deployment have a tendency to make such visibility more difficult than it needs to be.

Developers know that applications are much more dynamic than traditional IT operations, which makes visibility of them a more complex problem to solve. While most operations teams simply rely on a list of IT assets or a configuration management database (CMDB) for their service management requirements, the same can’t be said for application development.

Put simply, having a list of all IT assets is not something that has been a priority for application developers in the past. Putting that list together and keeping it up to date should therefore be a priority. But how does a DevOps team do this with applications?

Track application models

Gaining visibility across IT operations, applications and services can be easier said than done, as apps are not just things that are bought and installed. Instead, services can be built or bought, provided by a third party or rented in the cloud. Because applications can be based on many different models that can change over time, this makes it harder to get that accurate picture of all application assets and their status over time.

Looking into how the company buys applications can help here. Applications will be procured, bought and paid for; even internally-developed apps will have their requirements detailed as part of the budgeting process. Using this procurement information can help put together a current position on applications that are in place, even if those apps are not being used or updated currently.

Track moving parts – inventory framework

Having a current position on applications as well as IT assets brings the yin and yang of DevOps into a snapshot of focus, but another reason why application development is more difficult to track than standard physical IT is that apps are harder to define, and thus more challenging to track for stability and consistency over time. However, putting together a framework for application inventories can help.

IT asset management professionals make use of CMDBs to manage the life-cycle of events including software licenses. For application development teams, this inventory framework can include the application itself, the development history, the code used, and the responsibilities that exist around the application too. By keeping this information together and up to date, any problems can be dealt with more easily.

The alternative here relies on people remembering all the requirements and maintaining an institutional memory for all the decisions that were made. For old apps that have been in place for some time, or for more ephemeral web applications that were put in place for one requirement then forgotten about, this is not exactly reliable. An inventory framework can also help when you are looking at issues like use of open source software components.

Having a framework in place can help ensure that mistakes don’t get made and that those responsible for parts of an application can fix mistakes.

The road ahead

Looking ahead, it’s not likely that the volume and variety of web applications will go down any time soon. Banks in the US have upwards of 10,000 web apps, ranging from critical systems through to one-off web pages that were put together for a specific reason in the dim and distant past. Each of these can be moved around the organisation or dynamically scale up to meet demand. However, what they should also have is a record of why they were bought or developed alongside notes on responsibility.

By combining these fundamentals of IT operations with application development, DevOps professionals can continue to drive rapid innovation while ensuring that information on all those assets remains a stable and up to date base to support rapid and secure development over time.