Red Hat OpenShift Container Platform Reviews

Our primary use case for Red Hat OpenShift Container Platform is to enhance our Kubernetes management by leveraging the additional features and tools it provides. We use it to deploy applications, set up pipelines with Tekton, integrate secure networking, and facilitate AI and machine learning projects through MLOps.

Red Hat OpenShift has made the development processes more manageable and secure, particularly by providing its own DNS system, a pipeline solution called Tekton, and features like source-to-image. These enhancements simplify the complex tasks seen in plain Kubernetes, making it user-friendly and improving DevOps efficiency.

The most valuable features of OpenShift include its advanced security, integrated DNS system, built-in pipeline management with Tekton, enhanced networking routes, and dedicated platforms for DataOps and MLOps. These features make it a robust choice for handling enterprise-level tasks securely and efficiently.

Setting up OpenShift locally can be challenging, particularly because it requires RHL Linux and has specific restrictions. Additionally, the documentation for local setups is lacking. Improving these aspects would make OpenShift more accessible to the community for trial and development purposes.

I have been using Red Hat OpenShift Container Platform for two years.

OpenShift is highly stable. Its performance is comparable to Kubernetes, with enhancements where Kubernetes lacks certain features.

Scalability is customizable and straightforward. We can deploy it on any cloud service or our server center and scale it easily. Red Hat and AWS provide excellent support, making it easier to scale quickly.

The technical support from Red Hat and AWS is reliable and friendly, aiding problem resolution effectively.

Neutral

I have experience with Kubernetes, Docker, and Sravan for container management. However, OpenShift stands out for its security and feature enhancements.

The initial setup for OpenShift on the cloud platform is straightforward and quick, taking five to ten minutes to initiate and up to one day to deploy all resources, depending on the complexity. For local setups, the process is more complicated and error-prone.

Typically, three to four people are needed for deployment. This may include configuring nodes and setting up multi-cluster or hybrid environments to ensure scalability and ease of management.

If your concerns are primarily security and feature enhancement, OpenShift offers substantial value. It is suitable for larger teams concerned about security and usability. Smaller teams with less stringent requirements might consider other solutions. Careful cost estimation is crucial to avoid unnecessary financial burdens.

I'd rate the solution nine out of ten.

I work in a bank and we develop new microservices based on mainframe legacy systems. They want to start developing new microservices to reduce the calls to the mainframe. DevOps in Bank Hapoalim uses OpenShift as a platform and all the services are deployed automatically to avoid the problem of services being unavailable. So the main use case is to modernize the existing legacy systems. All the big projects of the bank are going through this modernization, with a new architecture and deploying stuff through microservices.

It makes our work much easier. Everything works automatically: the pods, memory, and CPU grow automatically. We had so many systems on the old technologies and it's very hard to modernize them. But this tool, OpenShift Container Platform, helps a lot. If we want to keep up with the market and be a strong organization, we have to support modernization. We can't see all the banks making changes and still go with the old systems.

Also, the department that's in charge of it, DevOps, has given us more dashboards so that we can see more details, exactly what's going on in terms of timing and everything. They give us all the details we need to see about the microservices.

It's an easy platform to use.

I'm not sure if this is an issue with OCP, but it takes time to deploy. I'm not sure because we have pipelines and Jenkins jobs that deploy the microservice so it takes time. It can take 10 to 15 minutes to deploy a microservice. The CI/CD process takes a long time, and if it's because of OCP, that is something that can be changed.

I have been using OpenShift Container Platform for about two years.

Overall it's stable. Sometimes I see problems with the stability, but I'm not sure that the problem is with OCP. There are things that we need to explore more deeply, but I would say it's stable.

It scales microservices automatically.

We have about 1,000 internal users of OCP and about a quarter of them use it daily.

We did not use any other container management software.

There were several other departments involved in the setup. 

It was done in-house.

It's a very cool product. You can trust it. We have plenty of complicated microservices systems deployed through this platform, and it does the job. We see the results. I only have good feedback about it.

It's nice to see technology getting better and better, doing things automatically. The platform can fit every organization, with the right configuration. It can do whatever you need it to do. It's very impressive to see how the technology of this platform does it.

Red Hat is acquired by IBM, there is still a separate entity, but we are more on the partner side.

I work with IBM, and most of our solutions are on the OpenShift platform. I work with our business partners to enable and help them with the technical pre-sales and setup role. So, I'm not involved in production engineering systems but rather in demos, first application implementations, and POCs.

The user experience and security are some of the key features. There are two key differentiators that you have certainly worked on from the customer's perspective.

It is actually very well laid out for a computer product. But maybe, since it has security built into it, it is sometimes very difficult for people to grasp.

It is much easier to work with Kubernetes than OpenShift. On the inside, all the security and other aspects are very much required by the container.

It has a difficult learning curve. Those are the areas where, from a customer perspective, OpenShift is a little challenging compared to other Kubernetes solutions.

I have been using it for five years. 

I would rate the stability of this solution a ten out of ten.  It is very stable.

I would rate the scalability a ten out of ten. It is a scalable solution. Our customers are mostly enterprise businesses for Red Hat OpenShift. 

The technical support is good. One challenge is that sometimes it may be difficult to find the answers to your questions if you are not a Red Hat customer. Many of the answers require you to log in to the Red Hat portal. Unless you are a customer, you cannot ask for a solution. On those lines, it is a little difficult. Otherwise, technical support is good.

Positive

I would rate my experience with the initial setup an eight out of ten, with ten being easy and one being difficult. 

The initial setup is a little difficult because installing and configuring it is very involved. I don't see it as easy yet.

It's deployed on both the cloud or on-premises. On the cloud, it's much easier where it is managed OpenShift. If we go to managed offerings like Red Hat OpenShift on AWS, Azure OpenShift, or IBM Cloud, it is much easier to provision. But if it is self-managed, where you have to do everything yourself, it is difficult.

Red Hat OpenShift is self-managed, not from a cloud provider. If you are doing it on the cloud, then it is just a couple of hours. But if it is self-managed, then it will depend on the infrastructure, networking, and all that. It is still a team, but not yet a resource to have all that correctly set up.

It has been a good solution to deploy all containerized applications, like our AI and ML applications. We're not missing out on that capability.

The ROI is definitely much better because once it is set up and done, it is very easy to manage and have applications deployed. The user experience is very good. So once you have it in place, it's easy to do the day-to-day operations, and eventually, scalability and all those things become clear.

Overall, I would rate it a nine out of ten. It is a very good solution overall.

I would definitely recommend it to others.

We use the solution to manage our digital assets like containers and applications.

Integrating the product into our existing infrastructure was easy. We did not face any issues.

The price must be improved.

I have been using the solution for six years.

I rate the product’s stability a nine out of ten.

The product’s scalability is good. I rate the scalability an eight out of ten. We have around 15 users.

The support people help us whenever we require their assistance. A partner provides us with the first-level support. The support has been good, but it is not direct support. We have a problem that has not been fixed for a long time.

Positive

I rate the ease of setup a six out of ten. The project was ten months long. The deployment took a month.

I rate the pricing a four or five out of ten.

I have also used Docker and Kubernetes.

I will recommend the solution to others. Overall, I rate the tool a nine out of ten.

Our primary use case for this solution is, as an open system, to deploy containers on AWS or other platforms and then manage them.

The most valuable feature for me in the OpenShift Container Platform is the option to manage different containers and environments and also being able to switch among them.

My impression is that this solution is pretty expensive so I think the pricing plan could improve.

I have been using this solution for about two years.

I would rate the stability a nine, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate the scalability an eight, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate the technical support of this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best.

Positive

I was not involved in the initial deployment but I heard that it's not too hard to set up with all the support available.

I would rate the pricing of this solution a four, on a scale from one to 10, with one being the most expensive and 10 being the least expensive.

I would advise other people looking into this solution – if they could afford their pricing plan – to go for it as it's a great product.

I would rate this solution a seven, on a scale from one to 10, with one being the worst and 10 being the best.

We primarily work on middleware applications to communicate between front and backend services and use the solution to deploy our platform as a container. Our entire application goes into OpenShift containers.

We initially started with OpenShift 2.0 and 3.0, which were on-prem platform versions. Then we moved on to OCP 4.0, a hybrid platform in the Red Hat cloud.

We don't use the solution on the vendor's OpenStack Platform; we integrate with vendors, but they have their own capabilities and manage their services and infrastructure. We build our services and then deploy them on the OpenShift platform, and if the vendor deployed their services or APIs on a different system, then we integrate with them, but we don't control vendor platforms.

When we first came to the microservice platform, we deployed our applications on a VM service, and it became tough to manage the VMs, as we added endpoints to endpoints. Then, we learned about OpenShift, Docker, and containers and were given OpenShift to deploy our microservices as a container to make our server management easier. Having a CI/CD pipeline with the container and Dockers means we don't have to spend time on deployment, pipelines, etc. The product increased our productivity and sped up our process, which helped us a lot.

When we had the VM infrastructure, the developers' building services had to spend significant time doing the deployments. Many of our developers didn't know how to use Linux commands, so we had to train them. As a result, the time spent on training, building, and deploying the packages was very high. OCS reduced that significantly, and containers are slightly quicker than VM servers, which positively affected our productivity.

Our developers can now focus on the development code, and as we moved away from a VM model, our system downtime was significantly reduced. Even when first deploying an application, the container is already running because we always have an active instance there. So, the rollover, service startups, deployments, and productivity saw significant boosts, and we were able to deliver more value to our business as an application team.

The solution's security throughout the stack and the software supply chain is very reliable. When it was on-prem, it was by default secured by our company firewalls and security tools, and now it's in the cloud, which has its security and systems in place. This provides stability to our infrastructure.  

We communicate on OpenShift under STDPS and TLS 1.2-based protocols, so whenever we contact our front and backend systems, we have certificates, handshakes, and the TLS protocols in place. These prevent any unauthorized access to our services, which makes out job easier and allows us to prioritize security.  

OpenShift provides the flexibility and efficiency of cloud-native stacks while enabling us to meet regulatory constraints. When we first onboarded the solution, we evaluated that it would not cause any regulatory limitations, and it's the only platform that was introduced to the application teams as a result. The main regulatory concern for a container that's being consumed by any service is security, and the solution provides this.  

The product's automated processes affected our development time, which is our most significant time saving, and when development time is reduced, so is the time required for production deployment. If the developers consume less sprint time, we minimize deployment time and increase overall productivity. This way, OpenShift provides our teams with a lot of flexibility and capability.  

Whenever we onboard or deploy services that talk to Oracle Database, they take a lot of time to become active and serve the incoming request, so it would be good to see some improvement here. This could be an OpenShift issue or an internal network problem within our organization.

OpenShift is an excellent platform, but AWS is fighting a tough fight, so Red Hat must continually improve its product.

I've been using the solution for about four years, first in a developer role and now as an architect.

The tool is very stable; we haven't seen any downtime since moving to OpenShift architecture. We had some minor issues here and there, but these were nominal. The VMs are also highly stable; we didn't see any problems with those.

The scalability is excellent, and it's one of the aspects we love most about OpenShift. We can drastically improve our output if throughput increases and we have the CPU resources and memory.

Our company has over 10,000 members of staff, and 60-70% of our APIs and teams are on OpenShift. 

When we encounter issues, we reach out to our DevOps team, and they can help us. They may reach out to the Red Hat team, but 90% of the time, they can assist us themselves.

Positive

We previously deployed our code to a VM platform and switched for several reasons: scalability, time reduction of the development cycle, and building and deploying. We don't have to manage the infrastructure or pay for all the hardware required, and VMs are a heavy solution. OpenShift has lightweight components, which helped us transition from a VM environment.

I wasn't involved in the deployment but in migrating my team's project to OpenShift. I was new to Docker-based platforms, so it was initially difficult for me to understand, but with some knowledge transfer, it was straightforward to pick up.

The migration from our legacy service to OpenShift was rapid; it took us a couple of days to write a Docker file and set up the environments, and we were good to go.

In the case of a single service, the deployment takes two to three minutes if the Docker image is ready beforehand.

Regarding deployment, our application team consists of 15-20 developers continually working and deploying their services on the platform.

We carried out the deployment internally; we had good documentation, and an occasional Google search helped us through the process.

From my perspective as a technical individual, I've gained much knowledge from using the solution. Still, regarding an ROI from a financial perspective, I'm not privy to those discussions.

It's possible that we evaluated other options, but I was not part of that team. 

I rate OpenShift a ten out of ten. 

Project onboarding time is a major pain area for us, but OpenShift isn't the issue; it's a company problem. When we want to onboard a new project to the platform, it takes some time due to internal processes which aren't dependent on OpenShift. If we manage to streamline our company processes, there's no reason for problems to occur while onboarding.

We didn't consider building our own container platform. As the application team, we weren't asked to do that; we were provided with OpenShift and started using it.

Red Hat is very supportive and an old organization, so it's easy to trust them.   

Our primary use case is to deploy Java and Angler UI codes into the platform's containers. We will soon migrate our product infrastructure to OpenShift. 

The most significant improvement has been in the microservices area, as the solution simplifies the deployment of microservices. We don't have to spend much time on the infrastructure and CI/CD pipeline, so OpenShift saves us a lot of time.

OpenShift eliminates distractions, allowing our teams to focus on innovation, features, and functionality. For example, the elementary deployment and the platform makes dealing with infrastructure very straightforward, allowing us to focus on other tasks. OpenShift taking care of infrastructure-related issues, in particular, takes a weight off us, and it feels good to focus on innovation, discovery, etc.   

The solution's CodeReady Workspaces reduce project onboarding time, and Red Hat can create a Workspace for us within two weeks. We place a request, and they start working on it; it's pretty fast because we're migrating most of the bank's processes over to OpenShift.  

The CodeReady Workspaces reduce our time to market by around 20%.   

The product is stable, reliable, and easy to use, from a well-known company, has a large volume handling capacity, and more and more organizations are moving to OpenShift.

The scale-up and scale-down functions of the product's UI are excellent.

The deployment is elementary and seamless.

We use the product on the vendor's OpenStack Platform, and in terms of speed and ease with which it enables us to create infrastructure on the OpenStack Platform, it's the best and most straightforward approach. OpenShift is excellent compared to other vendors like Google Kubernetes Engine and Azure Kubernetes Service; it's easier to use, more reliable and handles volume better. 

The solution is very good at creating infrastructure that can be flexibly sized to meet specific needs on the OpenStack Platform; there are options to increase and reduce the size to meet volume demands. 

The tool's security throughout the stack and the software supply chain is excellent; we are a large bank, so security is a top priority.  

OpenShift's security features are highly capable of running business-critical applications. The solution is exciting, and I'm looking forward to getting more hands-on experience. 

The solution's automated processes are excellent, and OpenShift has good integration potential with GitHub and Tangible, allowing a lot of code deployment automation. Plugins are also available for other CI/CD pipeline tools like Jenkins Pipeline, reducing our development time.  

The UI could be more user-friendly to drive tasks more effectively through the interface.

We used the trial version of the solution for one to two months to get hands-on experience in preparation for IBM Industry 4.0. 

OpenShift is a stable product.

The scalability is excellent; it allows for a very high transaction volume. 

OpenShift's technical support is outstanding, and I rate them highly.

Positive

I previously used Google Kubernetes Engine, and many of the bank's teams started switching to the OpenShift Container Platform. Once I got my hands on the product, I saw it was very good. The general trend in our organization is one of migrating to OCP.

I wasn't involved in the initial setup of the product, but it took around 30 minutes and I know it to be elementary. 

I'm an architect, so I have no involvement in the pricing and licensing of the platform.

We evaluated GKE and found OCP much more lightweight and easier to use. I tried with GKE but was never successful with it. However, with no background in OCP, I watched some YouTube tutorials and successfully deployed a sample project. This ease of use is essential for us, as we don't need to spend time dealing with infrastructure and can focus on the development and functional aspects.

I rate the solution a ten out of ten. 

We didn't consider building our own container platform because it's too big a job. We're a bank, and most banks focus more on developing functionality than building a container platform and instead look for the best available tool.

We also use Red Hat Linux and chose it because it's very stable and reliable.  

The biggest lesson I've learned from using the solution is how easy and simple it is to deploy, how little we need to focus on infrastructure, and how it allows us to prioritize functionality.  

We have a monolithic application, and our primary use case is to implement microservices. We needed Kubernetes, but instead of going with plain Kubernetes, we chose OpenShift because it has a well-designed UI, more advanced features, and better security.

The product provides great visibility in the form of metrics over our systems. The infrastructure team monitors the platform with their personal tools and dashboards and can see how it deals with loads, security threats, if bugs are present, etc. Then they can send reports to the rest of us in the organization.

The solution's CodeReady Workspaces reduce project onboarding time in the region of 10-15%.  

The CodeReady Workspaces also reduce the time to market; a rival vendor released an offering we had to counter, so we used the platform to implement and deploy our counter in three to four days.   

One of the best features is monitoring; we can see metrics via visual aids when the load increases, for example.

The software is user-friendly and straightforward to use, which is favorable to a developer.

The system also takes care of itself regarding scaling; the platform can up and downscale automatically depending on demand.  

With OpenShift, there is no need to learn new technology, as the skills required for Kubernetes carry over; the commands are interchangeable. Therefore, OpenShift is a developer-friendly tool.

We use the solution on the vendor's OpenStack Platform, and in terms of the ease and speed with which it enables us to create infrastructure, it's very straightforward. We can set up an environment within a day or two, and it's a very convenient way to develop.  

The infrastructure created by the solution on the OpenStack Platform is very robust; we created communication metrics: a shield where all VMs, master, and worker nodes communicate from subnet to subnet. We designed these and gave them to Red Hat, where they developed the ISO clients for deployment from day one. After gaining hands-on experience, we could create our own and implement a cluster.   

OpenShift is highly effective at creating infrastructure that can be flexibly sized to meet specific needs on the OpenStack Platform. The minimum basic configuration is three masters, three infra, and two worker nodes. When a load starts passing through this setup, and we reach a certain threshold, say the worker machines are running at 60%, we can add another node, another VM. We have added eight to ten VMs in this way before. After experimenting with different configurations, we get a feel of which one to implement for a specific use case within the production environment. If we want to scale up, we add worker nodes; nothing else is required.  

OpenShift provides solid security throughout the stack and the software supply chain; the solution has an inbuilt image registry and doesn't allow outside images, making the system more secure. The platform also features a Compliance Operator, which assesses the compliance of API resources and the nodes running the cluster.  

I want to see more incorporation of native automation features; then, we could write a code, deploy it directly to OpenShift, and allow it to take care of the automated process. Using this method, we could write one application and have elements copied or pasted to other applications in the development process.

There are some gaps in the solution's security, so there is room for improvement in the security and compliance features. Protection against ransomware attacks would be welcome, much like in Google Apigee.

We've been using the solution for two years.

OpenShift's current stability as of 4.10 is excellent; I don't see any issues. From 4.0 to 4.6, the product wasn't stable, and in many cases, nodes went down, taking down other nodes, and we had to follow up on clusters a lot. After 4.8, the stability issues were fixed, and we haven't had a problem in a year.

The platform is highly scalable; we simply need to add VMs to accommodate the amount of traffic we have, which is a straightforward task. Eight to ten VMs is sufficient for millions of users, and we can easily implement them in a cloud-based or on-prem environment. There are around 50 total users across our Dev Teams, and the solution was able to support one million users of our applications per second without an issue. 

Overall, the customer support is good. There's a ticket process with a priority level from one to three, indicating the highest and lowest priority, respectively, with two in the middle. Level one means production is impacted, and support responds rapidly to help with a client team. There are some delays with the lower-priority tickets, but they are there when we need them most. They could have better internal communication so they are all on the same page, as we are sometimes asked the same questions by different people and have to re-explain the issue.

Neutral

We previously used Kubernetes and switched because it's more complex from the developer, management, and maintenance perspectives. It doesn't have a proper UI, so knowledge of Linux is required to operate the CLI. However, with OpenShift, a newcomer can log in and run the solution using the UI, which is an excellent capability for a development company. OpenShift isn't restrictive; anyone can use it, making it a good choice.

In addition to the UI, OpenShift has more advanced features, such as the Internal Image Registry, which can restrict malware images. The product is also straightforward to deploy and has good integrations with other tools like Jenkins.

The initial deployment was straightforward and took two days. At most, two staff members are required to deploy and maintain the solution.

The pricing and licensing are handled on an upper management level, and I'm not involved in that, but I understand the solution to be somewhat pricey.

I rate the solution an eight out of ten. 

We recently experienced a Log4j vulnerability issue, and the OpenShift team released a patch to which we upgraded, but they could have done a better job.

Regarding the platform helping us meet regulatory constraints, I have yet to deal with this area.

In terms of automation, most people I know use Github, Jenkins, or some other third-party platform and integrate with OpenShift.

We didn't consider building our own container platform because Kubernetes is an excellent platform, and OpenShift is built on top of it. We're satisfied with what we have and see no need to start from the beginning.  

Red Hat is an excellent partner; we never shared code, but we used to have review meetings where we shared room for improvement with the product and gave some suggestions. For example, we would like a backup process or system implemented, and we have communicated this to Red Hat.