For almost five years, we have been researching cloud-native applications. As part of an industry-wide push to cloud-native computing, a lot of stacks and middleware components are proposed every day, but few tools and processes help improving the applications themselves especially in terms of quality attributes such as discoverability, elasticity and resilience. With Helm charts, there is already a higher-level approach to package cloud applications in Kubernetes environments. Our work on static analysis of Helm charts and quality assessment beyond is documented and ongoing. In this post, we take a first look at CNAB, or Cloud Native Application Bundle which is self-described as secure and cloud-agnostic way to deliver applications.
CNAB is best understood as a high-level format which can be translated to existing package installers such as Helm (through Porter), although the bundles can also be installed directly (through Duffle). Each bundle references at least one executable invocation image which parses an environment variable $CNAB_ACTION that typically refers to installation, configuration, deinstallation and other package lifecycle actions similar to those known in operating system packages.
The CNAB specification was initiated in October 2018 and is actively being worked on. CNAB mandates that applications are described by a JSON-formatted bundle file with metadata and references to images, primarily Docker container images but also allowing for alternative runtimes. This choice reflects the relation of CNAB to CNCF’s Open Container Initiative. As the nature of a specification is usually dry, there is a set of example bundles available. Our initial research interest is therefore: Which metrics can we extract from these bundles, and what can we already learn about CNAB?
We wrote a small script to parse all bundle descriptors to automate this task, and now run this script nightly to observe the evolution over time. Currently, there are 21 bundles of which 5 are explicitly declared as base bundles, meaning that other bundles are supposed to build on top of them. One bundle’s descriptor does not conform to the specification which has been duefully reported as issue.
Diving deeper into each bundle, we can see that the syntax mandated, encouraged or offered by the specification is used to a varying degree. On average, each bundle references one invocation image to bootstrap but only 0.3 further images. This suggests that the sample applications are of moderate complexity and the usefulness of CNAB for complex applications still needs to be determined. Further, we see that documentation is non-existent for descriptions and maintainer information. The reasons for their omission are not clear, but the quality deficit could be reduced by extending the required attributes to those. Configuration and security parameters, on the other hand, are more widely used with 1.4 and 1.9 on average, respectively. Almost all images are Docker containers except for one which references the Microsoft Azure cloud provider’s runtime.
Evidently, the numbers so far are neither conclusive nor impressive, and will simply require waiting several months before either the sample bundles repository or external repositories start to be filled with CNAB definitions. From a first look, it appears to be a promising approach nevertheless, bridging existing packaging workflows with cloud-native technologies.