Red Hat’s OpenShift Practice Lead, Chuck Svoboda (a market subject matter expert in the Kubernetes, Docker, and Cloud Foundry ecosystems), sat down with our Red Hat Sales Director, Rich Savage, to discuss the impact that containers are making towards IT optimization in agencies across the public sector.
Rich Savage: Thank you for joining us today. I'm Rich Savage with the Red Hat Team at Carahsoft, and we're sitting down today with Chuck Svoboda, the Lead Transformational Specialist with Red Hat to talk about the role containers play in IT modernization.
Rich Savage: Chuck, to get us started, give us your definition of containers.
Chuck Svoboda: Containers are a standardized packaging of apps, databases, whatever you could think of, that are portable, immutable, and provide isolation from each other. In a lot of ways I like to think of containers as kind of like the new-school RPM for the cloud that can really run anywhere and provides homogenous operational experience, at least on the outside.
Chuck Svoboda: One thing that's important to understand, because I think there's a lot of confusion on it, containers are not an evolution of or a replacement for VMs in a lot of cases, because the UX is so different between a VM and a container, you really need to treat them a bit differently. That's actually where I think a lot of folks get themselves into trouble, which is why I talk a lot about that. I want to make sure that we bring it up directly, but Red Hat can help you with that.
Rich Savage: In your view, what is the difference between the virtual machine experience and the container experience?
Chuck Svoboda: Well, if you've heard of the comparison of VMs to containers of pets versus cattle, is that a VM is traditionally very stateful, very persistent. Operators brag about how long their VMs stand up, whereas containers are supposed to be very ephemeral. They can spin up and spin down whenever they want with no interruption to continuity, with no interruption to service or anything like that. Let's be honest, it's a gross oversimplification but that's a big piece of it, and then so when you're building applications or services to go in a container, versus in a VM, there's a lot of operational and development concerns taken into account.
Chuck Svoboda: One great one that I always bring up is configuration specifically of end points and things like that, like hard-coated IP addresses, which is bad practice in general, but those absolutely do not fly in a containerized world. Again, there's many more that Red Hat can help you work through, but that's a huge difference, one that comes top of mind every time as I explain to a customer.
Rich Savage: What are some new and interesting facts around containers?
Chuck Svoboda: Containers have traditionally been thought of... useful for, rather, cloud-native web applications. Think of like Node.js apps or something like that, kind of greenfield development. Where we're kind of going into now is as I really kind of think about Gartner Hype Cycle, we're kind of coming out of the trough of disillusionment. We're now applying because those cloud-native apps are so few in number compared to the larger swaths of use cases such as high-performance computing applications. Applications that need to use GPU. Stateful applications and services like databases and message keys and things like that.
Chuck Svoboda: Edge computing, which is a really interesting use case for containerization, and then finally, we do actually understand that VMs will have a place in infrastructure for quite some time longer. While, containers are actually a great way to run traditional VMs. You get the management aspect or the benefits of the management aspect around single-pane glass or unified control plane for all your containers and your VMs, so just run them all the same, basically.
Rich Savage: From your experience, what is the current state of public sector IT modernization?
Chuck Svoboda: Sure. I think the simplest way I can say that is we're just scratching the surface. A lot of the conversations I'm in start with, "Hey, we want to adopt containers", which I'll be the first to tell you... I'll probably say it part of this podcast a few times that containers by themselves really don't get you anywhere unless you modernize your methods and practices around the same. I think a good swath of public sector is still just focusing on, "Hey, let's put something in a container and call it 'modernized'". There are quite a few agencies out there, particularly in DOD and some of the civilian like USCIS that are much further and understand that true modernization, not only building new applications better but modernizing existing legacy through the use of containers as a tool, is the right way to go about it.
Chuck Svoboda: I think we have not fully rounded the corner, though. There's still so much more to do and we're still a long ways about it, but some very exciting journeys. There's a lot of opportunity for agencies out there to do what they need to do to truly modernize and do things the right or new way.
Rich Savage: How can containers help with IT modernization?
Chuck Svoboda: As I said, containerization by themselves doesn't get you much without adopting new methods and practices, specifically think about agile methods and practices to modern application delivery. Just going out and buying a bunch of containers and throwing them at that, including your culture out of these organizations doesn't get you very far. However, from a technical aspect, the things like the isolation, the immutability, the homogenous development and operations experience really enables us to... or actually lowers the bar to adopting some of these methods and practices.
Chuck Svoboda: Think about like Red Hat OpenShift as a container-based application platform with all of our development and operations and opinions on top of it to move fast safely, securely in its scale. Containers are definitely an enabling implementation detail of that, and so I think at the end of the day, yes, containers are very helpful. They allow all of this to happen, but really, a developer should never see a container in a modernization experience. They should still just able to check in their code and let the platform handle the building of it, the securing of it, the testing of it, everything else that needs to be done in it in a modern CSE pipeline, and then just so happens that that all happens because of containers.
Rich Savage: Do agencies understand the distinction between modernization and containers?
Chuck Svoboda: Yeah. I think actually it's funny. As I said earlier, containers don't really matter at the end of the day. They're an implementation detail. They're a really important one, so you need to do them, but funny enough, I get brought into modernization discussions simply because they want to talk about containers, and then that opens the door for me and my friends in the industry to kind of get in there and have a real discussion about what actual modernization looks like.
Chuck Svoboda: A couple of examples, though, for instance are it was announced at Red Hat Summit a few weeks ago as Lockheed Martin is modernizing the F-22 Raptor, basing facing speed delivery to get functionality, features, capability to the actual jet, the actual weapons system from four years down to one. We're doing that with Red Hat OpenShift as an application platform, a development platform, using agile methods and practices derived from Red Hat Open Innovation Labs as well as our traditional consulting program at scale. No, we're not putting containers or even OpenShift for that matter, on the airplane yet because we're just not there yet. We're not ready to do that yet, but containers are a great way to accelerate the development and provide development guardrails for the development teams to move fast and rapidly iterate.
Chuck Svoboda: Another great example is USCIS with basically their eDocs line of business where we're actually completely modernizing and revolutionizing the way that all the documentation around immigration is being used, which is a very sticky subject right now in the America we live in. It's really cool to be able to be a part of... again, this was announced at Red Hat Summit a few weeks ago. A really cool part of providing a better way of life and a way of doing things on a very stressful situation for folks who are trying to get into our country and actually act so that's pretty neat.
Chuck Svoboda: Again, containers aren't just an implementation detail. They are kind of I think of a fuel as part of a modern application delivery lifecycle or pipeline, but they're not the reason, they're not the catalyst for it all happening. The last one I'll say example-wise is a radar system that detects ICBMs. That's a really cool use case that is really important to national security that we're leveraging Red Hat OpenShift and our consulting organization to again leverage the platform and everything to move fast, to do rapid iterations... to fully modernize and get this agency off of old, unsupportable mainframes that are just... really have nowhere to go anymore.
Rich Savage: To sum up for our listeners, why Red Hat OpenShift for public sector?
Chuck Svoboda: Given that this is public sector and there is all kinds of security and controls and accreditations and things like that we have to worry about because in public sector lives literally depend on this stuff, I like to start with security. Red Hat OpenShift runs on a battle-hardened operating system, Red Hat Enterprise Linux, and if you think about containers as a whole, containers really aren't that special. They're basically Linux kernel primitives. I've been saying it. Again, they don't really matter, but they do in terms of they need to be done right. Everything or the way that you run containers through Red Hat OpenShift inherits a lot of the security controls that are baked into Red Hat Enterprise Linux.
Chuck Svoboda: Anyone who's been looking at modernization through containers, really you can't throw a stone without hearing about a CDE or something that was exposed to some sort of exploit and there's several this year that actually came out in the past year that Red Hat OpenShift just wasn't affected because the other layers of security that we bake into RHEL that, again, OpenShift inherits, it's just not affected us. It's a basic completely moot point. Basically the exploit that happened inside of a container just couldn't break out because of the awesomeness of the defense in-depth it provided through RHEL that again OpenShift inherits.
Chuck Svoboda: Another thing to remember, too, is OpenShift is Enterprise-grade Kubernetes. Again, if you're doing containers you're probably going to do Kubernetes. The other container management platforms that have been out for the past few years just kind of don't really matter anymore. Everyone has kind of gotten bored with this now with Kubernetes, and so understanding that Kubernetes isn't an app platform by itself, it's basically incomplete. You need to do a lot of other things to make it functional for production. Things like telemetry, logging, metrics, monitoring, all of the CMCS, things like that. An even easier or a better way to do management through like a console both operationals and dev and provide an easier development operation experience.
Chuck Svoboda: Well, OpenShift comes with all of that baked in, so you're not hand rolling it, DIY-ing it, having to support it yourself on the Kubernetes platform. A long time ago, I remember... I think this was maybe not a long time ago, in IT years I guess it is, but 2016 I remember a conference it was like... I remember someone said, “If you were to roll your own platform with Kubernetes, hopefully you'd come out with something that looks OpenShift", and I still believe that's true to this day.
Chuck Svoboda: Another thing to think about, too, is that what Kubernetes is and what OpenShift is, is a gluing together of a lot of really important open source projects. Each one of those open source projects has its own lifecycle, has its own set of updates as they come out, and the management of that is really, really hard. Well, with Red Hat OpenShift and part of our trusted software supply chain that provide from an open source perspective and curation is that we take everything in the upstream, compile and package it in such a way that makes it really easy to install and also maintain both day one and day two operations so you don't have to worry about all that kind of the actuating that has to happen with running a Kubernetes-based platform.
Chuck Svoboda: Lastly, regarding kind of the operations and support is that there's someone to call if you need help. OpenShift and any other Kubernetes platform is literally like installing the cloud. Its compute, its storage, its networking, and a whole bunch of other stuff that is frigging hard and you don't want to do that on your own. No matter what anybody tells you out there, unless you're running a managed service, your data center does not look like the reference architectures for any of the upstream open source projects. Calling Red Hat, we've seen it basically all. We can absolutely get it integrated for you and help you support it.
Chuck Svoboda: Take it up a level is that by leveraging Red Hat OpenShift, you get access to our consulting organization that has decades worth of agile software development, skills built in from building software. Some of the world's trusted software for Red Hat for our customers, whomever, and bringing agile methods and practices such as Lean, XP, Scrum, Kanban, et cetera, domain-driven design, test-driven development, pairing, et cetera, and that's how you get access to it so that you can take those prescriptive CI/CD pipelines that we ship with integrated with all of the other trusted partners and IOC community to deliver applications reliably, repeatedly, rapidly, and with a good ROI.
Chuck Svoboda: Hi, my name is Chuck Svoboda. I'm a Lead Transformation Specialist at Red Hat public sector. Today I'm going to show you a demo on OpenShift 4. First of all, about my background though. I'm a developer at heart. I've been hands on a keyboard for as long as I can remember, but I've also led a lot of development teams. As such, no matter how good my methods and processes were for my dev teams, I’ve had a lot of misbehaving developers. I want to show you in this new world of containerized modern application delivery, how we can enforce good methods and practices to keep really good developers behaving and moving forward quickly to deliver a lot of awesome code. A lot of awesome apps that people really love to use.
Chuck Svoboda: One of the concepts we talk about to do this is the trusted software supply chain. What is that? Well that is taking trusted bits from supported, upstream, open source or whatever else is out there. Assembling those bits and adding in whatever your custom code is for, to implement requirements that produces your finished code in a safe and secure and fast way. This is something that is not necessarily a new concept, but it's just the technology and the methods and processes around the technology that are so ubiquitous that it's accessible by really, anyone out there.
Chuck Svoboda: Commercial, private, government agency, what have you. This software, trusted software supply chain, if we look at the actual definition is the enforced sequence of processes involved in the development and deployment of software. Developing awesome code and deploying it in a modern way. It looks like this. If you look over on the far left, you see we start with using agile methods or agile practices such as domain driven design to build an actionable backlog of things, of requirements rather, that developers can code against.
Chuck Svoboda: We use modern development environment using things like GitHub or GitLab and a modern IDE (Integrated Development Environment) called Che, which I'll show you here in a minute. Pulling from trusted bits from a modern artifact repo such as Nexus, Quay, Artifacts or whatever else. You're then enforcing test-driven development through automated unit testing through tools such as Cucumber, Arquillian, JUnit, whatever you need. Whatever works best rather, for your use case. That is immediately followed by code quality analysis and review scans, using things like SonarQube and Fortify.
Chuck Svoboda: That rolls right into the security scan using things like a Twistlock, nCore, OpenSCAP, whatever else. UAT, or sorry, integration test, QA, UAT, et cetera. Each one of these phases produces enough metadata to either automate or get a rapid ATO or both, which is really awesome. Because each of these stages are guaranteed to happen, everything is produced then becomes yet another trusted for reuse and your trusted code repo. Because how often do, especially in the government, do we do something more than once? Because we either don't trust or know about what the other guy has done.
Chuck Svoboda: All right, so let's begin. Here we are. We see OpenShift 4 which Red Hat just dropped this month here in May, which is a totally awesome new release of OpenShift. A whole bunch of cool automated operations, development, abstracts and et cetera. We're building applications in something we call Eclipse Che, which is web-based Eclipse. Fully centralized and standardized by alpha developers to ensure that your standard developers have everything they need and provided to them, ready to go. So we're even shifting farther to the left, the full development experience. Because no developer, including this guy likes installing Maven, so why can't we just provide something?
Chuck Svoboda: We want to make this conversation completely extinct. Let's say here, here's my IDE. I got to change the title. We'll say it's Chuck's Awesome OpenShift Demo Task. I'm going to do a little git-commit here. To show you how completely real this is, I'm going to leave a completely fake comment. I'm going to commit that puppy. Now I need to open up a terminal here to actually do a git-push. Okay. I now push my code, and we can look in the Jenkins a build is now kicked off. This will take, I don't know, a few minutes or so, but what's going on is actually pulling down, it's probably a build phase, all the trusted bids from Nexus. The JDK, the JRE.
Chuck Svoboda: The stuff that has already been set up for me as a developer so I don't have to go down from the world-wide-web in Git, I don't have to worry about an app server or anything else. By the way, a little thing about containers. We talk about containers a lot in the market, as you'll see throughout these initial phases here, or stages here, the container does not even get built until the application will say, "Hey, this thing is safe and ready to go." Which is really awesome. Go to the jeopardy music while this build happens. All right, so this is going to take a little bit.
Chuck Svoboda: Okay. So what just happened? The application was built with trusted bits. It was tested. Some code analysis happened. One of the things that happened, and part of that code analysis was a code cover scan to ensure that whatever was written was taught and covered with enough unit tests to validate that what we built is what should go out. Then finally, we hit a manual stage gate that says, "Hey dev manager, check to make sure that developer was behaving." I'll put on my dev manager hat here. Back here because we're hosting SonarQube to enforce, or to do the code quality scan. I'll bring up SonarQube to look and see what happened. I can see here the project, it failed. Immediately I know something isn't right, this developer misbehaved.
Chuck Svoboda: I'm now going to kick back and say, "Hey, abort this. Hey developer, you need to figure out what went wrong and you need to fix your code." Developer gets an alert, developer goes back to their IDE. The developer knows because a part of that alert says, "Hey, there was a code quality issue, specifically dealing with code coverage." We will now update or add a unit test. Well, how convenient. There's an add, ignore annotation here so I bet you if I comment that out, this is a little bit of theater by the way, for demo purposes, if I comment that out now we will increase our code coverage. Again, add another VS comment because I'm sure you guys don't want to send me type. I need to know the terminal open here and git-push. Another build goes, gets kicked off.
Chuck Svoboda: One of the things I do want to show is remember, because we're enforcing all these things, we want to make sure folks know that these things can be reused. Whatever comes out as pipeline is in fact something for reuse. At the end of this thing, if everything goes right at the end of this CI/CD pipeline, we should have something populated in here in our Nexus repository for reuse. We're keeping bad code out so no one else can get it. All right, now look at that. The test phase failed. Now this is really important. It wasn't that the demo failed, this was actually supposed to happen. I implemented it in a unit test, which means more of my code. I already increased my code coverage, which means that more of my code was actually tested.
Chuck Svoboda: Which means it detected a defect that was always already there. It was already there. It was there in the last run. Had I not had that code coverage quality gate as part of my CI/CD pipeline, a defect would have escaped. Once that defect escapes, now we're talking about actual change failure rate increasing, which as we know in terms of tracking that dev ops metric, it's really important not to let it get too high. This happened. I now, as a developer have immediate feedback that I need to fix my code. Go back to my IDE and I'm going to go to where I need to fix the code. Again, a little bit of theater here because I don't think you guys want to see me do some real time debugging. How convenient. There's some code, comment it out. Let's go ahead and uncomment that.
Chuck Svoboda: Again, I'll do another git-commit. Bad comment. Which I suppose we could probably enforce, and open up another terminal. Now, when I do git-push yet another build will happen. This unit test or the unit test phase should in fact pass. Which means that I'll again have to have another interrogation of, do I have enough code coverage? Now we're at that same promote to dev manual stage gate for review that we hit before. Before I can approve it, again I'll put on my dev manager hat. I'll go back in and I'll check. Look. Quality gate passed. We see the code coverage increase. We see code swells increase as well, which means we're going down in defects so what we're going to do now is say, "Hey, this thing is great so I'm going to go out and promote this."
Chuck Svoboda: Now here's where a little bit of the magic happens behind the scenes in OpenShift is that we take that code that was built, we smather it onto what we call builder image. This is a JBoss EAP application. This has a hardened rate version of JBoss EAP that has an entry point for the application. We enter it into the builder image, configure it, and then we start to point it out. If I go back to OpenShift here, we can see in our development project, we're now getting a full deployment happening here. Now, this will take a few minutes to come up. I don't want to sit around and have you guys wait. I'll show you another project because we're also going to go to staging. Right here where you see nothing.
Chuck Svoboda: I should have yet another stage gate that I need to do approval of. All right. We just hit another manual stage gate review which will be part of deploying this application to staging for UAT. I'll go back into OpenShift here and I'll show you that in our staging environment, we still don't have any workloads going on. There's no pause, nothing like that. What I will do is go back into Jenkins and I will approve this. I promote it after I tested and probably I guess I should have showed that is, showed our application, which is here. It's up, it's running and says Chuck's Awesome Test, top here. If we go over to staging, we now see another container being created. We're creating a running container out of the container image that was originally in dev.
Chuck Svoboda: Now as this moves forward back in the CI/CD pipeline, we went all the way to archival. That was just the bits that were built at the very beginning. If I refresh here, hopefully if enough junior sales guys have been sacrificed to demigods, we should see something in here. This is actually the JBoss EAP application that I built. Again, my name is Chuck Svoboda from Red Hat. I really appreciate you sitting with me watching me, kind of stumble through a demo here. I hope you got a lot out of it and really understand that you want to have these prescriptive development guardrails on top of OpenShift, on top of any app platform that you may be looking at today so that again, you can move really quickly, safely. Thank you.
IT Optimization Infographic
August 13, 2019
Discover how Red Hat helps agencies optimize their current infrastructure and frees teams to focus more on initiatives, not day-to-day maintenance...
How Containers Drive Application Modernization in the Public Sector
July 25, 2019
How are Containers fueling transformation in the public sector?...
Red Hat OpenShift Container Platform
July 25, 2019
Built by open source leaders, Red Hat® OpenShift® is a leading enterprise Kubernetes platform: a security-focused, consistent foundation to deliver applications anywhere, with streamlined developer workflows to get to market faster...
What are Linux Containers?
July 25, 2019
IT delivers thousands of applications to meet the needs of your business. Learn how to package applications and their necessary components with Linux® containers. Developers can choose the environments and tools that best fit their projects, and operations teams can deliver applications anywhere, in a consistent way...
What can you do with Containers?
July 25, 2019
Whether you call it DevOps or DevSecOps, one thing is certain: security has changed in the age of container-based, continuously delivered applications...