 So just by way of introduction, my name is Peter Lautereck. I'm one of the product managers. Actually, if you know OpenShift, there's probably about 45 of my closest colleagues that manage different parts of OpenShift. I'm responsible for a couple of different things at Red Hat. One is Rev or the Red Hat virtualization, which is our traditional virtualization platform. OpenShift on Rev, which is the ability to run the brand new spanking container platform on the old infrastructure or traditional infrastructure, and then OpenShift virtualization, which is the ability to run VMs inside of OpenShift. And I'm sure everybody's wondering, really, what's the point of running VMs inside of OpenShift? So what we're gonna talk about today is why you would do that. And more specifically, we've got some really good examples of customers that are doing exactly this, right? Which is running databases in virtual machines to enhance their container applications. So OpenShift virtualization is a feature of the OpenShift platform. It doesn't have a separate SKU. It doesn't cost you anything extra. If you own OpenShift or OKE or OpenShift platform plus, you already have the ability to do this. It's an operator that you download, load it up into your OpenShift cluster. So you need bare metal, though I will talk about some cool cloud stuff coming. And what you wanna be able to do is run virtual machines and containers together, right? And what would you would call a composite application? So a couple of things that are available in OpenShift virtualization in some of the futures that we're delivering now are being able to back up and restore your virtual machines in that environment as you back up your OpenShift cluster. The other thing is that OpenShift itself has many different deployment options, right? So you can actually deploy in a large bare metal cluster with racks of servers. You can deploy in a much smaller footprint like a compact three node cluster with schedule masters. And then there's actually a single node OpenShift, which is the latest thing. And you can actually run virtual machines and databases and virtual machines on every one of those platforms. The other thing that we're now getting into, and this is kind of a new future for us and a very interesting one, which is running virtual machines in a Kubernetes cluster in a public cloud, right? So we already have OpenShift, VMs and OpenShift in AWS bare metal instances. So you can actually have an OpenShift cluster in AWS without any bare metal at all and add bare metal worker nodes that you can actually then deploy virtual machine workloads on. And we've just with 4.10, we will be also previewing tech previewing IBM bare metal in the public cloud there. And you'll actually see as other customers and partners demand other footprints, we have other cloud providers, some are the well-known global ones, like Azure who we're in conversations with and then much smaller ones that tend to be regional, pardon me. So the idea of running virtual machines in Kubernetes, as I said, is maybe not a common one or a well-known one, but the idea is actually helps you modernize your applications. But at the same time, you wanna make sure that, yes, I get all the benefits of the virtual container platform, but I still have as a virtual infrastructure admin, an idea like, hey, I need to create VMs, I need to be able to manage them, I need to be able to update them. All of those paradigms still apply. And I'm gonna show you the technology under the hood. The other thing that we can also do with these virtual machines is, as you know, OpenShift has a great story for AIML, just by itself with containers. And that lends itself to a lot of interesting use cases with OpenShift Data Hub and a lot of other cool things. But you can actually, if you have virtual machine workloads or AIML models that only run in VMs and haven't been containerized yet, you can actually still run them on that same platform and take advantage of the hardware acceleration of the GPUs in both virtual machines and containers. So over on the right here, we've got a quote, I'm not gonna read it to you, but it really is, and I'm gonna show an example in a second here, our friends over at Sahi Binden who you heard from really have embraced sort of virtual machines and OpenShift as part of their modernization strategy. And it really has a couple of benefits here. I'll talk about the technical ones later, but the other one that's also interesting is for folks that not just push running websites like Sahi Binden, but other companies and enterprises that are moving in a cloud native strategy, talent acquisition and staff retention is actually a big deal. So the ability to leverage the applications that you have in VMs and still do them on a modern container platform like OpenShift is a fairly big advantage. Down at the bottom, I'll not go into the different use cases, but we've got folks looking at using virtual machines and OpenShift in every one of these environments. And what would that look like? So I've got your traditional three tier app. So let me orient you on this slide. Time flows down the page here. So in the first row, I've got a traditional three tier app that's on a legacy application. Maybe it's your favorite hypervisor like Rev, maybe Zen server or say vSphere. I can actually bring those virtual machines, right? And this is your standard, hey, database in Linux would be MySQL, Jboss and Apache, right? And I can bring that over in Windows. It could be SQL server, .NET framework and then IIS is the front end. And you can bring those VMs directly into OpenShift and run them as VMs, they're KVM VMs. So the same technology that you would use on other Red Hat platforms. Now that you have them there, it's actually pretty cool because you have the same in-guest properties, right? The operating systems that you're using are the same. So you manage them internally the same way, but now you have all the benefits of running on a container platform, right? So the idea of infrastructure as code and being able to roll out new parts of your application and update that using things like GitOps is a very powerful message, even without making any code changes at all. So now as time flows down the page, you can go ahead and let's take the easy part. Hey, the web front end, we've got some new cool cloud stuff we wanna put on the front of this, maybe a mobile app. You can actually containerize that and still leave your middleware and your database in a virtual machine. Now the third slide here is actually the most interesting, right? Which is, there's probably a couple of people listening to the sound of my voice right now going like, you know what? Databases and containers, I'm not convinced. I'm gonna run it on my bare metal. I'm gonna run it in my virtual machine and I like it that way. And that works best for me. So you can actually stop at this point and essentially containerize and modernize everything, the front end and the middleware, and leave the database in a virtual machine if that makes sense for you, right? So this isn't really any sort of forcing of a technology choice. You can move down this path at your own pace, right? And once you get comfortable and the DBA decides, you know what? I've seen enough like SQL Server runs great inside a container, right? And we've got lots of people doing it. You can actually migrate your SQL Server database from your virtual machine into a container and migrate that over. And the very cool thing is if you set it up right and you're using things like services on the, you know, on the container side, that actually that transition is actually seamless to the application. There's no, if you're using something like a service mesh to connect everything together and services inside the cluster, that will be completely transparent to the application. So let's talk about, you guys have already heard about Sahi Bindan. I wanna talk about some of the benefits that they've seen for running databases here. It really is a very exciting customer we've had for them. They had a lot of automation that deployed into their old infrastructure. And what they were able to do is actually easily, you know, as they built this OpenShift bare metal cluster. Let me orient you here to this picture. So every server here is, this is all a single OpenShift cluster running on bare metal and it's a combination of two different vendors hardware, right? And as long as it's certified for Relate, they're good to go. The service that have these little green blobs on them are actually running OpenShift data foundation which is actually providing a storage cluster across these 40 or so servers, right? And then compute and storage are actually running in a hyper-converged fashion here on this part of the cluster. These other servers over here aren't storage nodes. They're actually handling other parts of the application and are segregated off, but they're actually still part of the whole main cluster. And then there's a load balancer that controls access to the applications here. One other thing I wanna point out, which is actually very cool is this little green box over here is actually a large legacy storage array. And what this means is they were, I didn't wanna say skeptical, but they wanted to sort of hedge their risk of like, well, what if this whole bare metal cloud thing doesn't, on-prem cloud thing doesn't work for us? We wanna have a backup plan. And it turns out that I'm not gonna name a storage vendor, but like there's no parts of the application that are stored on that storage. And when they actually deploy the next, there's actually gonna be an HA site for this. When they deploy that, that part's not gonna be there. So it's a fairly large number of VMs. There's a fair number of management challenges here, to be quite honest with you, because you're doing both things, right? You're moving to a new data center, but you're also, some of the things that you do need to learn is you're actually managing a Kubernetes cluster, right? So this isn't your traditional rev or vSphere or even Zen server. But the very cool thing that they did was the team was very focused on automation and they were quite good at that. And what they were able to do is point, the build pipeline that they had for, deploying on their old infrastructure, they updated their images and patches and things that they were gonna deploy. And they actually pointed it at this cluster, which was completely empty. And when that went, excuse me, when that those VMs got put in there, then they actually set up database and application replication to pull the data off of the old servers into the new ones, right? And now I've got a form of disaster recovery here. And then I can actually unplug that old data center and decommission it. And what they're gonna use that same exact, that same exact methodology for building a new data center in another city. So there's actually quite a few options here, right? When you talk about, hey, how do I migrate these VMs? We actually have tooling that will bring over the VM itself and bring the data in it, but that's not the only way to leverage virtual machines in this environment. So now let's talk about a slightly different use case, which is actually much more container focused, but involves databases, obviously. So this is a global telecommunications provider. I'm not able to share the name, but what they wanted to do is build, this is actually a larger environment. It's probably, it's over a hundred physical servers. And what they wanted to do is say, look, we're gonna build this new container-based application, but parts of it are not ready for containers. And the two pieces specifically were a SQL cluster, carrier grade, which is a version of MySQL that's very high-performance and highly available. And the load balancer that they had chosen, right? Containers weren't ready. So at that point, you either don't start the project or they had the option to run them, those particular pieces of the application as VMs in the same OpenShift cluster that all the new cloud native stuff was built. And the very cool thing is, is when I checked in on this lately, somebody said, oh, by the way, they're not using your product anymore. By the way, this went in probably maybe over a year ago. They said, oh, they're not running that stuff in VMs anymore. And I was like, that is super exciting because that wasn't the point to run VMs long-term over there. It's to let them get their architecture set up and prove that the architecture works and they can do the scale that they want to and build the application as they wish. It's just parts of those are running inside of VMs. And again, those are just VMs that you would run on any other infrastructure like Rev or vSphere, but it's now running inside the OpenShift cluster. And when those other vendors showed up with the functionality was running in a VM as a container, then they could switch over gracefully and not disrupt the application. So this is actually a, hey, I can actually do stuff much quicker instead of waiting for a perfect world when I have all of my stuff in containers, that might be years down the road. So this really lets you accelerate and take the benefit of the things that you already know how to do, like run a database in a virtual machine and get performance out of it. I can actually use that in a cloud native application. So there's probably a couple of skeptics on here going like, yeah, but containers are different and VMs are VMs. And, you know, I know how to tune a VM and I know how to do something. So the other interesting part I want to point out here is that part of our release criteria for OpenShift virtualization or VMs and OpenShift is a, not only a regression baseline against ourselves, but against our other products, right? So this is the way to read this is this is a relative performance chart of database workloads, SQL Server Postgres and MariaDB. And obviously they're not running them at the same time. This is a set of benchmarks that we run internally. And what you want is sort of parity here. We're like, if everything's equivalent, it'll be at zero. And in this particular case, running the database in a VM on OpenShift was a couple of percentage points faster. And in the case of SQL Server, it was like one and a half percent slower. Now, I don't want you to draw any conclusions that, oh my gosh, it's better to run it in containers. That's actually within the accept, especially for a big database benchmark like this, you know, five or 6% is within the margin of error. And like I said, this is a release criteria. If we aren't within, you know, performance parity of what customers run on other platforms, the product doesn't ship. And let's see, I think that's it for my slides. So in conclusion here, you can do a lot of very cool things. OpenShift 4.10 is going to drop in a couple of weeks and has all this new cool stuff. Thank you, thank you so much Peter. This is really helpful. And I hope this is giving our viewers some creative ideas to solve their problems.