Azure Red Hat OpenShift Reviews

My clients use Azure Red Hat OpenShift mainly for two purposes: as an application delivery platform and as a virtualization platform.

Azure Red Hat OpenShift is very valuable because it is a complete application delivery platform with a lot of automation that developers can utilize. It's a complete solution without building your own on top of Kubernetes.

As a consulting company, we implement Azure Red Hat OpenShift for our clients, who appreciate its integration capabilities for enhancing cloud operations. While we handle implementation, build processes, and automation, the operational responsibility lies with the customer. The service provides basic processes and support from Red Hat and Microsoft, which benefits clients by allowing them to focus on their business rather than regular operations like cluster upgrades.

I am a consultant advising customers who want to migrate from Broadcom to solutions like Red Hat OpenShift, Nutanix AHV, and VMware Essentials. My role involves keeping all options open for IT system migration.

Red Hat is a very stable product with good integration with products such as Kubernetes, and it also offers migration tools. Moving from VMware to Red Hat OpenShift requires different in-house skills. Azure Red Hat OpenShift is scalable and stable, benefiting from Red Hat's longstanding presence.

We have used it for containerized applications. Recently, we migrated six applications. One of them was Microsoft Office 365 SharePoint. And we are migrating our HVD environment. So, for that, we had prepared a separate HVD environment. HVD, in terms of, like, we call it as a Bank of America, call it as an HVD. HVD, in layman's terms, we can call it a VM.

We had almost created one for each employee during the pandemic, and we had almost more than one lakh employees. So recently, we decided, like, why should we have that much hardware utilized for all of them because nobody wants it from the developer side, and the people who didn't require it, they are rarely using the HVD, so why can't we make them temporary HVDs. So, we decided to create our resilient HVD infrastructure, and we are moving to the cloud. 

So what happens is, like, premature concept Google, there's a similar concept that we are using in our environment. That, like, a user will, whenever they need a profile or are ready to access something, their profile will be created at that time, and we have a buffer of activities that will be allocated, like, in activity will be a number. And at that time, we can allocate those ten HVD designs. As soon as, let's say, we decided to have scaling capabilities, like, out of ten, we have allocated, say, around, all of a sudden, we got a request for seven or five. So, in that case, let's say, as soon as you get two HVDs utilized out of that, it will replace another two HVDs so that you will always have a balanced count always with you.

If you compare it with Kubernetes, it has similar sorts of features. But the only thing is that you are now using open source, which is cost-saving, and that was more likely why the bank has opted and decided to continue with OpenShift as Kubernetes because of cost-saving.

So that's the reason. Because if you want to buy Google Kubernetes or some other AWS or Azure Kubernetes, that will come with a package. But that's the reason we are going to utilize that. 

And the main purpose of utilizing Azure will be the, like, we will be utilizing their computing power. 

Second, Google, we will have our governance because of the way they have their own applications like YouTube, Gmail, how they are getting secure, and how they scan the junk emails into that. So that feature and the governance features, we are going to utilize, like, those services we have taken from Google, and we will have AWS as an option as our third multi-cloud provider. Because in case we need some multi-cloud identity, in that case, let's say, some features of AWS, like Active Directory or security reasons, and those features are more secure because Microsoft comes over with their product of Active Directory and identity access management. So that helps so that instead of going for Google Cloud, I'll go for security reasons with Azure.

In similar ways, if I power, like, Microsoft is not much into databases, so we also consider the Oracle database service as an option for this one. However, we are considering that Azure is giving more resiliency in database management and records.

The secondary cost-saving is there because Amazon has been in the cloud area for more than ten years. Other partners like Google, Lenovo, and IBM have recently started moving into it, even Cisco.

Back in the years, VMware and Cisco were the core infrastructure providers for any platform; whether you were working or doing, you were preparing for your virtualization or going for the cloud. So they may have been core service providers, but they realized, okay, like, we are providing our services to the big cloud products, like Azure, AWS, and others. So they also came up with, like, why can't we leverage our technology? We could take advantage, and we could also complete the market where we can compete with them. And that's why they came up with themselves as cloud service providers. So they started late instead of. Instead, they should have started earlier, even before Amazon and others started.

We are currently using Azure Red Hat OpenShift for our pipeline management. We use Jenkins. We have some small Kubernetes apps that are currently running there. We also use it for helping with migration efforts from people that use on-prem, can't go to the cloud yet, but want to use Kubernetes. They deploy to OpenShift on-prem and once they divorce themselves of some of the monolithic apps that they have on-prem, they'll be able to easily move to a cloud provider like Azure using our OpenShift.

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.

I use Azure Red Hat OpenShift in our company to store our clients' databases and their statements and transactions that need to go through the containers.

The most valuable features of the solution are accessibility and scalability.

We use this solution for internal and external security for a banking environment. We control the user environment and develop codes.

I'm using version 4.4. It's deployed on a private cloud. We also have physical servers.

It has a feature to automatically scale up or scale down. If my application is running in peak hours, it will automatically increase.

OpenShift provides us with the flexibility and efficiency of cloud native stacks, while enabling us to meet regulatory constraints.

I had been using Azure Red Hat OpenShift for corporate integrations, trying to build and develop a digital business.

We recently put in production a new solution based on the Oracle platform. As a platform, this solution needs to integrate with legacy systems that are not appropriately adapted to the cloud-native solutions, and this is the cupping layer.

Azure Red Hat OpenShift and its integration tools provide the tools we need to integrate legacy systems with digital products in a special manner.