Stories From KubeCon: IBM announces Razee, a Multi-Cluster Continuous Delivery Tool for Kubernetes

DZone 's Guide to

Stories From KubeCon: IBM announces Razee, a Multi-Cluster Continuous Delivery Tool for Kubernetes

Stop pushing and start pulling with this new continuous delivery tool for Kubernetes, straight from IBM at KubeCon.

· DevOps Zone ·
Free Resource


It started with a pull-oriented model and a dream...

First an apology: it has taken me months to get these KubeCon interviews published. Life, as it always does, got in the way. Each is likely to be two parts, a general interview, then a dive into a tool mentioned. The first part of the interview with Jason covered IBM’s general cloud strategy.

Hear the full interview below; it’s the first of the three.

You may also enjoy:  Top 11 Continuous Delivery Tools for Kubernetes (Part 1)

Why is IBM at Kubecon?

Apart from just awareness of our capabilities and telling people about our contributions in the space, the new thing is we’re announcing a new open-source project called Razee, a continuous delivery framework for cloud-native microservices.

One of the challenges we found when we were running Kubernetes, is that we run our managed service on well over 10,000 clusters around the world, and inside of all those clusters, we manage software on behalf of users. How do you manage that? How do you do rollout microservices to 10 or 20 thousand locations? How do you have flexibility around what gets updated when, and how that update process works? We started with a traditional Jenkins-triggered CD process and found that at that kind of scale and in the microservice world that didn’t work well, as it is incredibly complex.

Razee is our rules-based pull oriented CD framework that we think is great for managing complex microservice environments. We’re open-sourcing it, and we’re starting to build it into our management tools and releasing it to the community.

We use it ourselves, and one of the things it does well is it gives you a view of what’s running everywhere. And that’s a problem that lots of enterprises need solving. If you think about how to run compliant workloads on a Kubernetes platform, you need to know exactly what version of every container was running when, and when was it updated, so you can prove compliance and all that kind of boring stuff.

We think it’s an interesting approach to continuous delivery and something the community hasn’t quite nailed yet. If we all believe in microservices and that we’re going to have multi-client environments with clusters all over the place, how do you manage that from a CD perspective?

Why Do You Think the Community Hasn’t Nailed It? There Are Lots of Options Available

There are two fundamental ideas in Razee that we found made it worth it for us. One was going from push- to pull-oriented. If you think about how your phone updates, it’s a pull-orientated model. All phones check in with a server to see if there are updates available and they pull them down and update. That’s the way Razee works; it’s not the way people traditionally do CD. CD is usually a pipeline with something like Jenkins, and you push the changes into your environments. This works when you have dev, test, and prod, but doesn’t work when you have 100 or 1,000 environments, or you have a lot of the rules about when you want to update what.

Let’s say you’re running six major regions in the world. You want to roll out a change. You want to start in Australia where you have a smaller customer base and roll it to the US, where we have a big customer base. Coding all those kinds of rules into a traditional CD system is hard.

With Razee, we modeled everything as feature flags, and represent every cluster in the world as a target that we can write rules against.

Getting Started with Razee

I took Razee for a quick spin on my Docker for Mac Kubernetes, first use kubectl to install RazeeDash:

kubectl apply -f https://github.com/razee-io/Kapitan-delta/releases/latest/download/resource.yaml
kubectl apply -f https://github.com/razee-io/Razee/releases/latest/download/resource.yaml

Then I was slightly stuck, as the website “getting started” say to go to https://app.razee.io, which asked me to sign in to GitHub, but would only let me select organization repos from GitHub, which makes sense, but isn’t so great for testing. Instead, I headed to the full docs, which went into a little more detail, so follow this instead.

Once you’ve followed those, RazeeDash should be running on port 8080, of localhost in my case. You still need to authenticate with a repository provider, but this time you have more options available. Then there are a couple more steps on your cluster, and finally, you should be able to see your cluster running. Obviously, with a tool like Razee, the next step is configuring the information you want to monitor via a series of YAML files, and the possibilities are extensive. Dig more into the docs posted above to find out much more including the feature flag options, integrations with the Launch Darkly SDK, and so much more.

Further Reading

Enterprise Kubernetes: 5 Insights from KubeCon 2018

Top 11 Continuous Delivery Tools for Kubernetes (Part 1)

cloud, cloud native, continous delivery, hybrid cloud, ibm, kubernetes, monitoring, open source, pull oriented model

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}