I’m a stone’s throw away from reaching my 1 year anniversary at Bitnami, so it feels like a good time to pause a bit and look back.

After 8 years working at Canonical on a wide range of projects and roles, it was a very difficult step to take and was riddled with uncertainty and anxiety about leaving behind so many things I had poured my heart and soul into for so many years behind, and more than anything else a once-in-a-life-time epic team of people to work with.

A year in, I’m overwhelmingly happy I made that decision.

A lot of people expressed surprise I was joining Bitnami as either they hadn’t heard about them at all or they had but thought of them as a company that “made some installers or something”. However, Bitnami had been quietly but consistently growing in size, scope and revenue, all fueled by being organically profitable which is very rare nowadays in the tech world.

Fast forward a year later Bitnami is starting to move out of the shadows and some of what’s been cooking for a while is getting some well deserved time in the spotlight.

Of the things that are public, I would say they fall into two buckets: Kubernetes & Packaging open source applications.

Kubernetes

The Kubernetes community has been growing at a healthy and inclusive pace for some time now, some would say it’s the hippest place to be right now.

One of things that was attractive to me when changing jobs was the possibility of being able to use some new and interesting technologies more hands-on as part of my day-to-day job, and K8s was at the very top of my list. Shortly after I joined we made a company decision to go all-in on K8s and began setting up our own clusters and migrating over our internal services to it. Aside from the amount of buzz and customer requests we had, once we started using it more hands on it became obvious to us it would win over hearts and minds fairly quickly and we doubled down on being all-in  🙂

Aside from all the knowledge we gained by setting up, maintaining and upgrading our internal clusters, Bitnami acquired a small but very relevant start-up called Skippbox which brought over further expertise in training, but even more interesting was a project called Kubeless.

Kubeless is a functions-as-a-service framework which has the advantage of having been built on top of K8s native objects, making it very easy to extend and interact with anything inside your cluster. That project has been a lot of fun to play with is a natural addition to our internal clusters to fulfill our stated goal of making it easy and enjoyable for our own development team to get deliver software to production.

It was a busy year, have I said it’s been a busy year? So, as well as all of that along came the Helm project. Once we heard “a packaging format for applications on K8s” we knew someone’s current iteration would be derailed  🙂

We jumped in with Deis and helped get the project off the ground by applying our knowledge of how to package software to Helm and quickly produced the majority of the charts that the project launched with. It’s been getting a healthy string of contributions since then, which is as good as you can hope for.

Because humans are visual creatures, no matter how technical, on the heels of the launch of Helm we took the lead on a new project code-named “Monocular”, which is a web-ui to search and navigate existing Helm charts and even deploy them to your cluster with one click. An app store of sorts for K8s applications.

With all that K8s experience in our toolbelts, we started to realise there was a gap in how to consistently deploy applications across clusters. Why across clusters, you say? A very common pattern is to have at least a staging and a production environment, which in K8s you would likely want to model as different clusters. We happen to internal also provide a development cluster as we do so much development in the K8s and often need to test in larger machines or use some specific features that minikube doesn’t satisfy. The way to do that in Helm is essentially to copy and paste your yaml files, which for a small amount of clusters or apps is fine. For us, this quickly grew out of control and realised that we needed to instrument some amount of re-usability and flexibility when trying to use K8s features that Helm itself hadn’t exposed yet. It turned out, we weren’t alone. Our friends over at hept.io and box.com had similar problems and were in fact trying to address it in a similar way (given there were a few ex-googlers in our ranks, jsonnet was picked as the library to help with re-usability), and as such ksonnet was born. You can take  a look at it more closely if you’re interested, but in essence it takes json & jsonnet templates and compiles them down to native K8s yaml files that you can track and feed directly into your cluster.

Packaging open source applications

This is what is probably the most underrated aspect of Bitnami, as it’s probably not very obvious the scale at which we operate and there’s nobody else really to compare the company to.

Let me try and give you some hints at the scale at which we operate. At this exact point in time, you can find Bitnami-built assets as:

• Windows, Linux and macOS installers
• Amazon EC2 VMs
• Azure VMs
• Google Cloud VMs
• Oracle Cloud VMs
• Virtual Machines (OVA’s)
• Huawei Cloud VMs
• Deutsche Telekom VMs
• 1&1 VMs
• GoDaddy VMs
• Centurylink VMs
• Docker containers
• Eclipse Che containers
• Docker-compose templates
• Amazon Cloudformation templates
• Azure ARM templates
• Google deployment templates
• Kubernetes Helm charts
• …and more on its way  🙂

That is 20 different target environments! Even if you just built one applications for all those targets it would be an interesting problem in itself. However, there’s more  🙂

Bitnami has a catalog of about 170+ open source applications of which we don’t always provide the full catalog to every environment as it doesn’t always make sense (not everything makes sense as a Docker container or a multi-tier application), and while I haven’t looked at the exact numbers it would likely average out over all targets at around ~110 apps. That is 110 x 20 = 2,200 assets to build. That on its own should feel daunting for anyone who’s tried to build an application for more than one environment. But wait, there’s more!
Bitnami’s missions is to make it easy for everyone to use open source software, and to try and reach more of “everyone” you need to support major versions of these applications (because not everyone has migrated to Python 3 yet :), so that ends up with around 4,400 assets. Mind. Blown. But you know how it goes, there’s always more!

Building these images and templates is an interesting and hard problem, but the hardcore last-level boss problem is in doing so in a way where you can keep building those continuously so they are actually up-to-date all the time. In order to do that you have to track a lot of software (eg., libssl, libc, openssh, php, java, rails, etc) packaged in different ways (ie., debs, rpms, gems, pip, etc), so you end up watching thousands of different pieces of software over all, some of which can affect every single image (hello openssl & heartbleed!).
To solve this problem there’s over a decade of code that’s been brewing, carefully structured metadata about how applications like to be configured in different scenarios, regression tests, tracking upstream releases and watching and matching CVEs. Over the last year there’s been a tight focus on taking all that work to streamline the tools to plan for continued growth as the landscape of software expands, and some refactoring to be able to shape it into a product that might be useful to others beyond our internal use.

Daunting problems end up being the most fun to work on and this has been no exception. This is why I joined Bitnami, to lead this effort and make open source software a bit easier to use and access every day.