On today’s episode of Semaphore Uncut, I had the pleasure of chatting with Jason L. van Brackel, director of community at Rancher Labs. When he’s not developing training programs and Rancher engaging the open-source community, Jason is wrangling (pun intended) the DevOps community around all things Kubernetes.
Listen to the episode or watch it on youtube below for:
- Why Rancher is the “easy button” for Kubernetes
- Misconceptions some development teams have about Kubernetes
- Open-source projects making Kubernetes a breeze for enterprises
Watch this Episode on Youtube:
Transcript Highlights
Darko Fabijan (00:16): So hello everyone, welcome to Semaphore Uncut—a show where we talk about the developer community, developer tools, DevOps and all things related to development. Today, we have Jason van Brackel with us. Thank you so much for joining us.
Jason van Brackel: Thanks for having me. I am Jason van Brackel. I am the director of community at Rancher Labs, which is just a really fancy title that means I work with the open-source community of people who use the Rancher project and who aren’t necessarily clients. So I do everything from content generation to hand-to-hand combat with developers and operators working with the software.
Ranch Cast
Darko: Great. And you have another project on the side, if I remember correctly? The YouTube channel you started a while ago?
Jason: Oh yeah. I started the Ranch Cast and it’s on YouTube and Mixer and Twitch, just the Ranch Cast. And the idea was I wanted an intimate way of talking about the operations, developing communities, and the idea of automating all the things.
I’m a huge DevOps practitioner. My background was originally in software development. I spent the better part of 15 or 16 years doing everything from Java, Oracle to PHP and then a whole bunch of time doing everything from VB 5 all the way up through dotnet core. I then got into architecture and DevOps later as a result of getting into architecture and then getting into the last startup I was with prior to my time with Rancher Labs. But I realized that as companies have adopted Kubernetes, there’s that, let’s get started point.
The Staples “Easy Button” for Kubernetes
Darko: (03:11) Right. So, maybe you can walk us through what Rancher is. What’s the vision, what’s the problem you’re trying to solve, and how did it end up where it is right now?
Jason: So, the Rancher project is one of the projects under Rancher Labs. It’s an open source project, I believe it’s Apache 2 licensed alongside other projects like k3s and Longhorn. All these projects are designed to essentially make Kubernetes easier. I don’t remember if you know the Staples commercial, they had this easy button, and you hit the easy button. It said that was easy. The buttons were annoying, but they ended up in everyone’s office. But we want to be that easy button for Kubernetes.
Rancher has a nice, trusty API and a pretty UI, making it really easy to, to use the metaphor, make your Kubernetes clusters cattle and not pets. One of the disturbing things I’ve seen as a DevOps practitioner is that as people were adopting Kubernetes, they were treating the Kubernetes clusters as if they were pets, which is the whole thing we tried to get out in the first place. That’s the idea with Rancher. Just that easy button for Kubernetes.
What’s Next for Rancher
Darko (05:40): Yeah, and in that easy button you get the pretty UI and an easy way to get started. I watched one of the recent hands-on tutorials you did recently, and it was focused on service mesh in Istio. Is that something which is a part of Rancher as a kind of default installation or add on?
Jason: Actually that’s one of the new features coming out in 2.3. Yeah, we’re on the 2.2 Ranch right now. We previewed the Istio feature. We’ve recently previewed new Windows server containers feature. And we will be previewing in our online meetup cluster templates.
So. a lot of the innovations we’re making are based on what the community’s asking for and what our clients are asking for. So we have somewhere between 20 and 30,000 teams using Rancher based on our telemetry and several hundreds that are paying for from a support standpoint. Their ideas aren’t always ours.
The Buzz about Kubernetes Adoption
Darko (11:03): You mentioned that you did a lot of teaching when Docker first started. For development teams starting with Kubernetes and Rancher, what are some of the patterns you have seen with adoption?
Jason: I’ve gotten this question three times. Well, not this specific one, but the question that I’m hearing the most is, “How do I go from my monolith to microservices?” That’s the one I keep hearing over and over again because Kubernetes is a buzzword.
What I’m finding is that there’s one thing that everybody tries, and it almost always fails: it’s the rewrites. Distinct service and their existing software, and they start to adopt this rewrite and think it’s a great idea. They think they can undo all the mistakes they made and make whole new mistakes.
And the problem is that 1) you still have the existing thing that still needs to be supported and featured and add things too, and 2) you alienate that team because usually you create some new team that might pull from the old team but have some newer people to it. So the old team is like, “Oh, are we being replaced?” So the old thing gets neglected. There’s lots of reasons that goes wrong.
There’s a great pattern in there for that and it’s the anti-corruption layer, the idea that corruption layer being that you have system A and system B and there’s this layer in between that is the communication for all of them. Twenty years ago, that’d be like an enterprise service bus or something like that.
Now that’s an API, usually a REST API, but it’s some sort of a shared API. And with the API or pieces of the API and then those pieces are serviced by the old thing, the legacy app. The legacy apps or the framework, and then you start adding microservices for other API calls and then slowly you break off a chunk of the legacy app or the mainframe app, whatever. So the API stays relatively static. You do the same things but API development, but over time you’re slowly breaking off chunks of the legacy app and moving that into distributed microservices.
Jason: Eventually you’re at a point where either you’ve completely replaced the old thing or you have just enough of the old thing around because it’s just too darn expensive to replace that piece. Like you still need that little bit of COBOL or Fortran left. That little bit of VB6 around that just is not going to die because it’s just too expensive to move. Maybe you don’t have the source code anymore and it’s just that executable is going to sit there and run until it just dies and then you’re really hosed.
Making Kubernetes Easier
Darko (19:25): Yeah, and in terms of making Kubernetes easier, what are maybe some exciting projects that you see that are coming or that is already here? I’m touching this every time there is a lot of YAML, there is a lot of configuration that you have to know and understand. So I’m all the time waiting for something easy with UI to come along and I don’t have to do that.
Jason: Well Rancher is really good for that because you can push buttons in the UI and spit out YAML and reuse it. It gives you the ability to learn Kubernetes and then having to adopt Kubernetes all at once and then it gives you the room because it’s a very unopinionated project as to how you do Kubernetes. So it’s Kubernetes your way, but it’s Kubernetes your way with some safeguards and some side rails and some suggested ways of using it.
Instead of having to deal with multiple operating system paradigms where you’re dealing with the Windows operating system as a paradigm and you’re dealing with Linux operating system as a paradigm. Kubernetes is becoming the kernel. The flavor of Kubernetes you’re using, whether it be an EKS cluster or something on prem, becomes your operating system. And then the container is becoming your application sandbox.
What is k3s?
Darko (24:11): And you mentioned two projects that I want to ask about before we wrap up. I think I know what k3s is, but maybe you can reintroduce k3s and Longhorn?
Jason: Sure. The k3s project is a Kubernetes distribution that is meant to be really lightweight. So we’ve ripped out about three million lines of code from Kubernetes, both code and test code. Things like alpha features, things had been deprecated, all the cloud provider stuff. The idea is tiny lightweight and if there’s something that we need, we should either be able to CSI plugin or some sort of plugin model to get it.
It was designed with small footprint in mind, whether that be an ARM device. It’s Kubernetes on the edge. So if I want Kubernetes in my truck, Kubernetes in my restaurant, Kubernetes in my warehouse, I don’t want to have to put a rack at a data center up there to do Kubernetes. That’s the whole idea of k3s.
Longhorn is our distributive block storage software. That was sort of a collaboration with a client. We then continued the work on that as an open source project and that is also now approaching general availability. We’re actually looking to donate to the CNCF. There’s a pull request out for that as another option for distributive block storage.
And again, like everything Rancher does, it has a pretty UI, nice API, simple to set up. You know, ease of use and user experience are key. That was two or three developers who’ve just been working on that and iterating over that pattern for well over a year now. I’m excited to see that come to general availability.
Darko (26:56): Great. Okay, well it was a very interesting discussion. We mentioned a number of interesting projects, so Rancher Cast one of those. I’m looking forward to seeing more about that reference architecture that you’re building and k3s and Longhorn and those are the other products that you can link to from the notes, so yeah, we’ll make sure to share those. Well again, thank you for your time and good luck.
Jason: Thanks for having me. This was a ton of fun.
