Adam Clater, Chief Architect, North America Public Sector at Red Hat, discusses the value of a Red Hat subscription and Red Hat’s process for refining open source innovation into stable, secure solutions for your state and local agency or academic institution's production environments.
Rich Savage: Thank you for joining us today. This is Rich Savage with the Red Hat team at Carahsoft, and I'm here with Adam Clater, Chief Architect for the US Public Sector at Red Hat, to talk about the value of a Red Hat subscription. Now Adam, I know this is a subject you are very passionate about. Can you please take a moment to explain the important distinction between enterprise open-source technologies and their unsupported community-based alternatives?
Adam Clater: Yeah, absolutely, Rich, and thanks so much for having me on. It's always a pleasure to work with you all in Carahsoft and do these. I think the first thing to understand about the enterprise supported open-source software like what Red Hat ships is you do get that support. So you've got someone that you can call and get access to and help resolve those issues when you find them, but it's a lot more than that. So we have the concept of security patches and updates, which are an integral part of what happens for our customers, but sometimes security issues will happen before we have the opportunity to make a patch widely available. So if there's a patch that you need that's not yet been accepted in the upstream community, Red Hat can work on that patch, make it available to you, and then support that on an exception basis to get you back where you need to be and get up and going.
Along with that comes just a whole host of certifications and accreditations, and some of these you may think of as the Good Housekeeping rubber seal of accreditations, and the first, obviously, is Common Criteria. Red Hat Enterprise Linux has been through Common Criteria evaluation more than any other operating system in the world. We take it incredibly seriously. Actually, DISA requires that if you're in a national security program, you're using a nationally secured system, then you have to conform to Common Criteria. Other than that, and again, that's a third party accreditation, it's actually part of a series of treaties that the US government has signed on to how that's done.
Another in addition to that is this idea of FIPS 140-2. So FIPS 140-2 is actually required by the department of commerce, and it says if we're going to be doing encryption, we have to guarantee that we're doing encryption in the way that the algorithms were designed, so that no back doors have been inserted to them, and no third party has ability to read what's being encrypted in those messages. So that's another third party evaluation where they evaluate the source code and the binaries that make up the encryption libraries within Red Hat Linux, for example, but that certification and accreditation applies specifically to the binaries as they're shipped from the manufacturer. So if you just download the source code, you're not actually running a supported encryption. We can go on and on about this. There's the idea of technical account managers and a variety of other services that we make available to customers sort of in that support.
Rich Savage: Great, thank you for that, Adam, and I always like to hear this. Can you give us a brief overview of the process that Red Hat takes to turn upstream Fedora into a hardened enterprise piece of software?
Adam Clater: Sure, absolutely. So it actually starts before the software gets into the community, and I say that because the currency of value in open-source communities is really contribution, and so the first thing that Red Hat does is we spend a lot of time contributing to these communities. So when you think about the Linux kernel, Red Hat's the number two overall contributor to the Linux kernel. Intel is the number one. They found that they can sell a lot of microprocessors by enabling them in the Linux kernel early and often, but Red Hat's the number two overall contributor, and more importantly, we're the number one approver of changes to the Linux kernel. So somewhere between 20 and 25% of all changes that happen in the Linux kernel are being approved by someone with an @redhat.com email address.
That means that Red Hat has the ability to kind of safeguard systems on behalf of our customers. So if someone wants to make a change to a memory subsystem that might impact the way your real time operating system is going to run, your real time Red Hat Enterprise Linux, we've got the insight from that contribution to safeguard those changes and say, "Okay, this is something we can or we can't accept," but more importantly, if the change is made, we understand how it's going to affect all of the other components and make sure that they're kept up to date as well.
This history of contribution doesn't just apply the Linux kernel though. We're significant contributors to Kubernetes, we're the number two overall behind just Google. We are the sort of creator and progenitor of CRIO, and CRIO is de facto standard. In fact, it's the standard from the cloud-native computing foundation for Kubernetes. So it's the Kubernetes native container. We belong to an organization called the Open Container Initiative, which says that if you write a container that conforms to this standard, then you can run it on any of these other container platforms, that's a big part of that support, and then we're currently in the top three when it comes to contribution to OpenStack.
So really, step one for Red Hat is contribute, and then we become a consumer of those upstream bids and we sort of productize those, and there's a variety of QA and engineering testing that goes into those, and of course, all of those fixes make their way back out to the community. Red Hat is an upstream first, a hundred percent open-source community. So everything that we ship, we make the source code available to, and we don't ship it generally, with the exception of those one off security fixes, or hot fixes as we might call them. We don't ship anything that we don't have already accepted into a mainline upstream community. It's really, really important for Red Hat.
Integration testing, certification, accreditation. We work really, really closely with a lot of your hardware vendors to make sure that when that operating system or that piece of software arrives in your data center and you go to run it on your hardware, you know both the hardware manufacturer and Red Hat have said, "Hey, this is compatible, and we're both going to support this in a very bi-directional way," and we have those kinds of agreements with folks like Microsoft, folks like VMware, folks like Oracle, and then of course, all of the major hardware manufacturers. So that's a big part of the testing and accreditation.
Then the securing. We work with DISA and with the NSA to develop the STIG, which is the Secure Technical Implementation Guidelines for the department of defense. We actually ship the capability to apply the DOD STIG directly in the operating system installer so you can apply the DOD STIG at the point when you do the installation of that operating system. No longer are system admins walking around with clipboards and sheets of paper trying to keep track of what controls have been applied to what machines and what's been invalidated, blah, blah, blah, blah, and then, of course, we have the ability through tools like SCAP or Ansible to make sure that those controls are persistent and kept up to date over time.
Rich Savage: Great. That definitely segues into my next question talking about security. Security is paramount to all of our public sector customers. In what ways is Red Hat and the software that Red Hat produces more secure ... Maybe a better way to say it is gives customers more security as opposed to just using the community open-source software?
Adam Clater: Yeah. So we talked about the security accreditations and we talked a little bit about the DISA STIG, which is really where we partner with DOD to make sure that those security controls are really consumable and understandable. A lot of that stuff flows down from FISMA, Federal Information Security Management Act, I believe, and those get interpreted by NIST into section 853. So a lot of our government customers are familiar with this concept of NIST 853 and how those controls sort of get translated into what gets applied to the operating system. The DOD STIG is their interpretation of the NIST controls, but we can work with any of our customers for their custom baseline of whatever their security controls are to make sure that they get those in place.
Another thing that we do is when we ship Red Hat Enterprise Linux, and generally when we ship a product that's going to run on Red Hat Enterprise Linux, we ship it with security-enhanced Linux, or SE Linux enforcing turned on. So when you install Red Hat Enterprise Linux eight, it's automatically going to enable security-enhanced Linux. Now this is a really cool technology, because what SE Linux does is it applies mandatory access control labels on every single resource within that operating system. So if, let's say, your Oracle user starts up a database, it's going to apply SE Linux controls around that, and what that does is the kernel prevents processes from talking to other resources that are not specifically enumerated for that process, whether that be your Apache server, your Tomcat server, or any of a variety of other technologies.
Now we've taken that one step further, in that with our OpenShift containerization platform, we have SE Linux on in the container platform by default. So every time a container gets created, there are SE Linux controls that are automatically applied to that container to maintain that isolation. So as you're running tens or hundreds or thousands of containers on a single operating system, you know that it's going to be isolated with that, and that's key. That technology is really key for how we've been able to pass our Common Criteria certification. I think sort of the ongoing support that Red Hat provides ... When we say we're going to support an operating system, that's 10 years from the date that we issue that operating system, plus we have additional years that can be bought, and so you've got that sort of guarantee that I'm installing this, I'm building this, I know when this is going to stop being supported, but I also know how long it's going to be supported, and that during that time, I've got Red Hat standing behind it to say that if there is a security vulnerability or a patch that's required, of course, we're going to make that available.
A lot of what Red Hat does is we actually end up backporting patches into earlier kernels. So to explain, the operating system will ship with a particular version of the kernel. When we ship the operating system, we make a commitment that if you compile a binary or write an application to talk to APIs in that operating system on day one that it's released, it's going to be fully supported in year 10 that that operating system is available. Well, that's really interesting. That's incredibly difficult, because over that time, Red Hat is actually backporting features and functionality out of future looking kernels. So if we're on kernel four now and those features are being supported, in the future, kernel five is going to come out, we're going to back features and functionality to continue that enablement for those customers over that 10 year life cycle. Some of it could be hardware enablement, but a lot of it could be security patches that are being rolled out as well. So getting those security patches out of those future kernel versions, backporting them into older kernel versions, that's something that's pretty unique about Red Hat. Not a lot of other Linux or even software companies in general are prepared to maintain multiple streams of the Linux kernel and manage the backporting of those security fixes across them.
Rich Savage: That's a great answer, Adam. Thank you, and we're going to switch gears a little bit here. Red Hat, I feel like really paved the way for software subscription business. Can you tell our listeners a little bit how that differs from the traditional perpetual software license that most people are accustomed to?
Adam Clater: Yeah. We like to say that at Red Hat, we've got to earn our business every day, because the reality is we sell a subscription and ... We'll have to check the records, but I think Red Hat was the first to actually walk down this path of software subscriptions, which is ... Now everybody's doing a software subscription now, so it's good to be in really good company. It's hard sometimes to be the first one there, though. So what that means is that at Red Hat, you buy a one year subscription to Red Hat Enterprise Linux. At the end of the year, if you decide, "Man, I don't really feel like Red Hat did their job," or, "I had an issue," or, "I had this," you can decide that you don't want to have support anymore for it. Now you're then running unsupported software in your data center, but it at least gives you that flexibility where Red Hat isn't going to come and knock on your door and say, "Hey, you didn't pay your bill, but I know you're still running that software, so you've got to pay me or you've got to true up or you've got to do this." Those really aren't practices that we engage in.
Now by and large, most of our customers will make a decision that Red Hat Enterprise Linux makes a lot of sense. "I get a lot of value from Red Hat in doing this, and so I'm going to continue on with that subscription," but you can buy one year, and if you don't like what we've done in that one year, you don't have to pay for the next year's subscription. You can keep on running it. Now things you won't get. You won't be able to call in for support, we're not going to be able to do that. You're not going to be able to have access to updates and patches, because that's an ongoing part of the support. You're not going to be able to have access to our knowledge base. Our knowledge base is really comprehensive, and we've got initiatives within the support organization that if a ticket's opened, a knowledge base article is the outcome of any ticket. So if it's a new issue, then that support engineer needs to go write a new knowledge base article and get that in there, because we understand folks want to be able to have fast resolution, they want access to a lot of information and data. Some don't always want to get on the phone every time they have a problem. So that's a big part of what we do as well.
Rich Savage: Thank you, Adam. For our state and local government customers and our higher education customers, a little bit different than the federal government. So in what ways have you seen that those customers benefit from using enterprise open-source software?
Adam Clater: So it's tremendous. We see adoption of these enterprise technologies throughout the state and local government. To be quite honest, every state is, in some regards, a microcosm of the federal government. So when you think about homeland security, you've got police forces, you've got national guard organizations, you've got health and human services organizations, you've got folks that are providing services all over the place. So when we talk about ... An eligibility system, I think, is a great example of a solution that we're seeing deployed in both state and local and the federal government.
So for example, how do I know whether an individual is eligible for a service? Let's just say snap benefits, like food stamp program. We've got to take information from a lot of different places, and so the first step that has to happen is I've got to connect my application to all of these other data information services and figure out how to speak the languages that they're speaking. Well, that's a classic integration problem. How do I integrate with all of these applications? So we're seeing a lot of customers using our fuse technology to do that integration. That runs really well on OpenShift, but it takes a lot more than that.
Once I gather all of that information together, I've got to use something like a Red Hat decision manager to evaluate the criteria so that I can, in a very automated fashion, without a lot of paper shuffling, make a decision of whether someone is available for these snap benefits or not, and this is really important, because we're talking about delivering real services to humans, real people that are having real problems, and so being able to automate those workflows and make them happen faster and get those services out to those folks is vitally important. That's happening at the federal level, and I guarantee you that's happening at the state level. Those are the folks who are making the decisions there. So that's just one example, but we see it all over the place.
Rich Savage: Excellent. Thank you, and it's crazy to see the evolution of enterprise open-source software in the industry. Crazy to think 10 to 15 years ago, that wasn't really even widely accepted or even used in many agencies, and now today, 86% of IT leaders say that most innovative organizations are using enterprise open-source software to really make an impact on furthering either their businesses or their agencies, and Adam, for our listeners, if they want to learn more about the value of a Red Hat subscription and enterprise open-source software, do you have any suggestions on where they can go to learn more?
Adam Clater: Yeah. Obviously, we've got a great website at redhat.com. We've got a whole variety of activities and sort of online learning sessions that are going on that we can make available to people, but reach out to your Red Hat account person, whoever that is. Whether you're commercial, state, local, federal, we've got someone who's in charge of making sure that all of this information gets into your hands and so that you have a very clear understanding of what the value is of these things, but I think it's also important for folks to understand sort of the breadth.
You mentioned this idea that 10 years ago, would people have been using enterprise open-source? I'll tell you, it was hard. It'll be my 10 year anniversary at Red Hat in December of this year, and to be quite honest, the amount of time that we spent sort of trying to convince people that open-source was acceptable for their government need, as an evangelist and as someone who sort of talks to customers about this all the time, we spent a lot of time saying, "It's okay, someone else over there has done it. The FBI has used this technology, or the department of defense has used this technology, or homeland has used this technology. It's going to be okay, you can do this," and people would say, "I just don't want to be the first one to jump on the bus and to get out there," and we're finally able to say, "You know what, you're dangerously close to being the last," which is a great position for us to finally be in from an open-source technology perspective.
I think what people have really learned about open-source, and it's really been a significant change in that 10 year period, is that open-source communities are actually the driving source of innovation today. If you think about open source, I'll say 20 years ago, maybe 15, it was really about commoditization. It was, "Well, I want to use Linux so that I can stop paying this big bill to Sun Microsystems and decouple my operating system from my hardware purchase decision making," and that was great. That was a great service, and we kind of really shook up the industry. At Red Hat, we'd love to say that we've changed the world a little bit, but it's a whole different world now. It's not about commoditizing. I'm not looking to come unseat somebody who's there, I'm trying to move your organization forward into a world of cloud, multi-cloud, how are we going to deploy these things? How are we going to get to containerization?
I think a lot of people have finally accepted that just lifting and shifting a workload out of their data center and into the cloud is not really clouding right. It's becoming a bit more of an anti-pattern. I always equate that to sort of having a managed services contract with a cloud provider, which is pretty expensive. If you want a managed services contract, go bid one, but if you really want to consume cloud, you've got to think of this idea of how do I make applications that are going to start up and shut down and be atomic in that way, and containerization is really well suited to that. That came directly out of open source communities, and to be quite honest, containerization would have never been possible without technologies that are built directly into the Linux kernel. So there's two concepts of Linux and containerization, they're so tightly coupled with one another, they're really important.
Rich Savage: I don't think you can have digital transformation or IT modernization, and now going into AI and machine learning, without enterprise open-source, I don't think those things are even possible, thanks to the contributions from those communities.
Adam Clater: I agree completely. It's funny, because if we look at the first technologies to really be able to make their way out into cloud, the first cloud services were really based on Linux, and you can certainly deploy a Windows workload and get that into the cloud, but even Microsoft will say it's only a small ... Well, not a small percentage, but it's a lesser percentage than those of the Linux workloads that are in these public clouds. So accordingly, cloud providers have had to really be agile and think on their feet and say, "Okay, if I've got a shop that's not a Linux shop, I'm going to have to kind of build services in the cloud and make those available," whereas those organizations that were sort of Linux natives became cloud natives very, very quickly, and were able to adapt to that.
Rich Savage: Well, Adam, I'm sure we could do this all day, but that's all the time we have. So thank you again for your valuable time and all the insights and information you're able to provide. We really appreciate it. For our listeners, please feel free to visit redhat.com, tons of resources there, and also great information at carahsoft.com/redhat, and again, you can contact your Red Hat account representative. You can also reach out to redhat@carahsoft.comor (877) 742-8468 to talk to a Carahsoft representative about Red Hat. Thanks everybody for your time, and we'll see you next time.