Let's talk about shipping software to customer environments. Whether you call it on-prem or self-managed, this is the software you create that your customers run and operate for themselves. And there's a lot of great things about this, right?
It opens up new markets, it can lead to much more satisfied customers, and it can strengthen your relationship with those customers. But there's one thing about it, and I gotta tell you - it scares me.
The scariest thing about on-prem distribution of software is that I have no idea what my customer is running. It’s a lot better today with containers and Kubernetes - right?
Containers deal with making sure I have the right dependencies. Kubernetes lets me easily describe what to run and how to get traffic to it, but there's still a lot of variability. There's variability around networking and storage and policy, and all sorts of different things that could be going on in the cluster. That isn't necessarily even all stuff that's under your customer's control, because they could have different distributions of Kubernetes and different versions from their cloud provider, or from VMware, or from Red Hat. There are all these different things that could be different than what you're expecting.
If you run and test in AWS and your customer's running GKE or Red Hat OpenShift, there's a lot of different things that could be happening in that cluster that could be a surprise to you when your software first runs there. So, how do we deal with this? Well, one of the main ways to deal with that is to do a lot of testing.
But there's a challenge there in that maybe you don't want to spend a lot of time understanding and maintaining and automating a whole bunch of different environments. You just want to care about the ones that you're using for your production system. So, Replicated built the compatibility matrix to deal with this. We're going to take a quick look at the compatibility matrix here in the Replicated Vendor Portal.
We're going to run the create cluster command from the Vendor Portal, because it gives me this nice GUI that shows me all the options that I have. Not only does it give me this GUI, if I scroll down to the bottom, it's going to tell me how to run that same thing in the command line.
That's pretty important, because hopefully I'm running this in my CI pipeline, so that it's running every time I build and release my software.
Let's set up a cluster, and let's use Red Hat OpenShift, and I'll tell you in a couple minutes why I chose that one.
We're going to use three nodes. We're going to say, “keep it alive for an hour”. I can even do some tagging here. Say that the team that this belongs to is my QA team, and I get a whole lot of things here, and it gives me even the command line that I would set there. I'm going to save that tag, so it shows up here too.
I'm going to copy this over, I'm going to come into this terminal, I'm going to clear it up, and I'm going to run that command - and it's going to create a cluster for me.
That spins up, and it's going to take about 4 or 5 minutes. I'm sorry about that! Let's face it, if you've ever installed some of these clusters, you might think it's kind of funny that I'm apologizing about it taking 5 minutes, but I do want to keep that running while I explain a little bit more about why I picked OpenShift.
Why OpenShift? OpenShift provides a lot of value to large enterprises. They pre-build into their platform beyond the baseline of what Kubernetes has. A lot of features around security, around stability and reliability, around helping you achieve your compliance goals. So, if you're an OpenShift customer, you're looking to be compliant with things like HIPAA and PCI. You're looking to operate your software in a highly secure environment, and you're wanting to make sure you get a lot of reliability out of that cluster. If you think about it, these are some of the same motivations that people have for running your software in their own environment in the first place.
They trust their security controls over yours. Or, they maybe don't want to deal with the compliance constraints of bringing in another vendor. So, instead, they'll get that software running in their environment and they'll feel confident that it's where it needs to be based on the security posture that they expect.
As they configure and set up their Kubernetes cluster in their OpenShift environment, that's mostly built around their first-party software, not the third-party software like they're getting from you. So, you may not have made the same decisions about how to set up the security contexts for your applications, about signing images, about lots of different things that are going to potentially be in that environment. Many of these are going to be happening by default in an OpenShift cluster, which is awesome for your customer, but can create a little bit more complexity for you.
You could say, “okay, well, I'll just run an OpenShift cluster to do testing on”, and you can. It's not a horrible lift. I've done it a few times. I have to admit I've struggled with it as much as I've had success with it - maybe that's all on me. But it's another type of cluster and it's probably not the one you're using for your day-to-day development environments and for any SaaS that you might be running.
Not only that, but you've got to use other elements of the Red Hat infrastructure and ecosystem. If you run an Ubuntu shop, you're now going to have nodes that are running with RHEL and things like that.
There can be a lot of challenges. What I found from talking to different software vendors is that a lot of times, that means they just stand up an OpenShift cluster and they leave it running all the time. They can spend three, four thousand dollars a month. There's a real cost to testing in this environment.
We went over to the compatibility matrix a few minutes ago and we got a cluster started. Let's take a look at how that one's doing.
You can see I'm going through the process still, it's preparing the cluster for me. What we're doing to avoid some of those challenges around how long it might take to stand up or around errors that maybe your team doesn't understand or managing operating systems that your team doesn't understand, we're doing that for you. We're doing it in such a way that we can give it to you very quickly because we keep warm pools of clusters available. We keep the control planes available, we attach nodes into those clusters, and then we make it available to you.
Those clusters never get reused. You go into the pool, you come out and use the cluster, and you get replaced with a new cluster. We keep it live and fresh so that we can continue to give you those clusters quickly, but we never reuse those clusters. You don't want your application being tested in a cluster that someone else has already used, because who knows what could have been lingering from their install and their uninstall. You create it, you destroy it, we give you a fresh one the next time you ask for one. We destroy it automatically after a certain amount of time, or you can destroy it as soon as your tests are finished.
You can access this cluster just like you would any other cluster. We just give you the kube-config information.
Once this is up and in a ready state, we're going to run that command and you're going to see that we can get access to it right away.
Saying how long we want it to be alive, we can extend that, we can delete the cluster when we're done with it, and one of the cool things that's going to happen is after we get past this preparing step, we're going to go into a verifying step.
The reason we do that - we verify every cluster that we create - is because we want to make sure that you have a failing test. Now, it may be that the compatibility matrix is doing its job, and you're finding that running in this particular type of cluster, in this particular version, in other words OpenShift 4.14, there's something about your application that isn't going to run the way you expected it to. That might happen, but that's what it's for!
You're trying to uncover those types of errors, but you're not going to have a situation where a bad cluster is what's causing your failing test because of this verifying step that's going on right now.
I'm showing the GUI, but all of these things we can do are available from the command line as well.
I'll just run [.inline] replicated cluster [.inline].
You can see the different commands. I can list my clusters. I can create them, I can prepare a cluster to spin up right away with my application in it. I can get a shell that is ready to talk to that cluster. I can update the settings. I can upgrade a cluster from one version to another. Lots of different things.
So, let's take a look. This is going to give me that same list that I see there in the GUI.
[.inline] replicated cluster ls [.inline]. That's going to list all of my available clusters. Hopefully this one has gone into a running state while I've been talking about what this command line can do. It has.
So, let's get that [.inline] kubeconfig [.inline].
Now I have access to that cluster, and I'm going to run commands against it as soon as this command completes.
You can see what's in this cluster now.
[.inline] kubectl get namespaces [.inline]
You can see all of the namespaces that were created by OpenShift, and even just looking here you can see all the types of things that OpenShift is giving your customer that might explain why they might want this over more of a baseline Kubernetes environment. Now with this I can install into here, I can run all my tests against it and I can get immediate feedback around what's going to happen when my application runs in this cluster that many of my customers might be running because, again, the same types of customers in those high compliance, high security industries like defense, healthcare, banking, that want to run OpenShift are going to be the ones that want to run your software in their own clusters versus having you run it for them in a hosted model or a SaaS model or something like that.
If you're interested in giving this a try, just come over to replicated.com and connect with us there and we will give you some credits to get started and give this a go.