Solution Architect at a financial services firm with 10,001+ employees
Real User
Top 20
2023-07-19T05:57:27Z
Jul 19, 2023
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.
Development Team Lead & Project Manager at bank hapoalim
Real User
Top 10
2023-02-12T16:42:00Z
Feb 12, 2023
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.
Solution Architect at a financial services firm with 10,001+ employees
Real User
Top 20
2022-12-26T20:10:00Z
Dec 26, 2022
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 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.
Senior DevOps Engineer at a tech services company with 1-10 employees
Real User
Top 10
2022-12-25T17:05:00Z
Dec 25, 2022
One area for improvement is that we can't currently run Docker inside a container, as it clashes with security consents. It would be good if we could change that. The stability of the console could be improved.
Senior IT DevOps Engineer at a transportation company with 10,001+ employees
Real User
Top 10
2022-11-22T15:25:00Z
Nov 22, 2022
In my experience, the issues are not always simply technical. They do stem from technical challenges, but they struggle with the topic of adoption. When you encounter all of the customer pull, there are normally several tiers of your client pop that can adopt either the fundamental features or a little more advanced ones. The majority of the time, the challenge is determining how to drive adoption, how to sell the product to the customer, and how much time they can spend to really utilize those advanced features. If we get into much more detail, but this is from my perspective as the platform engineer and not the end customer, the ability of the end user to be able to debug potential issues with their application That is arguably the most important, let's say, work throughput in my area.
Software Architecture & Integration Development unit manager at AgeSA
Real User
Top 20
2022-09-26T15:03:25Z
Sep 26, 2022
The monitoring is problematic. The product monitoring tool does not work for us. We had to purchase the Dynatrace solution to monitor our product and our applications, and this is a weakness of OpenShift Container Platform. If there was some orchestration with mini services because microservices can be complex.
There will be things that can improve, however, at this stage I cannot give a point or two. Maybe after a few months, I can give more details. One improvement I can suggest is for the people who are not very competent with technology, for the product to give some tips on the screen, to make it easier for them. Things are there and the documentation is there, however, there still needs to be quick guides available. Then it will be easier for people to adapt and learn. Rather than going to big documentation, if there is some quick help or quick guide available and then it would help people to quickly adapt and learn. It still has to improve compatibility with a couple of more platforms. It works with many however we are still trying to improvise more on a couple of other platforms. Integration seems to take a little bit of time. It would be nice if it was expanded and simplified a bit.
It is difficult to deploy the OpenShift cluster in a bare-metal environment. For example, when there are errors during the cluster deployment, it is hard to find the error on any documentation. So, from the cluster deployment perspective, there could be improvements. Also, the machine config and machine config tools need improvement. The machine config tool implements changes related to files over the worker and master nodes in OpenShift. However, sometimes it starts without warning, and it is unclear how the error can be fixed. In terms of additional features, it will be good to have the support of the CNI or OVN for the Multus CNI. Currently, in OpenShift, the additional networks added by the Multus and the pods do not support the OVN CNI plugin. OVN is supported in OpenShift, but only for the non-Multus interface, which is the primary interface of pods.
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.
The monitoring and logging could be improved. I think it would help developers in terms of provisioning the database and the whole development lifecycle.
IBM Data & IA Technology Consultant at a tech services company with 10,001+ employees
Real User
Top 10
2022-05-15T17:07:36Z
May 15, 2022
OpenShift's documentation could be better. It's difficult to document everything you need in a specific use case. You have to seek some support or spend a few minutes trying to figure out what's going on. Another thing that bugs me is that they removed the software in NFS storage. I don't understand why because this is a common type of storage. I am having problems with that, so I wish they would put it back.
Solutions Architect at a financial services firm with 10,001+ employees
Real User
2022-04-12T16:15:31Z
Apr 12, 2022
There should be a simplification of the overall cluster environment. It should require fewer resources. Just to run a simple Hello World app, it requires about seven servers, and that's just crazy. I understand that it is fully redundant, but it's prohibitively expensive to get something simple going. We've had a very difficult time going from version 3 to 4. We need to go to version 4 because of multiple network segments that may be running in a container and how we organize our applications. It's very difficult to have applications from different domains in the same container cluster. We've had a lot of problems with that. I find it to be an overcomplicated environment, and some of the other simpler containers may very well rise above this.
Computer Specialist at a government with 1,001-5,000 employees
Real User
2021-02-23T16:55:00Z
Feb 23, 2021
It has an option to install OpenShift without connecting it to the Internet. We tried this, but it was very hard. We couldn't manage to use that option. We wanted to use it offline for installations, updates, upgrades, etc., but we didn't find the offline installation and updates easy. This could be better.
CTO and Principal Architect at Li9 Technology Solutions
Real User
2020-11-13T22:12:14Z
Nov 13, 2020
The solution has pretty good features overall. I can't recall if there are any that are lacking. The pricing is quite high. It would be nice if they could make it more competitive. The solution needs to introduce open ID connect integration for role-based access control.
Digital Solution Technical Analyst at ADIB - Abu Dhabi Islamic Bank
Real User
2020-11-03T05:43:00Z
Nov 3, 2020
From a networking perspective, the routing capability can be matured further. OpenShift doesn't handle restrictions on what kind of IPs are allowed, who can access them, and who cannot access them. So it is a simple matter of just using it with adequate network access, at the network level. It should be possible to whitelist IPs so that you can allow and restrict access to the API. That would be a fantastic feature. OpenShift would then encapsulate the entire security and access. This is one improvement that I would seriously want our client to have, and for that reason, I have joined the OpenShift community, and it is a project I could probably work on myself. The second thing is that deployment is more of a strategy rather than a feature in OpenShift. Although you can create different routes, and it works fine, it is not an innate feature of OpenShift that it understands that you want to run specific versions of the same service as needed.
Red Hat® OpenShift® offers a consistent hybrid cloud foundation for building and scaling containerized applications. Benefit from streamlined platform installation and upgrades from one of the enterprise Kubernetes leaders.
OpenShift Container Platform needs to work on integrations.
There is room for improvement with integration.
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.
OpenShift Container Platform is an expensive solution, and its pricing could be improved.
My impression is that this solution is pretty expensive so I think the pricing plan could improve.
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.
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 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.
One area for improvement is that we can't currently run Docker inside a container, as it clashes with security consents. It would be good if we could change that. The stability of the console could be improved.
The UI could be more user-friendly to drive tasks more effectively through the interface.
In my experience, the issues are not always simply technical. They do stem from technical challenges, but they struggle with the topic of adoption. When you encounter all of the customer pull, there are normally several tiers of your client pop that can adopt either the fundamental features or a little more advanced ones. The majority of the time, the challenge is determining how to drive adoption, how to sell the product to the customer, and how much time they can spend to really utilize those advanced features. If we get into much more detail, but this is from my perspective as the platform engineer and not the end customer, the ability of the end user to be able to debug potential issues with their application That is arguably the most important, let's say, work throughput in my area.
The monitoring is problematic. The product monitoring tool does not work for us. We had to purchase the Dynatrace solution to monitor our product and our applications, and this is a weakness of OpenShift Container Platform. If there was some orchestration with mini services because microservices can be complex.
The solution does not work on a route-wise NFS.
There will be things that can improve, however, at this stage I cannot give a point or two. Maybe after a few months, I can give more details. One improvement I can suggest is for the people who are not very competent with technology, for the product to give some tips on the screen, to make it easier for them. Things are there and the documentation is there, however, there still needs to be quick guides available. Then it will be easier for people to adapt and learn. Rather than going to big documentation, if there is some quick help or quick guide available and then it would help people to quickly adapt and learn. It still has to improve compatibility with a couple of more platforms. It works with many however we are still trying to improvise more on a couple of other platforms. Integration seems to take a little bit of time. It would be nice if it was expanded and simplified a bit.
It is difficult to deploy the OpenShift cluster in a bare-metal environment. For example, when there are errors during the cluster deployment, it is hard to find the error on any documentation. So, from the cluster deployment perspective, there could be improvements. Also, the machine config and machine config tools need improvement. The machine config tool implements changes related to files over the worker and master nodes in OpenShift. However, sometimes it starts without warning, and it is unclear how the error can be fixed. In terms of additional features, it will be good to have the support of the CNI or OVN for the Multus CNI. Currently, in OpenShift, the additional networks added by the Multus and the pods do not support the OVN CNI plugin. OVN is supported in OpenShift, but only for the non-Multus interface, which is the primary interface of pods.
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.
The monitoring and logging could be improved. I think it would help developers in terms of provisioning the database and the whole development lifecycle.
OpenShift's documentation could be better. It's difficult to document everything you need in a specific use case. You have to seek some support or spend a few minutes trying to figure out what's going on. Another thing that bugs me is that they removed the software in NFS storage. I don't understand why because this is a common type of storage. I am having problems with that, so I wish they would put it back.
There should be a simplification of the overall cluster environment. It should require fewer resources. Just to run a simple Hello World app, it requires about seven servers, and that's just crazy. I understand that it is fully redundant, but it's prohibitively expensive to get something simple going. We've had a very difficult time going from version 3 to 4. We need to go to version 4 because of multiple network segments that may be running in a container and how we organize our applications. It's very difficult to have applications from different domains in the same container cluster. We've had a lot of problems with that. I find it to be an overcomplicated environment, and some of the other simpler containers may very well rise above this.
It has an option to install OpenShift without connecting it to the Internet. We tried this, but it was very hard. We couldn't manage to use that option. We wanted to use it offline for installations, updates, upgrades, etc., but we didn't find the offline installation and updates easy. This could be better.
The solution has pretty good features overall. I can't recall if there are any that are lacking. The pricing is quite high. It would be nice if they could make it more competitive. The solution needs to introduce open ID connect integration for role-based access control.
From a networking perspective, the routing capability can be matured further. OpenShift doesn't handle restrictions on what kind of IPs are allowed, who can access them, and who cannot access them. So it is a simple matter of just using it with adequate network access, at the network level. It should be possible to whitelist IPs so that you can allow and restrict access to the API. That would be a fantastic feature. OpenShift would then encapsulate the entire security and access. This is one improvement that I would seriously want our client to have, and for that reason, I have joined the OpenShift community, and it is a project I could probably work on myself. The second thing is that deployment is more of a strategy rather than a feature in OpenShift. Although you can create different routes, and it works fine, it is not an innate feature of OpenShift that it understands that you want to run specific versions of the same service as needed.