Quiet Please! Cloud-Native Development in Progress

The adoption of agile development practices and cloud-native architectures are changing the way organizations build and deliver applications. Applications are no longer written but assembled using a plethora of independent services and components that interact via APIs. The shift to reusable service-based architectures is simplifying development for sure but the downstream impact to supporting teams is not yet fully understood. For most organizations, the deployment of new services is happening so quickly that supporting operations and security teams have not yet had the time to see the long-term impact of these strategies nor develop best practices for managing.

Consider back in 2017 the Cloud Security Alliance (CSA) reported that the average enterprise has 464 custom applications deployed and IT security professionals are only aware of 38.4% of these applications. With a predicted growth rate in the number of custom apps by 20.2% per year and that puts the average number of custom apps in an enterprise around 667, YIKES.


Pair that with data reported in the “2019 State of the Software Supply Chain” report produced by Sonatype that states the average modern-day web application contains more than 460 software component releases, of which 85% are open source. And we end up with an ever-growing number of application components that have to be managed and secured.

The Cloud-Native Devil is in the Dependencies

Application packaging was already one of the most ad hoc-managed processes in IT. Cloud deployments and containers in cloud-native architectures have further exasperated the challenges. Containers can act as invisible black boxes, making it impossible for production teams to “see” what is running in the box and compliance teams to audit the components. And the complexity doesn’t end there. Each packaged application component comes with its own set of dependencies. Unmanaged and/or overlooked dependencies increase security risks. This especially applies to transitive dependencies. Transitive dependencies are those dependencies indirectly related to the core component: A depends on B, B depends on C, A then indirectly depends on C.

Take for example Node.js with its dependencies:

Source: https://bldr.habitat.sh/#/pkgs/core/node/latest

We see 26 transitive dependencies in this simple example. This explains why software composition analysis (SCA) tools are now topping the list of application portfolio managers. But SCA tools are only a piece of the puzzle when it comes to implementing a long-term risk management strategy for modern application architectures. Understanding where the vulnerabilities within a codebase are and enabling individual developers to remediate is great, but compliance and remediation in large highly regulated environments will require an enterprisewide approach.

Enter the Need for a Digital Librarian

As we see organizations scale their adoption of cloud-native architectures and application services become smaller, the technical authority and responsibility associated with them become more decentralized. In the world of cloud-native, independent development teams become responsible entities and the role of the IT operator is shifted from gatekeeper to knowledge facilitator.

Historically knowledge facilitation has been done via the creation of libraries that are organized and managed by librarians.

Source: 17 Quotes That Prove Librarians Are the Best

When we think about it, libraries are not all that different than most large enterprises that have been around for a while. Both have a large variety of assets they’ve collected over the years in various states. To track, they require detailed cataloging; assets are subject to theft and need to be protected; worn assets need to be replaced; and assets need to be checked in and out across different users. Thus, are the same set of solutions needed for enterprise application portfolio managers looking to gain control of the software components being consumed within their organization.

Application Packaging Management Strategy

Dealing with this new level of complexity will require new ways of thinking that simplify and make the management of application services more concrete. Organizations will need to operationalize how they manage all the parts and pieces and they will need to do it in a way that is scalable, doesn’t throttle back new innovation and also addresses regulatory and compliance concerns.

Knowing where a component is used will also not be enough. To validate and maintain the component, responsible parties will also need to know if it is the right version, the source of the code, who owns it, who has access to it, what the change history is and whether it meets corporate compliance standards. Capturing this type of data requires an overarching packaging management strategy that can digitally footprint packages and their contents and then catalog them in a searchable and reportable format.

Conclusion: Cloud-Native and AIOps

Applying AIOps (artificial intelligence for IT operations) will eventually become critical in cloud-native environments, since supporting compliance teams will have little to no chance of keeping up with the volume of new packages being created and delivered as more and more applications are developed and deployed. Each service will need to be serialized, indexed and version controlled. Only then can AIOps approaches be applied. Getting there will require a disciplined strategy that reaches across teams, technologies and environments.