Red Hat OpenShift Reviews

I have been using Red Hat OpenShift for more than six years.

I implement Red Hat OpenShift for our customers as we are a service provider, and we implement it in our cloud. We provide it as a service for our customers, and we deploy some of the applications that we have implemented in our company and for my personal use.

I deployed and developed an audit application which runs all the compliance requirements for a company, including multiple platforms and multiple standards such as ISO and others, and NCA for Saudi Arabia, and any other standard can work on it. This is one example. I also created a personal application for a t-shirt integrated with AI where we can create an image and print it on a shirt and ship it to the customer. I implemented another application for waste management, which was totally developed and deployed by myself for my personal use and the waste management for one of our customers. Additionally, I had another application deployed for one of our customers, where my role was to deploy Red Hat OpenShift and to make sure their application is deployed and available. This is for bill invoicing and financial operations. For one of the hospitals, our customer, I deployed the application for monitoring diabetes patients. My role there was to deploy it and to make the application available, providing all the requirements, ingress, configuration, storage, and other things. These are examples of what I have done.

Red Hat OpenShift by default is secure, more than native Kubernetes, as it has a limitation for the run as. The container by default does not run as root; this is one of the examples. The integration with ACS allows centralized policy deployment and enforcement, alongside great observability and monitoring. Red Hat OpenShift is actually enterprise-grade Kubernetes with all the accessories and main features.

One of the best features of Red Hat OpenShift is that it has the catalog, the application catalog, and the operator hub, which allows us to deploy things easily and straightforward without going into a lot of hassles. This is one of the main things, in addition to having integration with ACM and ACS, where we can have the ability to manage multiple clusters and to secure them, deploy them, manage them, run GitOps and day-two operations, as well as upgrades and other functionality which is made easy using these tools. Red Hat OpenShift also provides virtualization capabilities, and I am currently working with Zain to make a project where we will convert F5 appliances to virtual machines and to manage them through Red Hat virtualization, OVE. Red Hat OpenShift is a unique platform because it provides the features for both worlds, containerization, and VMs at the same time, requiring you to learn one skillset in order to manage all of this at the same time.

In the beginning, our cloud depended only on virtual machines, so I introduced this to our management to start to work with microservices and with containerization. This was adapted in our cloud, providing us the capability to sell more of these features and to reduce the hardware requirement by about thirty percent, following the trends of using containerization for all modern applications. In addition, it reduced the time to develop and to deploy a new application; all we need is using Jenkins for CI/CD. Once we commit any code, it gets triggered, and it will implement the new container in a very flexible and easy way, within seconds. This decreased the time to market and increased agility, allowing us to capture new opportunities very fast.

There is perhaps one thing about the deployment of Red Hat OpenShift. Currently, there are two new ways to deploy Red Hat OpenShift, which are easier with assisted deployment and agent-based deployment. However, previously it needed a lot of requirements on the infrastructure side if we are using UPI, user-provided infrastructure. If the deployment of Red Hat OpenShift itself can be easier and more flexible, it would be great.

I have been using Red Hat OpenShift for more than six years.

Red Hat OpenShift is stable.

It is great. Red Hat OpenShift can scale to thousands of nodes, allowing multiple clusters to be managed in different geolocations and managed by centralized advanced cluster management, ACM.

Regarding scalability, Red Hat OpenShift has a lot of scalability capability, including about two thousand machines in one cluster and multiple cluster management, centralized management through ACM and ACS, which provides a very secure way to manage centrally all the features and to enforce policies.

In the beginning, our cloud depended only on virtual machines, so I introduced this to our management to start to work with microservices and with containerization. This was adapted in our cloud, providing us the capability to sell more of these features and to reduce the hardware requirement by about thirty percent, following the trends of using containerization for all modern applications.

The response time for customer support is excellent, and they go deep and can resolve things easily.

The documentation and support that we get from Red Hat are very sufficient, and this differentiates between enterprise-grade Kubernetes and native Kubernetes or perhaps Kubernetes from other vendors.

We used native Kubernetes before Red Hat OpenShift, actually, deploying it through kubeadm. The issue with Kubernetes is that it is just the engine; Red Hat has all the requirements to give you a complete solution. Red Hat OpenShift provides the complete ecosystem, all the integrations, and the tools which I mentioned before, which are already integrated and easy to be used. You do not need to grab open-source solutions for storage or other things, and you do not have to do a lot of customization, needing to comply with each version. Red Hat OpenShift is tested and vetted, making things easier to be deployed, supported, and managed, and it is more trustworthy.

There is perhaps one thing about the deployment of Red Hat OpenShift. Currently, there are two new ways to deploy Red Hat OpenShift, which are easier with assisted deployment and agent-based deployment.

We are a partner with Red Hat; we sell their services and licenses, and we do the implementation ourselves.

We did not measure our return on investment in a very accurate way, but as I mentioned, we could decrease the time needed to deploy any application, enabling us to capture new opportunities faster, go to market faster, and maintain the availability and security of all our applications.

We work with Red Hat or our distributor in Saudi Arabia. We send our requirements as part of the RFP describing what we need, and we get the pricing from our distributor. There is an easy way to price the subscription of the support per CPU, per VM, so it is easy to be priced, but we depend on an official quote usually from our distributor.

Red Hat OpenShift by default is secure, more than native Kubernetes, as it has a limitation for the run as. The container by default does not run as root; this is one of the examples. The integration with ACS allows centralized policy deployment and enforcement, alongside great observability and monitoring. Red Hat OpenShift is actually enterprise-grade Kubernetes with all the accessories and main features.

Our go-to-market and our deployment for any application, the time is reduced perhaps by eight times. It is very fast because you have consistency for all deployed containers; it is not like a virtual machine where you have to deploy individually for each virtual machine or you have to copy code here and there. It takes seconds because the containers spin out very fast; they are very lightweight. The things that we used to do in days, now take a couple of minutes to be done. So, that is approximately the number—mostly it is reduced by eight.

We are providing our cloud to our customers, so we are a service provider. We deploy Red Hat OpenShift in our cloud and host customers' applications through it. Some of our customers prefer Red Hat OpenShift on Azure or on AWS, so we deploy it there when needed, but our main deliverable is through our cloud.

We have our own cloud provided by our company, making us a local cloud provider. We are not a hyper integrator, nor a hyper-scaler. We provide it through our cloud and deployed a couple of customers on Azure; this is what I recall.

I would advise others looking into using Red Hat OpenShift to take the step and to go fast into it because it will save them a lot of money and provide them with all the features, flexibility, security, and others. I give this product a rating of ten out of ten.

My main use case for Red Hat OpenShift is that we had several security tools that we deployed to Red Hat OpenShift platform, specifically when we were migrating our applications from monolithic architecture to microservices, and our OpenShift platform was using some of the AWS VMs as master and worker nodes, so it was completely on AWS, and we actually set it up from scratch, setting up those projects to be used for our applications and then deploying them with Red Hat OpenShift version 4, which we started using five years back, as it was the latest at that point in time, and then we continued to operate and run our applications there.

A quick, specific example of an application I deployed on Red Hat OpenShift is a banking-based application which we moved from a monolithic architecture to a microservices architecture, and we completely deployed it end-to-end, split into 10 plus microservices, and then it was deployed to Red Hat OpenShift platform 4.

The best features that Red Hat OpenShift offers in my experience include being a pre-assembled product where Red Hat actually makes choices for you, which for example, as a CloudOps Engineer, means I don't have to explicitly go into CLI because the web-based UI is simple and helpful for debugging, and they've integrated the logging of the application within Red Hat OpenShift. I really appreciate the automated updates, built-in observability comes with pre-configured Prometheus and Grafana stack for monitoring our cluster health, and the native tooling it has such as Red Hat OpenShift GitOps, which is a Red Hat supported Argo CD, and the integration into clusters are based on role-based access control with security by default, where Red Hat OpenShift is quite secure out of the box, having those strict permissions and using Security Context Constraints, and especially the immutable OS and Red Hat OpenShift virtualization, which is something that is really helpful.

Red Hat OpenShift has positively impacted my organization primarily through observability, as for us, application uptime matters a lot when providing public-facing products consumed by customers, and hence, we're using that to keep refining our application and products through observability metrics and keeping pace with market trends, as we promised 99.99% uptime to our customers, and the observability in Red Hat OpenShift is really helping us a lot with that.

Areas where Red Hat OpenShift can be improved include the licensing being a bit complex and maybe expensive, as that is something in the hands of the organization's higher management, especially when those licensing agreements are done, and I think Red Hat OpenShift is quite resource-heavy because the control plane and default monitoring stack consume significant resources, meaning for small clusters, a large percentage of compute goes just to running Red Hat OpenShift itself, not our apps.

I have been using Red Hat OpenShift for close to six years across those different organizations.

Red Hat OpenShift is stable in my experience.

Red Hat OpenShift's scalability is really good.

Customer support is really good because so far in our case, we have always received a prompt response, and they have been really helpful to us. I would rate the customer support a 10 out of 10.

Positive

We did not use any other solution before Red Hat OpenShift.

Red Hat OpenShift is deployed in my organization on AWS.

We have saved a lot of time with Red Hat OpenShift.

My experience with pricing, setup cost, and licensing would suggest that it was more into a high cost, but then again, I'm an engineer, so this is taken care of by the higher management, and I don't have any definitive answer.

We did not evaluate any other solution before choosing Red Hat OpenShift because we wanted to use a licensed product for Kubernetes that has enterprise support.

I would rate Red Hat OpenShift a 9 out of 10 overall. I choose a nine for Red Hat OpenShift because for such kind of tools, there is always room for improvement, as I already mentioned the things that can be improved in my previous answer. I would suggest that it's quite better if you're using Red Hat OpenShift for an enterprise solution, as it's really better to have the enterprise support which Red Hat OpenShift offers, and it's easy to use for Kubernetes-based applications.

My main use case for Red Hat OpenShift is that in our organization, we are going into a modernization of our application where we are moving away from our traditional application approach. Now we are moving forward.

A specific example of how I'm using Red Hat OpenShift in my organization is that we have around 18 clusters and for now, we are maintaining around 16 applications in Red Hat OpenShift.

Day-to-day, I'm using Red Hat OpenShift as we are moving into adding applications to containers, using it regularly on troubleshooting issues, whatever the customer encounters.

The best feature Red Hat OpenShift offers in my experience is the Service Mesh. The recent update of the Service Mesh is a very good component of Red Hat.

Red Hat OpenShift has positively impacted my organization as the main focus was to reduce the physical servers we have in our warehouse. That helped us a lot in moving into containerization and handling the application.

After moving to Red Hat OpenShift, I noticed we moved around 16 applications, and each application used to use around six to eight servers. So, roughly around 110-150 servers have been reduced right now.

Red Hat OpenShift can be improved as I commonly use the CLI console, but I have not explored much on the graphical console. I have been working on the command line mostly and not explored much on the console. I feel like it might be more advanced and useful for newcomers who are not familiar with the command line.

Further needed improvements in Red Hat OpenShift include that getting the providers will be a little bit tricky in the console. When I tried to add searching on providers, that was a little bit tricky.

I have been using Red Hat OpenShift for one year.

In my experience, Red Hat OpenShift is very stable.

Scalability-wise, Red Hat OpenShift is pretty much good, as it is one click where we can scale any of the applications.

The customer support of Red Hat OpenShift is good as I have reached out to them a couple of times. The customer support was easy. We have a premium membership with the Red Hat team, so it is very convenient and they get back to us as soon as we require. They are also knowledgeable.

Previously, we have not used any other solutions before Red Hat OpenShift as we directly moved to it.

Since deploying Red Hat OpenShift, I have seen a return on investment as it saved a lot. Once we deployed, there is very minimalistic time spent on troubleshooting issues. Everything is taken care of by the containers or the new pods we have deployed. Time was the major thing which saved a lot, and in terms of resources, it has reduced resource utilization so the remaining users can focus on other tasks.

Our company has a business relationship with Red Hat as we are a partner.

Since deploying Red Hat OpenShift, I have seen a return on investment as it saved a lot. Once we deployed, there is very minimalistic time spent on troubleshooting issues. Everything is taken care of by the containers or the new pods we have deployed. Time was the major thing which saved a lot, and in terms of resources, it has reduced resource utilization so the remaining users can focus on other tasks.

I may provide information about setup costs in another review at a later time.

Before choosing Red Hat OpenShift, we did not evaluate other options as this was an organization decision where we did not involve other tools.

I rate Red Hat OpenShift a nine out of ten.

I rated it a nine because it made a lot of work easy for me comparatively to handling servers, where I used to work in monolithic applications. This helped me a lot when I moved to Red Hat OpenShift. Kubernetes was the part where I used to work on and when I moved to Red Hat OpenShift, it gave me a broader way where I can think or explore much on what is not there with Kubernetes. The functions and features all together in one place helped me a lot.

My advice for others looking into using Red Hat OpenShift is that I surely advise going with Red Hat OpenShift, which is a very convenient way to handle their applications and to reduce the cost of servers and whatever resources we spend. Those resources can be utilized much more efficiently with Red Hat OpenShift, and that is the very easiest way.

I have additional thoughts about Red Hat OpenShift in that I appreciate the documentation given by the Red Hat team. That helps us a lot from a learning perspective.

My main use case for Red Hat OpenShift is to train and learn more about containers and Kubernetes, aiming to upgrade my competencies in this field to propose solutions with Red Hat OpenShift containerization and virtualization for my clients.

Most of my Red Hat OpenShift deployment is for training. I encounter difficulties in understanding and deploying Red Hat OpenShift due to the many scenarios for bare metals and virtualization, including various deployment methods such as assisted installers or dark sites installation. This presents a challenge for me, but with extensive training and deployment, I understand the differences and can deploy clusters with different scenarios for private cloud, bare metals, or proofs of concept.

Until now, we are trying to learn and gain competencies with this ecosystem to assist our clients in understanding the differences between traditional data centers and modern data centers with Red Hat OpenShift containers and integration with virtualization. Many clients are unaware of this new Red Hat OpenShift product based on Kubernetes and how it can replace legacy infrastructures from VMware or other solutions, providing an all-in-one solution focused on operational ease and efficiency for their teams transitioning to these new systems from Red Hat.

In my opinion, the best features Red Hat OpenShift offers include the integration of all specifications related to container, virtualization, and storage through the Storage Data Foundation in one cluster. This provides a comprehensive solution for clients. However, I find it quite challenging to maintain and manage everything without extensive experience. The combination of storage, virtualization, and containers, along with the necessity of networking expertise, makes management difficult for me in the Red Hat OpenShift cluster, but I see great future potential.

Red Hat OpenShift has positively impacted my organization. I have learned a lot about these new technologies. Initially, I was apprehensive about learning Kubernetes, but through Red Hat OpenShift, I gained the confidence to deploy Kubernetes or discuss this solution in meetings. Red Hat OpenShift has proven to be an intelligent product for me, being built on Kubernetes, which is widely recognized and is where many cloud providers are deploying new workloads. Knowing Red Hat OpenShift signifies that I am becoming a Kubernetes expert.

I hope that the interface and dashboard can become more user-friendly to assist in creating clusters and managing network interfaces easily, as opposed to relying heavily on command lines, which complicates management and troubleshooting. I envision a graphical user interface similar to what VMware offers with vSphere for seamless management.

I do not have additional needs for the specifications at the moment, but perhaps we require more functions within the dashboard and clearer configurations that allow users to integrate security more intuitively from the user interface rather than through YAML files or command lines. A setup similar to what VMware did with NSX, HCI storage, and VDS would greatly benefit future users of Red Hat OpenShift, especially those with less experience in Kubernetes ecosystems.

I have not yet seen specific outcomes or metrics regarding time saved or skills gained from this experience.

I have been working in my current position since 2018.

In my experience, Red Hat OpenShift is stable, although I have encountered errors during my labs and proofs of concept. Sometimes, I struggle to comprehend these issues, possibly due to underlying factors, but overall, I find it to be a reliable product from Red Hat.

Red Hat OpenShift's scalability is excellent. As with any Kubernetes cluster, scaling is not a problem. Red Hat OpenShift is designed to be scalable in deployment, making it easy to scale worker nodes, pods, and deployments without issues.

During my training session, I experienced a problem with my training cluster and sought support. The support team attempted to assist me, although it was challenging to comprehend the issues as I was new. Additionally, I supported a client who had Red Hat OpenShift deployment with VMware, where I helped resolve underlying VMware issues that affected their Red Hat OpenShift cluster.

I previously used VMware, which was the primary solution throughout my career. I have also utilized other solutions from Proxmox, Nutanix, or Red Hat Virtualization, which is the standard virtualization product.

My experience with pricing, setup cost, and licensing involved a pre-sales project with Red Hat OpenShift last year, which ultimately did not proceed as the client decided to cancel. Consequently, I only have limited experience that helped me understand the differences between licensing in bare metal, virtualization, and various deployment models such as Red Hat OpenShift, Red Hat OpenShift Plus, and Red Hat OpenShift with Data Foundation, based on CPU or physical cores.

Red Hat OpenShift has positively impacted my organization. I have learned a lot about these new technologies. Initially, I was apprehensive about learning Kubernetes, but through Red Hat OpenShift, I gained the confidence to deploy Kubernetes or discuss this solution in meetings.

Red Hat OpenShift has proven to be an intelligent product for me, being built on Kubernetes, which is widely recognized and is where many cloud providers are deploying new workloads. Knowing Red Hat OpenShift signifies that I am becoming a Kubernetes expert.

I have not yet seen specific outcomes or metrics regarding time saved or skills gained from this experience. I do not have improvements or metrics to share regarding return on investment from my work with Red Hat OpenShift.

My experience with pricing, setup cost, and licensing involved a pre-sales project with Red Hat OpenShift last year, which ultimately did not proceed as the client decided to cancel. Consequently, I only have limited experience that helped me understand the differences between licensing in bare metal, virtualization, and various deployment models such as Red Hat OpenShift, Red Hat OpenShift Plus, and Red Hat OpenShift with Data Foundation, based on CPU or physical cores.

I directly adopted Red Hat OpenShift without evaluating other options.

My advice for others considering Red Hat OpenShift is to ensure they have substantial experience in networking and storage, particularly with Kubernetes. It is crucial not to approach Red Hat OpenShift without a proper understanding of Kubernetes. I would rate my overall experience at three out of five.

Our main use case for Red Hat OpenShift is that our application, the CBMS application, is a microsite divided into multiple modules with multiple back-end modules built using Spring Boot and Java and UI modules built using Vue.js and React.js. These individual modules are deployed in Red Hat OpenShift, and whenever we make any changes and push to a feature branch, that particular feature branch gets merged with the development branch, and then a build is triggered. Once a build is triggered and I log into Red Hat OpenShift client platform from IBM Cloud, I can see that a build is happening. If there is any compilation issue, the build fails, and if there is no issue, once the build completes, a deployment happens and the application is deployed.

Apart from that, we check config maps, secrets, and see logs in the pod. For example, we worked on another application named AL Lab where the client asked us to download the profile pictures of all the senior managers working in IBM. From that pod, we wrote an API to zip the profile pictures downloading from Box and then put that inside one container from which that application was running and downloaded it. There are many other use cases, and it is very difficult to remember each one of them, but when I am working and seeing the user interface of that application, they come to mind.

A specific example of when Red Hat OpenShift helped my team solve a problem is when I came into this project that got migrated from the Chinese team. I think they built most of the things, and we have a DevOps person in our team who has most of the controls. Now, coming to help, we can find out the config maps and the secrets from Red Hat OpenShift by going into the console. If we need to run the application locally, we can get the secrets and put them in our STS application YML to run the application. I do not have too much experience because I am not getting many opportunities to work on Red Hat OpenShift. My basic work is mainly writing code in this project, which may be Java code, Spring Boot code, Python code, or React.js and Vue.js code, without being too much into the DevOps side, as there is a different person managing that. Whenever she faces any challenge, we work together to solve the problem.

We are mainly using Red Hat OpenShift as a deployment platform where we are pushing our changes. The image is built into the container registry, and when the build triggers, that particular image gets deployed into the containers and pod in Kubernetes. Once the application starts, it gets the secret config maps from specific locations, and the application starts and serves the client.

The best features that Red Hat OpenShift offers include the capabilities for deployment and build of our application. When we are deploying the application in the dev environment, there is a sorting feature based on the name and date, which is very helpful because we have multiple containers and deployments running inside dev, QA, stage, and prod environments. Once we are deploying in dev and have triggered a build, being inside that console, the sorting feature helps us understand whether the recent build has been triggered, which is very helpful.

Red Hat OpenShift has positively impacted our organization by improving efficiency and collaboration, as this is the first time I am trying to use Red Hat OpenShift after previously working with AWS. In the earlier project at Prudential, I was using AWS and before that, in Kroger, we were using IBM Cloud instead of Red Hat OpenShift. In comparison, Red Hat OpenShift seems to be better than IBM Cloud, as that is how I used it in Kroger. I cannot provide a comparison between AWS and Red Hat OpenShift at this juncture, as I was not very aware of what was happening in AWS, and a lot of time has passed since then.

At this particular point, I think it is very difficult for me to suggest how Red Hat OpenShift can be improved, as I need specific documentation outlining all features. Understanding Red Hat OpenShift UI is essential to provide feature improvement ideas, and I currently do not have the knowledge to do so. I do not have anything coming to my mind at this point regarding challenges or areas in which I think Red Hat OpenShift could be easier to use.

I have been using Red Hat OpenShift on this client advantage project for approximately one and a half years.

In my experience, Red Hat OpenShift is stable.

Red Hat OpenShift's scalability is good. We have one application named Content Microservice, which has multiple containers running in production, specifically four containers. I do not think it needs any horizontal or vertical scaling because our user base is not that large, but I believe that in such a situation, Red Hat OpenShift will be able to horizontally or vertically scale itself.

I did not go to Red Hat OpenShift customer support, so I have not had any interactions or needed help.

Before Red Hat OpenShift, I used AWS, but I was working as a developer, so I was not too much aware of the DevOps aspects. In Kroger, I also used IBM Cloud, but I cannot remember much since it has been over two or three years. There, we were updating the IBM Cloud registry and seeing the logs in LogDNA and checking the container registry, where we used to remove images and tag images, but that is all I can recall.

When I came into this project of client advantage microsite, they were already using Red Hat OpenShift, so I did not have the opportunity to evaluate it against other products as I was not in a position to make that decision.

My advice for others looking into using Red Hat OpenShift is to give it a try if someone wants to use a cloud platform. They can assess how much they gain and how much cost saving occurs, possibly giving it a try on a trial basis for one or two months. I truly suggest that any company wanting to move to the cloud should give Red Hat OpenShift a try. My overall rating for Red Hat OpenShift is eight out of ten.

I'm changing to AI, so I'm implementing platforms for agents, specifically for artificial intelligence and agentic platforms.

It is to deploy agents in a sovereign and private tenant. Basically, when customers don't like to share their information with any cloud provider, they prefer to keep the information local. So they deploy their own private cloud, and most of them are using Red Hat OpenShift.

I find support for Kubernetes and security are the most useful features in Red Hat OpenShift.

What I appreciate from Red Hat OpenShift is the capacity to provide an integrated and secure environment that is more or less better than creating the environment from scratch or based on standard Kubernetes. Red Hat OpenShift provides a lot of features that help us to operate the platform in a very professional and efficient way, instead of using low-level tools provided with the open-source capacities. For us, it is a very practical environment in which we can quickly develop features—not using directly AI capacities from Red Hat OpenShift, but our own capacities, in a very integrated way.

The main benefits Red Hat OpenShift provides for me as a final user include the capacity to integrate third-party tools and also the integration between observability, security, and monitoring capacities.

Red Hat OpenShift is very expensive. I am starting to evaluate the capacities specifically related to artificial intelligence. The suite also integrates a lot of open source, which is more or less aligned with my strategy that always tries to use open source. However, as far as I know, it's not so flexible using the components by themselves, but I don't really have firsthand experience. That's what I've been told by the people working with them. It's not so flexible, but you win in integration and lose a little in the capacity of flexibility or making your platform more flexible.

I've been working with Red Hat OpenShift for maybe one year.

I rate the stability of Red Hat OpenShift as quite robust. I'm satisfied with it.

From one to ten, I would rate the ability to scale as nine.

I would also rate the technical support from Red Hat as nine.

I no longer use VMware and Tanzu data solutions because I changed my profile and my department.

For us, the initial setup for Red Hat OpenShift is complex. It's complex, but also powerful.

In my case, I directly work with Red Hat for purchasing the license.

Overall, I would give Red Hat OpenShift a final mark of nine.

As a competitor to Red Hat OpenShift, I think Rancher may be a possibility, but it's very, very far from what Red Hat OpenShift provides. I don't really know any other commercial distribution of Kubernetes. The alternative would be to create the cluster by yourself, using the components or the open-source components, but it would be really, really complicated. Also, alternatives in cloud exist, using the Kubernetes services from cloud providers like Fargate or AKS. But I would rather prefer to create Red Hat OpenShift on top of the cloud instead of using it. It's more expensive, obviously, but we have good experiences.

In terms of functionality, I'm working with Red Hat OpenShift in terms of infrastructure and monitoring, so in these capacities, we are very satisfied.

I can recommend it to other users. Overall, I would give Red Hat OpenShift a final mark of nine.

My main use case for Red Hat OpenShift is to containerize web applications and migrate VMs from VMware to Red Hat OpenShift Virtualization.

For containerizing web apps or migrating VMs with Red Hat OpenShift, we undertook a project to migrate approximately 1,000 VMs because Broadcom changed the license subscription and contract terms. Our customer approved the migration from VMware to Red Hat OpenShift, particularly because our customer needed to implement CI/CD for a better experience and faster rollout of applications.

In my experience, the best features Red Hat OpenShift offers are CI/CD, together with containers and VMs, the ability to run workloads as containers, the autoscaling of deployment applications, cluster autoscaling, and the intuitive web console to manage and view resources.

The most helpful feature for my team is the quick wizard to create a deployment config, a route, API endpoint, services, and application scaling, particularly the HPA, which stands out for us.

Red Hat OpenShift has positively impacted my organization through digital transformation and faster rollout of applications. For example, before using Red Hat OpenShift, our customer waited two days to roll out an application, but with Red Hat OpenShift, they now wait approximately two hours to roll out an application in the production environment.

One area for improvement with Red Hat OpenShift is in management and cluster implementation.

I have been using Red Hat OpenShift for approximately four years.

Red Hat OpenShift is very stable.

Red Hat OpenShift's scalability is excellent because we can scale a deployment or scale a cluster, and we can scale machines if we need to add new nodes to the cluster to provide additional computing resources.

Customer support is great with Red Hat OpenShift. The response time is very good, and I am satisfied.

Previously, we only used virtual machines. We did not switch from another application provider such as Kubernetes, Rancher, EKS, or AKS.

While no aspects are difficult, I am surprised by how quick and fast it is to set up and implement in Day Zero and Day One. It is an easy process to implement.

I have seen a return on investment with Red Hat OpenShift by saving time, saving money, achieving faster rollout of applications, and providing the latest environment for delivering app containerization.

Before choosing Red Hat OpenShift, we evaluated Tanzu VMware.

One challenge I have faced in my main use cases with Red Hat OpenShift is ensuring equal network profiles from VMs, specifically VLAN, VXLAN, and the CNI, and the network-defined profile because many networks need communication between them, which is particularly challenging as this was the first large project of its kind in our case.

My advice for others looking into using Red Hat OpenShift is that it is a great product with a great ecosystem and a mature offering that is stable, with many users globally across numerous companies such as financial institutions and healthcare providers.

Red Hat OpenShift is a trusted product that is stable and secure. It is an approved product and one that we highly regard. I would rate this review a 10 out of 10.

My main use case for Red Hat OpenShift involves two cases: the first case is about the migration of QRadar and Red Hat OpenShift for the cloud, which relates to the process of antivirus, XDR, and SOAR and SIEM. The second case is the use for the migration in ARO, Microsoft Azure Red Hat OpenShift, for the migration of OpenCTI from on-premise to the cloud.

A quick specific example of how I used Red Hat OpenShift for one of those migrations is the particular process of the migration about the OpenCTI. The OpenCTI migration involved a process where we used Docker for the OpenCTI to function correctly when implemented, which was the main challenge.

I do not have anything else to add about my main use case or the migration processes with Red Hat OpenShift.

In my experience, the best feature Red Hat OpenShift offers is that the environment is easy to use. When I say environment needs, I mean that it is easy for the configuration and the management in the different environments. For example, when I use the API key, the configuration and connector, the environment provides easy visibility and allows me to watch the reports for the leadership in the company.

Red Hat OpenShift has positively impacted my organization, and now we use it more in the QRadar SIEM environment. However, in this case, IBM sold QRadar to Palo Alto, and our client changed the SIEM, so Red Hat OpenShift is not functional at this moment for QRadar.

Red Hat OpenShift can be improved by addressing any features, performance, or usability issues. In my view, the performance is very good, and the automatization of the new environment and new machine is fantastic because it is easier for my job in the company. My colleagues display information and the Docker functionality is good.

There are two small things I would suggest about the SOAR: the connection for the SOAR to send email and send communication to our colleagues and people in the company.

If I could change or improve one thing about Red Hat OpenShift, it would be to provide more information on the web because the information is limited and I need to explore more. I would change this about Red Hat OpenShift because I have known this all year and need more investigation.

I have been using Red Hat OpenShift for about one year, more than one year ago.

Red Hat OpenShift is stable.

In my view, Red Hat OpenShift's scalability is good, although I do not know for certain.

The customer support for Red Hat OpenShift is bad because the support does not respond.

I did not previously use a different solution before Red Hat OpenShift. However, before it, we used VMware.

Before choosing Red Hat OpenShift, we evaluated other options, specifically VMware.

I have seen a return on investment from using Red Hat OpenShift because I save money since I do not need the server in my data center on-premise, and I save money in monthly payments for availability and accessibility in the data center.

I cannot respond to the question about my experience with pricing, setup cost, and licensing because the cost is another area, specifically the area of accounting and finance.

Before choosing Red Hat OpenShift, we evaluated other options, specifically VMware.

My advice for others looking into using Red Hat OpenShift is to explore the tools, understand how Red Hat OpenShift migration to the cloud works, and recognize that the response and return on metric is efficient for good operation.

That is all I would like to add about the features of Red Hat OpenShift. I choose seven out of ten because my use is not total. Perhaps it is interesting for the use, but our environment in the company is easier to use with VMware. I rate this product seven out of ten overall.

I do not have any additional thoughts about Red Hat OpenShift.

I work for IBM Control, so I work with Red Hat and VMware, both technologies. I am working with OpenShift. I have not worked on Red Hat CloudForms, but I work with OpenShift. I am the integrator. We are creating automation for our customers using OpenShift, and we have implemented Ansible Tower Platform for automating all the system admin tasks.

We create what you call Ansible playbooks, which we execute for automation and deploy across all of our multi-customers within IBM and Control.

I find the resilient infrastructure feature of OpenShift very valuable, as it has no downtime at all.

I find OpenShift to be very scalable.

The initial setup of OpenShift is difficult; it takes a while to set it up. It is difficult to set up OpenShift because of the infrastructure requirements and the customization required to set up the software.

I would advise others looking into using OpenShift that it is a pretty product, widely accepted by customers, easily scalable, and highly reliable, but it should be more user-friendly. I think it should be more user-friendly because many people request assistance setting it up the first time.

I have been working with the solution for three and a half years.

OpenShift is stable. I would say the stability of OpenShift is nine out of ten.

I find OpenShift to be very scalable. I would rate the scalability of OpenShift a nine.

I think the technical support from Red Hat is good. I rate the technical support an eight. The reason for the rating of eight for technical support is that problems arise frequently, and they need to fix those issues, as it is open-source software requiring a lot of customizations.

We actually buy everything with maintenance; when we buy the software, we buy it with maintenance.

The initial setup of OpenShift is difficult; it takes a while to set it up. It is difficult to set up OpenShift because of the infrastructure requirements and the customization required to set up the software. I would rate the initial setup of OpenShift around five.

The initial setup of that solution took us weeks, but now the deployment is completed within days. It took one to ten days to set up OpenShift.

There are twenty-four to twenty-five people involved in the deployment. I think two to three people are architects, along with all the engineers involved.

I would advise others looking into using OpenShift that it is a pretty product, widely accepted by customers, easily scalable, and highly reliable, but it should be more user-friendly. I think it should be more user-friendly because many people request assistance setting it up the first time. I cannot think of any new features that could be added to make the solution better right now. My overall review rating for this solution is eight out of ten.

We already were having that microservices architecture, so there was not much change from that perspective. We had small services, so here we had to create multiple pod IDs. Even today, we are using a hybrid microservices architecture. Our DB still has two or three services that hit the same database. From that perspective, there was not much change that we did in our case.

We have certain applications on-prem on physical servers. We had some on Windows and some on Linux. There we had requirements where every time we had to manage extra load, we had to spawn a new Tomcat node. Scaling was one of the issues we were facing, and every time we had to scale up, it was a challenge. Plus, we had to procure infrastructure and do a lot of configuration and setup for the new instance being launched.

Once we set that up, scaling down was a challenge as we did not always bring that down when not needed. When we did not have too much traffic, we still had a lot of infrastructure lying idle. At the same time, when we had high load, we were not able to scale up quickly.

There was too much patching that happened, and every time we had to patch something it became a challenge. There were versioning issues with operating systems versus Java and other technologies we were using. That is why we moved to containerization, where we defined what operating system we need, what Java version we need, and what steps we want to do. Containerization helped us create that one unit we wanted to deploy. Red Hat OpenShift helped us with managing scaling up and scaling down.

Because it was centrally managed in our company, many metrics that we had to write code for were available out of the box, including utilization, CPU utilization, memory, and similar metrics. We performed multiple transformations from physical servers to Red Hat OpenShift, and some from virtual servers to Red Hat OpenShift.

The OC utility tool is something we use very often for replication, replica sets, and config maps for managing all environments and secrets. This is very useful for us. Routing is another beneficial feature we get, so we do not need to manage or do too many things for load balancing.

Currently, one of the biggest challenges we face is with services and jobs. For spawning batches, although it has crons, it is not easy to integrate with enterprise systems such as Autosys. The entire company uses Autosys, but we are not able to integrate it effectively.

We need intermediate servers to run OC utility commands and initiate the cron job. We have to do a lot of modifications to ensure our batches work properly. With physical or virtual servers, even in AWS, we are able to write and manage multiple jobs. Managing batches in Red Hat OpenShift has been a significant challenge.

Integrating third parties is a challenge with Red Hat OpenShift. For example, with Elasticsearch, onboarding itself was difficult, running file beats and dealing with routing issues. It is not straightforward, especially since we have some components in AWS as. AWS has many capabilities that come out of the box and are easier to work with compared to Red Hat OpenShift.

Red Hat OpenShift's biggest disadvantage is they do not provide any private cloud setup where we can host on our site using their services. The main reason we went with Red Hat OpenShift was because it is a private cloud, and we have regulatory requirements that prevent us from using public cloud.

The main reason we went with Red Hat OpenShift was because it is a private cloud, and we have regulatory requirements that prevent us from using public cloud. Red Hat OpenShift's biggest disadvantage is they do not provide any private cloud setup where we can host on our site using their services. For the use cases we dealt with, we have not seen much challenge with AWS. It has been better for us, but due to our requirement of being on private cloud for some applications, we are using Red Hat OpenShift.

We do not have any AI products at this time.

We have certain applications on-prem on physical servers, some on Windows and some on Linux. We had requirements where every time we had to manage extra load, we had to spawn a new Tomcat node. Scaling was one of the issues we were facing, and every time we had to scale up, it was a challenge. We had to procure infrastructure and do extensive configuration and setup for new instance launches. Once set up, scaling down was also a challenge as we did not always reduce capacity when not needed. When we did not have much traffic, we still had substantial infrastructure sitting idle. Simultaneously, during high load periods, we were not able to scale up quickly.

We have support available, but we never had to use it because we have our own internal teams who provide support. We have not encountered any issue where we had to reach out to Red Hat.

Neutral

It is not difficult to onboard onto Red Hat OpenShift. Once you understand deployment configs, configs, replica sets, the basic components, routes and all, it is straightforward to onboard an application there. This applies mainly to services. Beyond that, it becomes challenging. We have not tried too many things because we struggled with batches. Getting things up and running in AWS, such as Kafka and Elasticsearch, is much easier than doing it on Red Hat OpenShift.

It is cost-effective. The only consideration is that you have to use it wisely. Use only what you need because it is not very difficult to add resources. It is always advisable to get the bare minimum that you need, and then add more when necessary. When you do not need the services, bring them down so you are not unnecessarily using compute resources. If you use it efficiently, then it is beneficial, which is applicable to any cloud platform.

If you are dealing with services and need private cloud, go for Red Hat OpenShift. Regarding cost, if you compare to public cloud platforms, it is cheaper. If you are mostly on the services side and need private cloud, Red Hat OpenShift should be the solution. The overall rating is six out of ten, as it is not seen as a complete solution, but rather as a solution only for services. For other requirements such as integrations or batches, other cloud providers might be more suitable.