Let’s look a bit deeper at the relationship between Red Hat OpenShift and Kubernetes to see how they are both similar and different. As we discussed in the last video, there are many similarities between the two because OpenShift is built with Kubernetes. Native Kubernetes capabilities are also present in OpenShift. This means that OpenShift includes just about everything provided by Kubernetes, as well as additional functionality. Both are container orchestration tools, and both are open source software. Now let's look at the differences that we’ll discuss in the remainder of this module. First, OpenShift is a product, while Kubernetes is a project. Many companies have monetized Kubernetes in various ways but at the core, it is an open source project. OpenShift, however, is a product developed and supported by Red Hat, though the underlying components are also open source software. You learned about kubectl in the last module, but OpenShift has its own CLI called "oc." The oc CLI includes a copy of kubectl, so you can still run kubectl commands with oc; however, oc also includes additional OpenShift-specific objects and functionality. OpenShift comes with a web UI for performing developer and operations actions. While Kubernetes does have a dashboard, it is installed separately and it’s not as integral as the console is to OpenShift. While Kubernetes Deployment objects are still present in OpenShift, DeploymentConfig objects are OpenShift specific. These objects are based on an older Kubernetes object called ReplicationController instead of ReplicaSets. One advantage of DeploymentConfig objects is that they include triggers that drive automated deployments in response to events. This enables the buildsvcapabilities present in OpenShift, which you’ll learn about soon. Now listen to Sai Vennam from the IBM Cloud team as he explains more about the difference between Kubernetes and OpenShift. To start, we'll talk about deploying an application. So, deploying an application in Kubernetes can actually be a little bit time consuming. So first, let's assume that you have your code up on something like GitHub, so you'll pull that code to your local machine, maybe set up a container. Once you got that container you'll have to figure out where you want to actually host it, so the registry. So maybe you want to use something like Docker Hub or you want a private registry, you'll have to figure that out. One thing I want to mention, if you take advantage of Manage Kubernetes, so like Kubernetes from your favorite cloud provider, generally they have options to have a registry or a private registry directly in that experience. Next, once it's on the registry, you'll actually have to figure out your CICD story. And this is one of the things that gets complicated because there is so many different options for deploying your applications. On the OpenShift side of things on the other hand they have an opinionated approach, so all you really have to do is create an application and a project at which point OpenShift does the heavy lifting on the backend so its going to create those pipelines, it's going to create all of that automation that you need to do things like dev, test and prod for your applications. So really it makes it a lot easier and you can get started maybe using something like their Jenkins approach or source to image capabilities. But one thing I do want to mention here, you have a lot more flexibility on the Kubernetes side of things. As you don't have an opinionated prescribed way of doing this, so power users and teams that are kind of influenced by legacy architectures, Kubernetes might be more effective. For teams that really just want to be told how to get everything done and have a streamlined approach for their devops and pipeline approach, the OpenShift side of things makes things quite easy. Next, let's talk about managing your applications. So, two sides of the puzzle here, first let's start with how managing your apps looks like in Kubernetes. So you can take advantage of the default dashboards that comes with any Kubernetes distribution, but unfortunately for most operations teams it's not quite enough. So they'll have to take it a step further, and install additional dashboards. So maybe they'll use something like an ELK stack, maybe they want to use Grifani instead, maybe istio, the options are kind of endless. So essentially, you know, it's a lot of digging around to figure out the exact solution that fits their use case. On the OpenShift side of things, again there is an opinionated prescribed way of doing things. In addition, they have an awesome web console that builds on the Kubernetes APIs and makes it and comes with a lot of different capabilities for SREs and operations teams to really manage their work loads. In addition, there is prescribed and opinionated ways to do those dashboards that we talked about so they suggest an EFK stack and have different ways to integrate capabilities like Istio, if you wanted to use it, so again by taking advantage of with some of their automated installers and Ansible playbooks, managing applications is a little bit easier with the kind of caveat that you give up some of that flexibility as they do have prescribed approaches. You should now be familiar with the similarities and differences between Red Hat OpenShift and Kubernetes, including the CLI, Web UI and objects available in the system.