Episode 9: Geek Out with Brian Shimkaveg (Part 1): Using Open-Source Software While Managing Risk

Sure. I started my career professionally in the Navy. After graduating from Annapolis with a degree in naval architecture, I served in the submarine community. Did two tours, a fast attack out of Pearl Harbor, Hawaii and a ballistic missile boat out of Kings Bay, Georgia. I transitioned over into the private sector and eventually found myself in the information technology space in the DC area. 

And in all that background with technical know-how engineering and what have you, really only modestly prepared me for what I needed to do to serve our country well in information technology. I had to bootstrap my knowledge of software development, application deployments, cloud technologies, really to become credible in this industry. And so eventually, I made my way from a few different vendors over to Rancher. And I'm excited to help the Rancher team support our customers with Kubernetes and those type of technologies. But the thing is that I feel like I can help customers where they are in their mission. And their challenges and choices about how to ensure that we have a secure supply chain. And how we actually implement the policies and missions that we're required to do. And the same time, make smart choices about the technologies that they choose to do that with. 

I love that. And I think for our audience, whether you're driving around the Beltway or you're sitting having some coffee, Brian, you laid out some wonderful buzzwords. And we will again, try to break those down. But I always like to say to the audience, we're going to put it on you to Google or Bing some of these terms and learn. Because from Kubernetes, to cloud native, to cloud computing, to orchestration, containers, VMs, virtual machines, we'll get into some of that. 

And Brian, you're a storyteller, so you know what we said in our prep calls, for example, in how open-source, DevSecOps, agile methodologies, anytime you want to give that, for example, I think it would be wonderful. Because as I like to say, facts tell, stories sell. And thank you for your service, especially this time of year. So, it's great to be with you, Brian. 

I will say to the audience, I'm a big fan of giving homework. And there are several documents just here in this calendar year, 2024, that you'll want to check out, Securing The Open-Source Software Ecosystem released in January of this year, and not too soon after that, Back to the Building Blocks, A Path Towards Secure and Measurable Software, both published by the White House. Easy to read, consumable, and I think after this episode and when you watch this, I think you're going to be intrigued and interested in wanting to learn more. 

So Brian, back to you. Let's talk a little bit about what makes Rancher Government special, and that it is one of many companies that are helping support that diverse mission in the federal government. 

Rancher does two things very well. First, we identify with the mission. We understand what the soldiers and sailors and other elements of the Department of Defense and the federal civilian segments are dealing with, from a security perspective, from an operational perspective, from a reliability perspective. Because we're based here in the D.C. area, because many of our folks that are in the field and connecting with customers, we want to hear about and learn about their mission sets. And to make sure that what we're talking to them about is always in the context of what they're trying to do. 

The second is because we're committed to the open-source communities and the open-source innovations that happen there, we bridge all of the excellent innovation that's happening with developers across the world in open-source communities. And make it consumable for the government, make it meet the mission requirements, make it meet the security requirements. And have the ability to communicate that to all stakeholders on the mission side. 

I appreciate that. And I wrote down two things that you highlighted, and I kind of like to think of myself as the audience as well. Mission mattermost to Rancher Government Solutions and these communities. So, let's peel back a little bit on that. I think when people hear open-source, Brian, I mean it depends on where the mind goes. Oh, it's great. It's open-source. Anybody can use it. But wait a minute. Is that going to cause some issue, a security standpoint? But hmm, there are instantiations of it, distributions of it, versions of it, right? There are companies that promote it. 

I'll get to, if I may, down the road in this interview, some of the impactful or what's impacting our nation's most critical sectors, as a result of the open-source community. So can you speak a little bit more about, what does it mean to be part of an open-source community, and then to differentiate your company as well? We take it to that next level. So when you bring us in, you have access to really, really, really amazing experts with our instantiation of Kubernetes or what have you. 

When we talk about source code, we're talking about human-readable text. We're talking about things that are written in sophisticated languages of computer science. These might be Java or Go or C++. You've heard of them. But they're human-readable, logical statements that get embedded in a Word file, in a text file. And a simple case is where you write some functionality, you save it in a file, and you store it in a common location, GitHub or someplace like that. That's open-source. There's licenses around what you can do with open-source. You can share it, you can distribute it, all those kinds of things. And that framework has been set up for years. But software isn't written on one file. It's not a few lines of code in one Word document that's sitting out there on GitHub. To provide any sophistication at all, you have to have multiple files that talk to one another. 

And so, I was talking to you earlier in the week and we were talking about an analogy, and an analogy would be about ingredients and cake baking. An ingredient is like the open-source code. It is fundamental, it is undistilled, it still has a supply chain, it has value. You can buy high quality flour or you can buy low quality flour. You can buy high quality salt or low quality salt. And all of those ingredients, the recipe for that can sit out there on the web. And it's great. Anybody can bake that cake. 

But to transform that open-source code, developers go through a process called compilation and packaging. And what that means is they're going to combine the ingredients, they're going to use tools that is going to transform that from source code, which is human-readable in text files, to zeros and ones. That's the baked cake. 

And they also package it so that at the end of the day, the consumer or the user of it, the federal government or whomever else, is actually enjoying a cake and not just the raw material that's there. And you know that the difference between a star baker and the one that got kicked off the greatest British Baking Show didn't combine the ingredients correctly or well. So, baking really matters, and in supply chain really matters to make sure that you have the best ingredients for that. 

And yes, I'm going to augment that a bit and just introduce the term DevSecOps. Because if you can just get your head wrapped around open-source... And Brian, look, we're going to get into some of the challenges of calling on federal government, how you make a sale, or how you engage to establish trust with government customers current and to be, for something that is hidden in plain view. It's not like selling an application. It's not like talking about AI and going, "Look what this tool could do on your iPhone." It's the underpinning. 

And I'm just going to have to do this in shout out that the result of open-source and its influence in our world, Linux, Apache Web Server, MySQL, WordPress, Git, OpenStack, Kubernetes, Hadoop, OpenOffice. I mean there are so many things that we are using, folks, that are military, that are utility sector, our manufacturing sector, our healthcare sector. The things we do to save lives, extend life, make sure our food is secure, you can argue that it's rooted in some community that focused around open-source. 

So let pivot, Brian, and then we're going to move into the Rancher, what are you working on right now? But another document I wanted to highlight was the Department of Defense Enterprise, DevSecOps Fundamentals, Version 2.5 dated October of 2024. And for the audience, again, DevSecOps is a software engineering culture and practice that aims to unify software development, dev, security, sec, and operations, ops. DevSecOps emphasizes collaboration and communication between development, security, and operations teams, all of which the government depends on, to deliver secure and, key word here, resilient software at the speed of relevance. 

So that's more, Brian, how I like to think of, wow, that is what is the mission of government. So with that, let's delve into, and please bring out some buzzwords. What is what Rancher's excited about? What is it selling today that the government could benefit from? 

And so, when you have errors, how can you provide a cure to the vulnerability that's out there? Sometimes those vulnerabilities are just an error of logic and a bug, if you will. Sometimes that they can be pernicious as well, by a bad actor introducing something into a code base or something like that. But at the end of the day, you want to make sure that what you are deploying is known from known sources and will perform reliably. And doesn't have backdoors and all those other kinds of nasty things that could be introduced into a system. That is what the interest of the security folks are. 

And then the operations folks want to make sure that it's reliable, scalable, operational, beyond just day one. And so as you take a piece of software and you develop it to serve a mission use case, the life cycle of that application passes through time, enhancements to the capability, enhancements to the underlying infrastructure that's supporting you. All of these things have to be continuously advanced through career through time. 

If you think about your experience with Google, probably back in the 2004 timeframe, it was a cool new technology. It was a much better alternative to what the other alternatives were at the time. But still, when you look back 20 years, the sophistication, the power, the answers that you get from those types of technologies is significantly improved over time. And why does that happen? Because of DevSecOps. We continuously develop, we are constantly assessing security, and the operations have gone from a few users to hundreds of millions of, if not billions, of users. 

So to answer the question in the government context, why does DevSecOps matter and why does Kubernetes and the things that Rancher is offering? One is on the context of security. These tools that have come to market in the form of Kubernetes and docker containers and all those types of low-level technologies that's not at the top of the stack, is not as sexy, but is critical to operations, we do that plumbing work. And we make sure that when those important technologies, which are controlling kernel processes on the Linux machine, which sounds pretty boring and dry, work every time. And allows applications to be ported from the edge case, to the data center, to wherever the customer needs to have it operational. 

And it helps in scaling, which goes from, "Hey, I'm a laptop developer and I've got my single instance of my app and I can hack away. And I know that my party of one can really have a great experience with this application." But does that scale to a thousand or 10,000 or a hundred thousand users? If you're in the Department of Defense and your use case is working with battalions or divisions or something like that, at that level, you have a certain level of scale that you need and a certain level of sophistication that you need. If you are the Department of Energy or the Department of Homeland Security or the Department of Commerce, and now your use case is, "Hey, I need to serve millions of users against this application.", Kubernetes is a technology that allows you to go and to expand to those levels.

So, let me try to provide a translation into a language that I have become more comfortable with as time has passed, so that others outside of the language can understand in a consumable way. And I'd say this, think of it as a model of a Lego. We talked a little while ago about the ingredients and a piece of cake, that the ingredients matter, the compilation in building eventually creates the cake. And how you do that really matters. 

But a software just isn't one piece of code that is embedded in a file. It is that, but when you architect software, you're talking about lots of files with distinct bytes of functionality or components of that wind up talking to one another. And as developers are developing more and more sophisticated applications, they create something in what you might consider to be like a Lego-like structure. Things at low level, things near the host machine or the kernel are very low on that stack. And as you progress up the stack, you need an operating system, and then perhaps some middleware, and then perhaps some functionality for the end-using application. 

And so, you can think of it like a stack. And when developers are creating at the top layer an application that's serving a mission function, they're making calls, the code itself is calling down to the next layer below and the next layer below. And so, there's this problem of plumbing that you need the stack to talk to one another all the way up and down. And when you do an open-source project, you download some bits, and especially if you go unsupported, you download some bits on the lowest layer and then the middle layer and then the intermediate layer and then the top layer. And then you hope and pray, "If my world could just be static and everything below it be static, I can just code my thing. And I'll be done and we'll be satisfied." 

But we also talked about that passing of time and how Google went from a capability in 2004 to the capability in 2024. That top layer of Google has changed significantly, and also parts in between have changed significantly. And when you're working with that and you're working with open-source communities, open-source communities love to hack in whatever layer that they are. So, the operating system developers are developing at the lowest level. The middleware developers are developing in the middleware. And then the application developers. And they may be federal system integrators that are developing at that top layer to create that mission application for the warfighter or for the farmer or for the Geospatial Intelligence Agency. Whatever they are, they're not working on solid ground because that innovation is happening all the time. And if you're writing something at the top of the stack that's relying upon something in the middle of the stack and the low stack, and it's constantly changing, it's mind mindbogglingly painful. 

So, this is where RGS comes in. We are a part of that stack. We're innovators at the Kubernetes layer, at the longhorn layer, at the K3s layer. These components are in the middle of the stack, and so we have to work with folks that are lower in the stack and folks that are above in the stack. And when you really want to rely upon a mission-critical stack that's going to provide mission functionality, decision advantage, all those kinds of things, you want to make sure that people that are working in the middle of the stack are talking to both the people below and the people above, so that the functionality continues to work as time is passing. 

Without that, what you find is that you get technical debt. You say, "I'm not going to innovate at the bottom layer or the middle layer, or even at the top layer, because things are too hard to change." And that's where DevSecOps, where we have this freedom and flexibility to update. And as time is passing, and improve this software and improve the functionality, improve the security of it, is working in partners with the people that are subject matter experts at the layer that we're talking about.