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.
One of the things to notice is that this product can be expensive.
Another thing is that OpenShift has its own CLI, it has features in it that you don't have under normal Kubernetes. So if you're just a plain Kubernetes developer, you either don't know about these other features and you don't take advantage of them so you're basically treating it like a normal Kubernetes or there's a slight learning curve as you start to learn how the new CLIs work, the other options that are not available in Kubernetes. There is a learning curve; it's not high, but it's still there. That's another negative against OpenShift.
If you're purchasing OpenShift on their OpenShift container platform, you will have to manage the master nodes. If you are using Kubernetes in AWS, Google, and Azure, you don't manage master nodes. It's not really a big deal. It's all part of the patching in OpenShift. People will start to say, "Well, I don't want to manage the masters." But I think if they actually see the process of patching an OpenShift, they would say, "Okay, it's not even worth arguing because it's so simple." Alternatively, the main three cloud vendors can provide OpenShift as a service.
I have been using this solution since 2016, so six years.
I've been using OpenShift since 2016, and I've been in production since 2017, both at Kohl's department stores and at Foot Locker. I have yet to see a production problem due to OpenShift issues. In other words, where we lost money. I've seen UI patch issues and we have had to get the patch fixed. But we have not had a large outage where we considered burning Red Hat down because their product isn't doing what it's supposed to do.
I had problems with scalability on-prem with VMware, but not recently. This was years ago, but that's been corrected. I haven't had any issues recently. We do use scale sets. We are doing auto-scaling, meaning that if the load increases, it scales up and when it doesn't, it scales back down. That works fine. And I do have tests to run to verify that it works and I have not had any issues with that.
Currently, there are around three dozen people using this solution with plans to expand.
I have had many encounters with their technical support team including enhancement requests, feature enchantments, or fixes. I even supplied Red Hat with RFPs.
I would rate their technical support a six, on a scale from one to 10, with one being the worst and 10 being the best. The reason for this rating is that when I open a new support case, it normally gets assigned to someone in Asia or a European time zone. This only delays responses and I normally request the case be assigned to my region so I can work directly during my working hours.
Previously, we used plain open-source Kubernetes, and currently, we use Azure’s AKS. We started to use Openshift additionally in the last few years.
We are interested in the enterprise capabilities and the ability to migrate your application between different platforms without having to deal with IP addresses, certificates, storage backends, and the security side of it.
I have had a lot of experience with the initial setup of this solution and got an award from Red Hat themselves. Back when they didn't have an automated install of OpenShift, you had to do everything manually; you had to set up all the VMs and run certain scripts. And over a course of a year, I was working with a few other people and Red Hat too onsite to develop an automated way, this was in Google Cloud Platform, to deploy OpenShift and on VMware. We used Ansible mainly to develop this. And I know everything from manually deploying OpenShift. I started to use the solution with the 3.4. release. That was in 2016 and that was all manual to the current 4.11. And I'm just doing the fully automated install and I've done it for both VMware and Google.
A basic OpenShift cluster takes about an hour to implement. This includes deploying three master nodes, which is usually a minimum for anybody, and then three worker nodes on their automated process in Azure.
In terms of complexity, there are different ways to do it. So it can be more complex depending on your environment. Our implementation is only slightly complex because we do use our own networks in Azure. We can't use Microsoft's network. However, there is a single file, a config file, it's a YAML file and in there, they have a template and you put in the variables that you have in there for us. You answer one flat file, and then you just run a single command, and that's it. It picks up that file and deploys and then you just sit back and wait for it to get finished. I did the implementation myself.
We saw a return on investment at my previous company, Kohl's. Everything went to OpenShift; we decreased our data centers and tried to move everything into the cloud. We used OpenShift to do that so they definitely got a return on their investment. Foot Locker has yet to materialize the use of OpenShift and that's something I'm still working on. We haven't had it that long. There's been a lot of changes going on here. I think the changes are going to facilitate possibly using OpenShift as a platform because of some of the decisions that are trying to be made. But I can't predict the future so I don't know. So I would say at this point, Foot Locker has not seen the ROI but that's not due to the product, that's due to the user, and that's due to us.
When it comes to pricing, I would say Red Hat has a lot of flexibility. You can work with them and they are very flexible on pricing. Especially if you're new at it, they're extremely aggressive to let you try the product and they bring their prices way down. The one problem with that can be – and something a lot of companies worry about – that if you get it really cheap, they will nail you two years down the road because you can't get rid of it easily and it can get very expensive.
I have not seen that in the two companies I've worked for with OpenShift. For us, the price has gone up because we used it more but they didn't kill us on the pricing. So I think they're quite flexible on their pricing and they're competitive and they know you can choose other vendors to do your Kubernetes with besides OpenShift. So I would say to other people that are looking at getting it: be aggressive on the pricing and do your homework, see what else it would cost to you somewhere else, and then hammer that salesperson to get you the best price.
One piece of advice I would give others is don't think OpenShift is just Kubernetes deployed by Red Hat. Look into it more and find out more about what the differences are. If your strategy is to be a multi-cloud or hybrid type cloud environment, then you seriously need to look at how you're going to handle the full stack of Kubernetes, including all the options and support all that without having to do it yourself because that just adds a lot more work to teams like cloud engineering, which I manage. If you don't want to take on all that extra effort, let the vendor take it. They've got a very good product that's been out there for a very long time. Some of the largest companies in the world are using OpenShift and there's a reason why they're doing it. So I would say do your homework; don't just blow the solution off as another Kubernetes that Red Hat charges money for.
