 My name is Rushal Sharma, I work at Red Hat, as you can see here, and I am a technical engineer on the OpenShift container platform. So let's take a sneak preview of what's to come, because this is a developer preview. I'll be just showing you guys what's to come in the upcoming iteration of OpenShift container platform. And before that, let me just show you what OpenShift is and why you should use OpenShift if you are a developer. So why OpenShift? So these days, if you are working in a big company and you have a lot of ideas going on in your mind, and you want to streamline your app and development and the delivery process, usually what happens is when you go out in the market with an idea, somebody is also working on it, and to expedite the competition and to be in the front line, you need to launch your application pretty faster than the other people are doing, right, so that you can stay ahead of the competition all the time. Here at Red Hat, we are giving you a P-A-A-S, which is the platform as a service hybrid cloud solution to implement your next big idea pretty quickly. You can speed up the development and delivery process, and as a result of it, the cost of the development and delivery is reduced very significantly. So let's take a look at the OpenShift architecture. I hope you guys know what Red Hat Enterprise Linux is. If not, let me just tell you. So Red Hat Enterprise Linux is an enterprise Linux solution from the company Red Hat. We are in the market from a long time now, since the beginning of early 90s, and most of the 90 percent of the Fortune 500 companies are our client, because they trust us with the software. And we are delivering our micro-services and containerized application over our hybrid cloud, which is OpenShift. Now how OpenShift works? So at the bottom, we have the layer of our operating system. It can be a Red Hat Enterprise Linux or an enterprise container host, which we will talk about in the next slides. On top of this layer, we have our container orchestration management. So what is a container orchestration management? If you are running a lot of micro-services in your environment, and if you want to manage them significantly and easily, you need to have an orchestration tool. Although Docker provides an orchestration tool, but Kubernetes, as you know it, it's a much better orchestration tool than any other in the market. And why? Because it's developed by some of the greatest minds, and Red Hat is also contributing to the Kubernetes open source project. On top of this layer, we have the application lifecycle management layer, where you can build, automate, deploy, where you can automate the build, automate the deployment, and you can also integrate it with your CI CD tools. And on top of it, you have your containers running. You can run any container on it, whatever you feel like. Now when I say Kubernetes, so OpenShift is 10 times Kubernetes, because we have added a lot of layers to Kubernetes, which will help you create and deploy your applications much faster. Red Hat is the second most significant contributor to the Kubernetes project. According to Stack Electrics, an analytics engine that tracks the engagement on GitHub, Red Hat's contribution is at 14% and it's growing. Now we have a very new and easy installation method for this hybrid cloud environment. Earlier you had to create a lot of bulky playbooks and, you know, configure them, which was a big hassle for a lot of developers. So we have toned down that process, which I'll show you how easy it is to install an entire hybrid cloud solution in your environment with just a single command. Now at Red Hat, we have the culmination of some of the best DevOps tools in the market. And they are both certified by Red Hat and our partners. Now DevOps, when I say DevOps, DevOps is development and operations culminated together in a single package. So whether you are a Node.js developer or a Ruby developer or a Python developer, you need to integrate it with your operations. For example, Kubernetes or Ansible or any other operations model which you like. So at OpenShift, you get a one-stop shop for everything DevOps. What OpenShift does is it's just letting the developer what they do best, which is code. Now this is the OpenShift timeline. We launched OpenShift in 2012 and then we started improving on it, contributing to it and a lot of our partners started contributing to it with us. Right now we are here at 2019. Now when I say OpenShift 4, OpenShift 4 as I earlier mentioned in the beginning, it's still in developer preview. So there are a lot of things which are subject to change here in this presentation as well. And I'm going to show you how the console looks like and what are the new features in the console as well. We have changed everything to the core and speaking of core, the new container OS will be the CoreOS, the Red Hat Enterprise Linux CoreOS. Now why CoreOS? So CoreOS is the latest OS that Red Hat has acquired to run containers on it. It is completely optimized for containers. If you need to upgrade CoreOS, you can do it pretty easily. And even if you run into some errors during the upgrade process and you reboot your server and let's just say it's not coming up, you can simply roll back to the previous version very easily and you can have the tracks and logs of your upgrades on your CoreOS. Right? So what are the major changes? Podman. Earlier the container runtime that we were using was Docker. But now we have replaced it with Podman. Why? Because one of the most important reasons we did is you can run your containers without being a root user on your OS. Because it really exposes the security on it. So in 2014, there was a Docker shocker. So what was it? It was a malicious container which was able to access the host file systems. Now it is a very huge security thread. Because if you are running your containers from root, you are exposing your system to a user which is not entitled to be root. And that is being replaced with Podman now. In Podman, it uses the user namespaces and the support is integrated in CoreOS for this. Monitoring changes. Earlier in the 3.x versions, we had Hocular, Cassandra and Heapster as our monitoring tools. And in 4.x, everything is completely replaced by Prometheus. We have decommissioned these three tools and Prometheus will be completely supported from 4.x. Hosts and containers. Atomic host. So previously, we were using Atomic host which is now replaced by CoreOS as I mentioned earlier. Container runtimes. Previously, we were using Docker. And as I mentioned earlier, Docker is not that safe. Because see, cryo and Podman, these will be the container runtimes that we will be using now. Because Red Hat has certified it and Red Hat is giving support. If Red Hat is giving you support on Podman, then you can trust us. Because Red Hat is one of the most trusted Linux distros in the world. Ease of upgrade. So our prime objective in our next version of OpenShift is ease of upgrade and installation as well. Earlier we had the blue-green installation method. Now we have the ease of upgrade. Ease of upgrade is the core value for our next iteration. Now, let's talk a minute about Rel8. So because Rel8 is not yet out and OpenShift is also not yet out, I'll just say a couple of things about Rel8. So Rel8 is also optimized for containerization just like CoreOS. So in the near future, if you like to use Rel8, you can also use it with OpenShift. Faster deployments is the core value for our next iteration. And new and improved console, which I'm going to show you guys in just a minute. So let's just take a look at the new installation method. So previously when our customers used to install OpenShift, there was a very long list of prerequisites. What they had to do is they had to create a very long playbook, edit it and then run that playbook using Ansible. Now all you need to do is just run this command. So it's failing because I've already installed it, but it's as easy as it looks like. You just have to run this command and voila, you have a new cluster running in your environment, wherever you like. So let's take a look at the new console. So this is the latest console that we have implemented. We have completely changed it from the previous versions and added a lot of new features to it, such as live streaming of events. So if you're using either Kubernetes or OpenShift, there's an option to check the events which are going on in your pod. So if you want to check it on the web console live, let's just see if we can do it right now, because we have time. So this is my project. And under this project, I have this pod running, which is my ETCD pod. And these are the events. So as of now, there are no events. So there are a couple of events, the beauty of global upper preview. So let's just change it a little. Let's just increase the pod count to two. And let's see if we can see that in the events. So this live streaming is the... So it's showing there, right here. So this is the live streaming. So if you are scaling your application, you can see the events in real time here. Creating new projects, creating new applications, it's as easy as it gets. You just have to type in the name, then the display name, and then just click on Create. So we have this test catalog right now, but we will be adding a lot of new applications and a lot of new... We'll be increasing the catalog in the release, obviously. So let's just launch Apache Web Server. Create application. We'll give it a name, a sample. Create. So it's done, I guess. So there are a couple of things which need improvement, obviously, with this developer preview. This is how easy it is to create a new application. And then you can just hand over this... You can simply just hand this over to your developer. He can start working. So you are eliminating a huge silo here. Earlier, when you had a lot of developers from different programming languages, without microservices and without containers, you have to provision a fully blown virtual machine from either ESXi or AWS or Google Cloud or whatever. And you have to hand over that entire machine to your developer. Here, sometimes he used to run into a lot of dependency issues. Now, that dependency has been completely removed from here. So the developer is completely hassle-free to code. So this is the beauty of OpenShift. So this is the little bit of a sneak preview because the GA is, I believe, in the couple of months. Next couple of months, I'm not sure. So just keep an eye on Reddit's official website. And you can always send us a mail to connect. So thank you. And any questions? Yeah. I have two. Hi. So it wasn't clear to me if OpenShift 4 is only going to run on CoreOS or will also run in Rail 8. And also you showed the command to create a cluster but surely there must be a way to configure what that command does. Yes. Can you show that as well? Yeah. See, you'll be able to install, yeah, right now you'll be able to install OpenShift on CoreOS. But you will also be able to install it on other Linux distros like REL in the near future. But it's not confirmed yet. It's because it's still under developer preview. So you'll have to just keep an eye for that one. So as of now, we are moving towards CoreOS. Why? See, because CoreOS is a much better option than REL for containerized environments and for this hybrid cloud because CoreOS is completely optimized to run OpenShift on it. So it will be very easier for you if you are going for upgrades because most of our customers, some of our customers, when they upgrade their clusters, sometimes they run into some difficulties there. And right now in the 3.x version, it's a little bit difficult to roll back all the actions. But in the next CoreOS model, if you are upgrading your OpenShift version from, let's just say, 4.1 to 4.2, and if you run into an issue there, it will be much easier to roll back so that it will decrease your production downtime. So that's why we are moving more towards CoreOS. Let's... Perhaps before we take a follow-up. Any other questions in the room? Yes, sir. I'm afraid that I cannot show you that now because it's still under developer preview. So you'll have to wait a couple of months for that. Let's take follow-ups offline, please. What would be a great strategy when we already have OpenShift cluster right now is going to be to recreate a new cluster based on CoreOS and after migrate all the workload? Because I don't think so. You're going to have like a migration... So your question is, if there's going to be any upgradation from 3 to 4, that's what you're asking, right? So we're still under developer development preview and we are planning how to do that right now. So the correct answer for that you can get, I think, whenever the GA is released. So it's just a sneak peek of what's to come. So still there are a lot of things which are under reps and under development. That's it. You can probably sneak in one more if there's anyone wishing to ask. No? In that case, thank you very much.