The OpenShift features I find most valuable are the additional ones it has provided to make life a little bit easier for people either adapting to Kubernetes or trying to be cloud-agnostic or platform agnostic. Some of those features include their GUI, which is much easier to navigate compared to an open source package. It is called Lens, which is what Kubernetes uses. The nice thing is that everything goes back to code. So if you don't really need the GUI, you can use the CLI, the code, and APIs to do the same thing, and then it shows up in the GUI. So both sides see it. That makes your life easier. Another thing is that OpenShift provides routing. Kubernetes does not provide routing, so there are other things you have to do with Kubernetes to get into your applications. In Kubernetes, when traffic goes out of a pod, it has to have its own IP address. Every service that's going out requires another IP. But with OpenShift, you don't have to deal with any of those IPs because they use NAT. It has its own network internal and that makes it a lot easier to manage those clusters on the infrastructure side because you're not worried about running out of IPs because of all the applications that get deployed. Also, how the data comes into the pod is abstracted with OpenShift. You don't get that with Kubernetes. In Kubernetes, you have to have a load balancer, like Nginx, to manage your service coming in to get to the pods. You have to set all of that up yourself in Kubernetes. OpenShift, which comes built-in, uses HAProxy. You use URL load balancing so you don't have to worry about setting up any of that. As an app developer, you don't have to reach out to infrastructure people like me to have them set it up. Also, many applications want to use SSL certificates, they want to be encrypted and you don't want to have this data open. So in Kubernetes, you have to create all these certificates and put them in there. A lot of people don't like self-signed certificates because you get the pop-ups. So that means you have to use real certificates either from your company or from something external. With OpenShift, all of that is handled by a wildcard cert. The apps are later managed by that wildcard cert. If you do want a special URL that customers see, you can also add that. But if you don't care, you just want the traffic to get to your application, the platform takes care of it. So that makes life easier for application developers. Another problem is on Kubernetes if you're using different Kubernetes providers, be it like an on-prem Kubernetes or Azure or Google or AWS, you can move the pods around in any Kubernetes, they'll work anywhere, but the storage is going to look different. As a developer, you have to develop towards that provider so that it knows which storage to use if your pod needs storage. With OpenShift, it abstracts the storage so you don't have to worry about it. As long as it's set up the same by the infrastructure people when you deploy out a pod and you say, it doesn't care if it's AWS or Azure, on-prem, or Google. That's a benefit that you get from OpenShift that you would not with Kubernetes. In addition, as your applications mature, you want to be able to take advantage of things that make life easier for developers. One of them is service mesh. Service mesh is how you're handling traffic between pods in the same Kubernetes cluster. That gets to be a problem, especially with security and networking because they really don't have exposure to that network internal to Kubernetes. So when developers want to create or add features to their product, but they don't want all the traffic to go to those new features yet, they want to slowly bleed it in, sometimes they call them blue-green type deployments, there is a lot of work that you have to do in Kubernetes to make that happen there. Depending on your applications, it can be very complicated and service mesh is not easy either, but it allows you to do that stuff a lot easier. It also handles firewalls between pods, which normally, you don't get straight out of the box. Kubernetes is very open, which allows you to do what you want without the hindrance of a lot of security stuff. But that's not the best solution for enterprises. One of the things that you can do in Kubernetes is run your pods as a user root, which is the highest level user, and that has problems. Just like on a virtual machine or a server, you don't want things to run as root because that allows security hacks to get in and it makes their life easier. However, in Kubernetes, unless you have policies in place that you create and manage, you will be running as root. In OpenShift, by default, you cannot run as root. If you have to do it, there are ways around it by service accounts and doing some other stuff and you can make that happen, but by default, it's going to block you from running as root. It also isolates all the namespaces, every namespace has its own internal IPs. In Kubernetes, you use the IPs directly from your network and assign your IPs yourself. Another thing OpenShift has is SELinux. This feature makes it even harder to manipulate the backend in order to get around things. Kubernetes, Azure, and GCP use a Linux distro like Ubuntu, or Red Hat. If you want to put that SELinux in, you can, but you have to manage it yourself. If you're patching and using something like Azure, AWS, or even Google, the control plane part of Kubernetes is managed by the vendor, but the nodes that you use to run your processes, and compute nodes, you will have to manage yourself. You will have to patch them yourself and keep on top of everything because you can't just skip releases. If something breaks, then you will need to pull in support and try to get that fixed. OpenShift takes care of all of that for you. It controls everything internally and the operating system underneath. When you do patching with it, not only does it patch Kubernetes or OpenShift, but it also patches the underlying operating system because if you're using something like CoreOS, which is a container-based operating system, it can manage it in Kubernetes and so everything is patched at the same time and Red Hat manages all the patching. It does run on every platform. It can run on bare metal, it can run on AWS, Azure, and Google. So it's not really bogged down by the underlying platform. Patching is really a single button click and everything can be updated, and if there are problems, it can roll back those updates including the changes to the underlying operating system. These are some of the things that you get with OpenShift and its Enterprise Kubernetes platform, it takes Kubernetes to the next enterprise level, things that enterprises usually want to have to succeed.
