DevOps Bundles – New Name of The Game

The way we deploy software for the Web has come a long way from bare metal to VPCs to on-demand VMs with SOA to microservices. Latest big game in the DevOps world was container orchestration which is largely being won by Kubernetes and its ecosystem.

What is coming next? I am starting to believe that the next big thing for DevOps is how we approach bundles. The problem statement here is “How we replicate deployments between environments?” In example, how we test exactly what we have in production? Or how can we explain to the customer what exactly we are going to deploy?

This problem grew exponentially with the push to microservices. That is because monoliths are more or less trivial to track, but microservices – not so much. Another idea that contributes to the importance of bundles (that also seems to be on everyone’s mind these days) – spawning quick and lean integration environments on demand.

For example, during CI/CD run we want to have our full stack running to do integration tests. Or we want to allow developers or QA to quickly spawn a temporarily environment for testing. Goal here is to allow such environments to be created in minutes rather than hours and also allow for their destruction just as easily. At the same time, those environments should closely represent production environments so that our tests would be valid. If achieved, this would be efficient from prospective of both cloud compute costs and developer time.

Here come bundles! In the nutshell, bundles are objects that define what we spawn and relevance of the stack we spawn to what goes in production later. Let’s discuss existing cloud native options for bundles and where they may evolve:

1. GitOps – having infrastructure configuration is git is essential and considered best practice for quite some time. However, it is usually not enough in isolation to properly define full bundle. One issue here is that deployment over GitOps commit point may still be complex. Another issue is that modifications are hard – say dealing with many Git branches may be problematic without additional tools.
2. Helm charts – helm is a great tool which can be used over GitOps and generally allows for bundling cloud native applications well. Main issue with helm is that there is no good way to manage different versions of components and configuration parameters between environments. Again, we either have to deal with excessive Git branching or creating multiple values files. And maintenance of all those differences and version changes is manual.
3. Cloud native bundles (CNAB) – an opinionated spec for packaging application bundles. I find this idea to be great, but this specification is a little heavy to my taste and tooling is lacking. For that reason I prefer CycloneDX SBOM spec with its new version 1.2 that actually allows for bundling cloud native packages.
4. HashiCorp recently announced Waypoint – which is positioned as a platform independent bundle manager. Note, that this product is too fresh to draw any conclusions, but it’s using hcl (like terraform) and so far looks highly opinionated to me.

What we are doing at Reliza with all this? Recently, we have introduced functionality to download instance or revision specs in Reliza Hub in CycloneDX json format. Such CycloneDX exports can later be parsed by Reliza CLI to update specification files like docker-compose or kubernetes yaml files.

Therefore, we are trying to use CycloneDX as a medium to bundle deployment data and extend existing tooling (such as Helm or compose files) to automatically pick up bundle configuration. This solves the problem of manual maintenance and multiple version control branches to maintain such files.

These are early stages for cloud native bundles, a lot of work is happening and updates should be published soon. If you have thoughts or ideas or stories what worked / did not work for you in the past, I would love to hear and discuss those experiences.