Red Hat OpenShift Container Platform Reviews

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.   

I am using it for my critical system, specifically for the payment system.

Especially the security side is nice. On the other hand, there is firm support in the background. This is helpful for me since I am also native to Bandit system. On OpenShift side, I can get support from Airflow. It is a good aspect. It is important for critical systems.

I have used it for approximately three or four years.

I would rate stability between seven and eight out of ten.

It is easy to expand. Scalability is rated nine out of ten.

Quality of support may be improved. I would rate it seven out of ten.

Neutral

It is not too simple, however, it is not too hard either. It was a normal installation.

I know Kubernetes, however, I am not aware of other alternatives nowadays.

It is easy to expand it. I would give it a rating of eight out of ten.

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.  

Our use case is primarily to do with DataPower. We wanted to configure DataPower and move away from appliances to a software-based solution, which is CP4I. DataPower is an IBM product, and we were using their firmware machine. We wanted to move from hardware or firmware to software, and CP4I is a software-based solution for DataPower, and that works primarily for any Kubernetes, but IBM had both. So we moved to Kubernetes, and on top of that, we had CP4I.

We did the implementation for one organization. It was widely used, and there was a huge customer base. It was primarily in the telecom domain. Those APIs were used, and we were getting a lot of incoming traffic and outgoing traffic through DataPower.

This solution is deployed on our private cloud.

The architecture is the best. The solution is scalable if you are on a container-based solution. I can easily spin a new container or create another image, so that was the benefit. It was scalable, and I could easily ramp up and ramp down the services based on the need.

OpenShift is not very old. They have built an entire layer on top of Kubernetes. Getting the solution quickly and troubleshooting quickly are both areas where I think it needs some work. 

It wasn't very problematic for us because we were getting the solution. They also needed to do some experiments in their own lab, because our use case was a little different, and we were one of the few who were implementing it for the first time with Cloud Pak.

I have been using this solution for about two and a half years.

It wasn't stable while we were testing it, but now it's really stable.

I would rate technical support 4 out of 5. 

The deployment was very easy, which is another benefit. The orchestration and management were also very user-friendly and easy.

We used our own technical team for deployment. The team, including support and everything, was around five to six people. They were working on services also, like creating and deploying the APIs. We had the infrastructure team who were managing the clusters.

It also depends on the size and how many master nodes there are, how many worker nodes you have, and the mechanism you're using for logging. I was using Prometheus and Grafana. It all depends on how huge your architecture, how huge your infrastructure is.

We definitely did the ROI on this new implementation, and we found that in the long run, it was going to save a lot.

We paid for Cloud Pak for integration. It all depends on how many VMs or how many CPUs you are using. They do the licensing based on that.

It was not very cheap, but it was affordable for the organization. They had the enterprise ELA, which means they had the enterprise licensing agreement with IBM. So it worked for them, and it wasn't very expensive.

I would rate this solution 8 out of 10.

I have been using OpenShift Container Platform as a container of network functions for customer's telecom industry. 

One practical example of how OpenShift Container Platform helps us is in deploying security updates quickly, which is superior compared to other solutions like Coverness, Canonical, Kubernetes, Rancher, etc. However, there are areas for improvement in networking, architecture, and cloud aspects of the solution.

I find the security features and use of operators in OpenShift Container Platform highly valuable. The container update capabilities and OpenShift data foundation for storage are also important features.

I believe OpenShift Container Platform can improve in networking, architecture, and cloud areas by reducing deployment time, lowering costs, and streamlining engineer resources. Additionally, I would like to see more Azure I/O functions in the next release.

I have been using OpenShift Container Platform for four years.

The platform is stable and capable, covering various customer needs.

The scalability of OpenShift Container Platform is excellent. It allows for quick scale-outs with new workers, making it very efficient and is used by eighteen engineers for telecom purposes, impacting business significantly.

Technical support from OpenShift is decent but could be improved in some locations.

I find the initial setup of OpenShift Container Platform to be moderately complex. The deployment involves steps like installation, configuration, and deploying common services on-premises. Deployment typically takes around four hours and involves a team of two to four people. I'm not involved in maintenance. 

I'm not familiar with pricing or financial aspects. In terms of effort versus benefit, it's worth it.

My advice for new users is to explore the platform thoroughly as it's complex yet reliable. I would rate their customer service a seven out of ten. Overall, I rate OpenShift Container Platform a nine as it's a good product with room for improvement.

We use the OpenShift Container Platform to deploy applications. It helps to deploy them from a monolithic to a microservices approach. 

The tool's most valuable features include high availability, scalability, and security. Other features like advanced cluster management, advanced cluster security, and Red Hat Quay make it powerful for businesses. It also comes with features like OpenShift Virtualization. 

OpenShift Container Platform needs to work on integrations. 

I have been using the solution for two years. 

I rate the tool's stability an eight out of ten. We encountered certain bugs and issues, which were resolved once we raised them with Red Hat. 

I rate OpenShift Container Platform's scalability a ten out of ten. The autoscale feature is particularly beneficial for managing varying traffic loads on the platform. It automatically deploys additional VMs in response to high traffic and scales down when the traffic returns to normal levels. This feature is more powerful when deploying the OpenShift Container Platform on cloud platforms like AWS or Azure, where it adapts to the fluctuating traffic demands. My company has 15 customers who are mostly enterprise businesses. 

Red Hat offers good technical support. 

Positive

I rate the product's deployment an eight out of ten. It was a little complex. There are two to three types of initial configuration, including UBI. UBI is complex. Deployment takes around two hours to complete. 

The deployment process involves some complexity. We create configuration files and distribute these files to the platforms we work on, such as VMware or Nutanix. Subsequently, we initiate the initial deployment and configuration of OpenShift.

The solution is expensive, and I rate it an eight out of ten. There is a subscription called OpenShift Plus, which offers additional features and products the vendor provides to complement the OpenShift Container Platform. These include ACM, Red Hat Quay, and Red Hat OpenShift Data Foundation.

I recommend studying the documentation thoroughly and preparing the infrastructure according to the guidelines. Following the documentation is crucial, and most issues reported were related to network problems. Therefore, I suggest becoming proficient in troubleshooting network issues to identify and resolve problems. I rate the solution a nine out of ten. 

The principal use case of the platform is the transition and migration to the cloud. The second one is the modernization of our integration platforms.

The usability and the developer experience. The platform has a centralized consultant that is easy to use for our development, operations and security teams.

The price needs to be improved in OpenShift Container Platform.

When I choose this, the product is the first factor that we have to make a long analysis to compare the real cost for the other services. However, price is high.

I have been using OpenShift Container Platform for five years. We started with OpenShift Container Platform and now we have OpenShift Container Platform tools. 

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

I would rate the tool’s scalability a nine out of ten.

The solution is difficult to set up because of the limitations of the premises. 

Overall, I would rate the product a nine out of ten.

I usually help companies design their environments, find workloads efficiencies, suggest best practices, and provide an overview of the environment, which involves consultation and a focused-oriented approach. I also deploy and develop solutions for companies. I do end-to-end deployment for companies.

OpenShift Container Platform is used by companies moving from their old monolithic environment to a microservices-oriented architecture. If a company wants to do a BAU sort of stuff, they already have OpenShift Container Platform, but they need someone to drive it or work on its day-to-day automation while looking at its integration with Ansible or Puppet.

People choose OpenShift Container Platform because it's an open-source and Red Hat Kubernetes product. Red Hat has made Kubernetes command-line oriented, obscure, and hard to learn. OpenShift is easier to learn for a newbie, especially for someone who has not used CLI. The support structure of OpenShift is pretty good and absolutely terrific. The bug fixes and patching capabilities, along with the whole ecosystem of OpenShift Container Platform, are very mature from a technical standpoint or from an enterprise standpoint. If you are a big company and invest a lot of money in certain solutions, you need and expect top-notch support and features of very high quality. OpenShift Container Platform is a very good way to get in started in this whole containerization journey for some companies because the underlying product is from Red Hat, which has its own benefits. The aforementioned factors play a role in the decision-making process of most companies.

I have only been working for two years on OpenShift Container Platform, and I have only seen good stuff so far. Hopefully, in the next two years, I will have a bit more hands-on experience to find out some pain points in the product.

There are no perfect tools. Many things can be done better in a product, but I don't know how to make it possible. Once I have done enough with the tool, I should be able to give you a bit more insight into the product's pain points.

The interface could be a bit more useful or better. The product's interface is a bit buggy.

I have been using OpenShift Container Platform for a couple of years. I am a consultant who specializes in Red Hat products. I am a Red Hat-certified engineer.

The tool is scalable enough because it is available across the clouds, like AWS or Azure. You can have the tool deployed on-premises too. I think it's a pretty scalable tool.

The solution's technical support has been pretty good. Red Hat offers the best support to its users.

I am a person who is a bit more infrastructure-focused. JBoss is a middleware software, and I don't really work in that space. I am more into the underlying infrastructure, Red Hat Enterprise Linux, Red Hat Containers and Kubernetes, and that sort of stuff, including OpenShift and OpenStack. I am not really into the application layer.

Overall, I rate the solution a seven out of ten.