Red Hat OpenShift Reviews

We're going to deploy the entire core banking of the bank on the platform.

It helps us through consolidation, ease of use, portability, and because I can use microservices. It's like a one-stop shop for most of my containerized applications that are going to be deployed.

The most valuable features are that 

• it's cloud agnostic
• the containerization and security features are outstanding.

The cloud-agnostic aspect means I can move to AWS, Google, or Azure. That means it is not a limitation. It gives me flexibility.

For running business-critical applications, on a scale of one to five, where five is the best, OpenShift is 4.8.

Room for improvement is around the offerings that come as a bundle with the container platform. The packaging of the platform should be done such that customers do not have to purchase additional licenses.

They should partner with Jenkins. It goes without saying that I need Jenkins for my CICD. If Jenkins comes with support, that's good. But if there is a licensed product, I need to secure that license and then I will get support. 

Although the bundling with OCP is better than that offered by others, they can work more on it.

We implemented OpenShift in January 2023, so about six months ago, but we have not fully used it. It's the first time that we've installed it, and we're yet to implement.

It's pretty scalable because of the architecture. I don't see any issues in terms of scaling up or across. During our design phase, we had to scale across and as far as the design was concerned, it was pretty easy.

We can also scale it back. We can reduce or expand as per our needs.

In the future, it will be used by our entire bank, with between 8,000 and 10,000 users. 

We intend to expand the usage but we have to wash our hands of the core banking system first, which itself is a huge system. Once we're done with that, we'll think about other applications.

The forums and services are perfect. Excellent.

Positive

We did not have a previous container platform solution. We did try to build our own but it failed, badly. Building a container platform is not an easy task.

The initial setup is in between straightforward and complex. It's not so easy but not that tough. But we do require a lot of training.

Our deployment took one month.

Red Hat did most of it. We just provided them with the bare metal and away they went. It was a very time-bound project, and the Red Hat team was there. Our teams also worked with them. It was a collaborative exercise. On our side, there were 10 to 15 people involved, but there were five key people.

The CodeReady Workspaces should help reduce time to market if I use the CICD pipelines. That's what we aim for, and that's what the container platform is built for. That's something that goes without saying.

We're using Red Hat Linux across the bank for servers. We will use quite a number of Red Hat products during our core banking deployment, including AMQ, Process Automation Manager, and a couple of other products that are bundled with OCP.

The integration is something that is out of the stack. It's more of a middleware conversation and the middleware for us is an IPaaS. It's less about the stack and more about the application. I don't think there are any issues communicating via APIs. And the access management is pretty adequate. I can plug in any IM or document archival solutions. It's pretty easy to integrate.

Red Hat, as a vendor, has shared ample information with us to help us make decisions. That is where a partner comes into play and we're pretty happy with Red Hat.

We use it for container management. It's our container management platform for our financial systems.

It provides flexibility and efficiency. It helps us to design and deliver applications efficiently. We can modify our application in a smaller scope. We don't need to change the whole application.

It makes development fast because we can separate applications into different parts. We can deliver applications in different phases. 

It has helped to improve the quality of our end products. It has reduced the project onboarding time by 20% to 25%.

I like OCP, and the management UI is better than the open-source ones.

The integration with 3scale is very good. We use that too.

The monitoring part could be better to monitor the performance. The automation part could also be better because we had a hard time integrating our application with OCP.

I've been using this solution for about two years.

It's stable.

It's scalable for one cluster. When it comes to multiple clusters, it could be better. 

We have about 100 users who use this solution.

Their enterprise support is okay, but sometimes, their response is slow. Their response is also not accurate sometimes. It's not right.

Neutral

I didn't use it, but my company used the PKS solution.

It's straightforward. The setup took two to three days.

Red Hat is quite okay as a partner for helping us create the platform that we need. They do help you. They also provide training.

We use Red Hat AMQ streams and 3scale, and its integration with other Red Hat solutions is okay. The advantage of using multiple products from the same vendor is that you can get help from one company. You don't have to go to multiple companies.

It gives me the security that I need, but I didn't evaluate the security much. There is another department that's responsible for that.

I would recommend this solution to others, and overall, I would rate it an eight out of ten.

Usually, we use it as a test environment and to quickly develop the proof of concept for various projects. So, it's mainly for quick deployment and testing.

It's deployed on the cloud and on-premises.

The biggest benefit is the speed. When developing a new PoC, if we don't have a container-based environment, we would have to set up virtual machines. We would have to install different software to make sure that there are secure ways to do that, which would most likely need a couple of days, whereas, with a container-based platform, such as Kubernetes or OpenShift, we can do that in a matter of minutes or hours.

The security throughout the stack and the software supply chain is very good. It's a step-by-step procedure to obtain new software. It's very secure. We cannot have access without a safe, provisioned way. For troubleshooting a fault, I like the new oc debug feature where you spin up a new pod for debugging. You can spin up a new test pod for a complete copy of the problematic one. We are very happy with it security-wise. I would rate it a nine out of ten in terms of security features for running business-critical applications. That's only because I never give a ten.

It provides us with the flexibility and efficiency of cloud-native stacks while enabling us to meet regulatory constraints. We can automate these checks. For example, in the hybrid cloud model, we can check for different things, such as the accessibility of many different classes not only in the cloud but also on-premises. We can use the hybrid view to check many things very quickly. If someone comes into the company from a regulatory body whose job is to run a couple of scripts and check if certain rules apply to all servers, without having this kind of interface, we would have to give him a week to be able to connect to everything and check everything one by one, and of course, we would have to pay him for that. With OpenShift, from one panel, we can automatically run a script across several different servers or even connect manually to each of them, which is a big benefit. It saves a lot of time and money.

It can speed up the development time. There's only Jenkins, but I'm not so sure about that. Because the development and testing phases are sped up, the time to market can also be very good. However, it also depends on other factors, such as any back-and-forth changes, because we can have a lot of feedback. Overall, there is about a 10% improvement in the time to market.

The CodeReady Workspaces reduce project onboarding time. There is about a 20% reduction.

Its security is most valuable. It's by default secure, which is very important.

It's very easy to manage deployment across different environments. It doesn't matter if it's a private or a hybrid cloud. It's very well-suited for the type of work that we do, which is the deployment for our PoCs. It's very easy to start with small ideas and then gradually scale up. 

It's very easy to integrate with different systems and products, which is another plus point. 

It also has a very nice user interface. It's very self-explanatory, and that saves a lot of time from training new users. You can cut a lot of time to quickly familiarize yourself with the base.

OperatorHub is another big plus. It's very easy to use and very useful.

One thing that can be improved but is surely difficult to improve is the cost. We have a lot of customers who would prefer a Vanilla Kubernetes solution or another solution that combines Kubernetes with some cloud provider, especially if they are already using a specific cloud provider. When we try to work with them, some customers complain about it.

Another thing is that the installation and setup process is a little bit complex, but I must admit that it has improved a lot as compared to the older version. 

Autoscaling is a very unique feature, but it could be useful to have more options based on traffic statistics, for example, via Prometheus. So, there should be more ready solutions to autoscale based on specific applications.

I've been using this solution for about one and a half years.

It's a very stable solution. Usually, problems occur when there's an application error or someone does something wrong and there is a human factor. For example, once there was an application creating a lot of automatic snapshots. There were volumes of snapshots, which couldn't be deleted easily. So, occasionally, there may be some bugs, but generally, it's very stable.

Scalability is a big plus. There is scalability from nodes to machines and so on. However, I would prefer more options on scalability based on statistics. That would be very interesting and very nice to see in the future.

Currently, we have less than 100 users who use this solution. They are mostly developers. There are also some end-users, assessors, architects, administrators, and project managers. The end-user experience is quite self-explanatory, and it's very important.

Once I'm able to talk to a technician, the support is very good. They are very knowledgeable and polite. I'm very impressed, and I've only good things to say about their technical support even though there's a lot of bureaucracy until you reach the right department, which can take some time, but I understand that. All big organizations have a bit of a challenge. I would rate them an eight out of ten.

As a partner for helping us create the platform that we need, I would rate Red Hat a nine out of ten. They're helpful. Whenever I'm in contact with the technical team, they're knowledgeable and helpful.

Positive

I'm not sure because I wasn't involved in the installation. 

We never considered building our own container platform. I've only seen customers using Vanilla Kubernetes because OpenShift is a little bit expensive, and some specific organizations have chosen to invest in a strong team because they would need a strong team to build Vanilla Kubernetes. They are succeeding in maintaining that way of working. I have seen this a couple of times.

I wasn't involved in its initial setup, but I talked to a lot of the people who were involved. Compared to a simple or Vanilla Kubernetes, it requires lots more work and has a lot of default processes constantly running, but, in my opinion, it's something where OpenShift is getting better and better. It's getting quicker. It's going in the right direction.

The deployment took a few days.

I believe there is an ROI for organizations where security is very important, and because of privacy requirements, the public cloud cannot be an option. Especially in the banking sector, there's almost no competition. There is about 15% ROI.

It's expensive. It may be cheaper to invest in building Vanilla Kubernetes, especially if security is not the number one motivation or requirement. Of course, that's difficult, and in some business areas, such as banking, that's not something you can put as a second priority. In other situations, a Vanilla Kubernetes with a sufficiently strong team can be cheaper and almost as effective. In addition, people who are already working with a specific cloud provider tend to find cheaper solutions by combining Kubernetes on the specific cloud and choosing that over OpenShift.

It's important to build a team around this. So, invest in getting the correct training. There are a lot of options that Red Hat provides. Start small, scale up gradually, and involve people from different areas. In addition to the infrastructure team, also involve someone from development and the architecture team to be able to see its value from different perspectives.

I would rate it a nine out of ten. I'm very happy with the interface, security, and support.

Our company uses it as a platform as a service. We have business units with developers who deploy their containerized applications in OpenShift. We have a team that supports the infrastructure of clusters all over the world. We run thousands of applications on it.

It's deployed on-prem and in the cloud.

One benefit is that it provides you with the flexibility and efficiency of cloud-native stacks while enabling you to meet regulatory constraints. They have a catalog of the ratings of the base images that we use to build our containers. We reference that to show our security team that an application we're building has passed the security with vulnerabilities that are acceptable. We won't deploy it if something is not unacceptable.

In terms of our organization, the business units are able to deploy changes to the code rapidly. They can test it on the test cluster and, once it's tested, they can deploy an image in seconds. It has saved us time. Our guys are continuing to move to the OpenShift platform from whatever they were on, whether it was a mainframe or a standalone machine. And they're doing that for the cost savings.

In addition, a perfect example of the solution's automated processes and their effect on development time is the source-to-image feature. The developer can use that tool to improve his code's quality and it saves him some time. He doesn't have to understand the specifics of building a container.

There is also an advantage due to the solution's CodeReady Workspaces. That definitely helps reduce project onboarding time. There are prebuilt packages that they use. We have a lot of Java and some .NET and Python and the CodeReady packages help. Conservatively, that feature has reduced onboarding time by 50 percent. It also helps reduce the time to market by about the same amount.

Overall, Red Hat is a handy tool to have, like an electric screwdriver instead of a manual one. We don't have to write things manually. We can use what they've already written to make us more productive.

The developers seem to like the source-to-image feature. That makes it easy for them to deploy an application from code into containers, so they don't have to think about things. They take it straight from their code into a containerized application. If you don't have OpenShift, you have to build the container and then deploy the container to, say, EKS or something like that. It's a little different.

In terms of the solution’s security throughout the stack and the software supply chain, it meets our needs. It's excellent as far as we're concerned. It goes right along with the Kubernetes role-based assets control. OpenShift's security features for running business-critical applications are excellent. A lot of our external-facing applications have been protected. We do use Apigee for a lot of it, but we also do security scans so we don't expose something to a known vulnerability.

The software-defined networking part of it caused us quite a bit of heartburn. We ran into a lot of problems with the difference between on-prem and cloud, where we had to make quite a number of modifications. That heartburn meant millions of dollars for us. That was a year ago and the product has matured since then. They've since resolved it, so it's not really an issue anymore.

The storage part of it was also problematic. There were quite a few things that really hampered us. But it's much better now.

I've been using OpenShift for five years.

It's extremely stable. We haven't had any outages that were caused by the software. There have been issues due to human error on our side, such as not buying enough memory for the host. 

It's also extremely scalable. On our dev cluster, we auto-scale from 50 nodes up to 130 on a weekend, when there is a need. It also scales itself down to save money over the weekend. When people start hitting it on Monday, it scales back up, seamlessly.

In terms of users, we have about 20,000 developers, all over the world. It's used 24 hours a day. We have centralized development clusters that are being used all the time because we have deployments on every continent except Antarctica.

We're moving off mainframes and monolithic apps into the containerized world. Increasing our usage is a stated management decision in our organization. OpenShift has been growing in our company in the last couple of years.

We use the tech support daily and they're pretty good. There are always going to be a few rough spots, but most of the time they're responsive.

You may get one support guy who doesn't understand the solution or the problem and they give a wrong solution, and we all know that it's the wrong solution. The problem is that we have people who have different first languages, so they don't always phrase the question well. I can see where a tech support guy might get a little confused because of the wording of an issue.

Red Hat, as a partner for helping to create the platform we need, has shared code, information, and ideas. They've been very helpful and open. We have a couple of technical account managers who meet with us once a month. One is in the UK and the other is in the US. They're very responsive when it comes to any problems we run into.

Positive

Previously, all we used were standalone Unix machines. We didn't use a different container orchestration, like Mesos. We never considered building our own. We took a look at OpenShift a long time ago and it was really the best at the time.

Version 3 is very complex but it's 1,000 times better than five years ago, and it's even much better than it was a year ago. The deployment was a pain point for our company, but it's irrelevant for someone buying it now. They have fixed a lot of stuff.

We have huge deployments, hundreds of nodes in a cluster. The deployment time is relative to the size of the cluster, but the deployment time has gone from a week to a day for a 100-node cluster. Red Hat has improved the process considerably.

It provides us with good value.

There weren't a whole lot of options. There was Mesos or home-grown or Kubernetes using Rancher. There wasn't anything that really compared to OpenShift at the time. OpenShift was a complete package. There were a lot of things you had to do manually with the other products. The Kubernetes world has changed a lot since then.

The fact that Red Hat was open source was a factor and the security was what we really liked about it. They use CRI-O, which is a secure runtime container, as opposed to using Docker, which is super-insecure running as root. Red Hat is definitely the leader in the container security world.

You have to understand what you're getting into and you have to be committed to upgrading it. There are some people in the world who say they'll never want to upgrade it again. With Kubernetes, if you're going to get into OpenShift, you have to "sign the bottom line," so to speak, that says, "I'm going to update it," because the Kubernetes world moves at a fast pace.

In terms of container orchestration, we are totally OpenShift, but we use other Red Hat products like Linux and Tower. We do have standalone Linux machines that we manage, but we'll be migrating some of the applications from those standalone machines into the OpenShift container world. That's where the cost savings are.

We use the solution to split monolithic into microservices. I mostly use OpenShift as a Kubernetes distribution. 

I am impressed with the product's security features. 

The tool lacks some features to make it compliant with Kubernetes. 

I am working with the solution for four years. 

The tool is stable. 

The cloud version is scalable. The solution's on-prem scalability can be improved. 

The tool's support should be improved. 

Positive

The tool's deployment takes a matter of hours to complete. You need a team of three to four to maintain the solution. 

The product's support is expensive. I would rate the tool's pricing an eight out of ten. 

I would rate the solution an eight out of ten. The tool requires knowledgeable people to manage it. 

The solution's CodeReady Workspaces reduce project onboarding time by around 10%. 

OpenShift's CodeReady Workspaces also help reduce time to market by about 10%.  

Overall, the solution's security throughout the stack and software supply chain is excellent.

OpenShift offers great security thanks to role-based access control and segregation between projects. The security is very good, even for mission-critical projects.   

The product provides us with the flexibility and efficiency of cloud-native stacks while enabling us to meet regulatory constraints. Furthermore, it doesn't require us to learn a whole new vocabulary, there is no vast stepping stone regarding configuration and management, and we aren't cloud-locked. If we want to move our OpenShift solution to another cloud provider, or even our private data center, that's doable. The tool is better in terms of application management than anything found in the cloud, and one of the main selling points of OpenShift is the abstraction of infrastructure. 

There is room for improvement regarding the secret management and the integrated vault. I want easier node management and more user-friendly scripts for installing master and worker nodes.

In addition, the configuration for addons onto OpenShift could be more straightforward; for example, if I want to integrate with a general monitoring solution. 

We've been using the solution for almost eight years. 

The solution is stable. 

OpenShift is a scalable tool; we have 100-200 users, primarily developers and DevOps staff.

I rate the support a six out of ten, the knowledge base is difficult to navigate, and the documentation is complex.

Neutral

We previously used an on-premise server and implemented a massive change by moving from on-prem to AWS cloud provider to OpenShift.

The initial setup was complex; it was pretty complicated to set up the master, replication, turn ingress and egress, router, and configure the worker nodes, particularly the automatic scaling part of the worker nodes.

It isn't easy to quantify precisely, but we've seen a very good return on our investment.

The pricing is standard; the solution isn't particularly expensive or affordable.

I rate the solution a nine out of ten. 

We did not use the solution's automation for development; everything before building and deploying an image on an OpenShift project is done on another program or system, with no interaction. We do the verification and security aspects of the build artifact in OpenShift, but we don't use it to build and run the package, etc.

Red Hat could have been a better partner for helping us create the platform we need, as they weren't particularly helpful or reactive with concern to our specific requirements. They didn't step up as a partner but as more of a vendor; they provided the product in a commercial sense but not with a partnership mindset.

We use another Red Hat product, the Ansible Automation Platform. 

We didn't integrate Ansible and OpenShift, but we once had to connect them, which wasn't straightforward. 

Those considering implementing the solution should go to learn.openshift.com, where they can play around and see if they like the product. The hosted version of OpenShift is better than the dedicated one, as you don't have to manage your own node, deployment, or infrastructure. So, for those who can afford it, I recommend the instance hosted on the Red Hat system.

Our use cases for OpenShift are for payments and internal bank transactions.

What I like best about OpenShift is that it can reduce some of the costs of having multiple applications because you can just move them into small container applications. For example, applications don't need to run for twenty days, only to be used up by Monday. Through OpenShift, you can move some of the small applications into any cloud.

I also find the design of OpenShift good.

My team has found some bugs in OpenShift due to continuous integration, and this is an area for improvement in the platform. RedHat should fix the bugs.

Another area for improvement in OpenShift is that upgrading clusters can be challenging, resulting in downtime.

Application support also needs improvement in OpenShift because the platform doesn't support all applications in the cloud.

I'd like upgraded storage in the next release of OpenShift, especially when I need to do a DR exercise. It would also be good if the platform allows mirroring with another cluster, or more portability in terms of moving applications to another cluster.

We're using OpenShift for the last two years.

OpenShift is a good solution, stability-wise.

The performance of OpenShift is good, but sometimes, it can be bad, depending on the network, but that's okay. That's normal. You won't have a very bad experience with OpenShift, performance-wise. You'll experience some issues from it, but it's still a good platform.

As OpenShift is on-premise, there's not much scalability from it. My team is still coming up with new clusters, and some clusters have been deployed as well, but my company isn't ready to scale OpenShift at the moment.

My team contacts OpenShift support whenever there's an issue, and it was a very bad experience. The response time needs improvement, and support didn't give straightforward answers.

On a scale of one to five, my rating for OpenShift support is a two.

The setup for OpenShift was complex, and it can only be done by a consultant. My team can do an on-premise setup and automation, but a consultant has to certify the cluster, otherwise, you can't get support from RedHat.

Deployment for OpenShift can be completed within six to seven hours depending on the infrastructure. Otherwise, it could take more than one day.

My rating for the initial setup of OpenShift is three out of five. RedHat will check the setup or configuration, and if the customer is ready to take over the process, then it's good, but what's usually happening is that the vendor isn't providing detailed guidelines, so my rating is more on the neutral side.

We used a RedHat consultant for the deployment of OpenShift.

The licensing cost for OpenShift is expensive when compared to other products. RedHat also charges you additional costs apart from the standard licensing fees.

We're currently evaluating a product from IBM.

My company uses OpenShift currently, but it's still under RFP.

OpenShift is deployed on-premises on a disconnected cluster for a financial institution.

Some maintenance is required for OpenShift. Whenever there's a bug, my team does the maintenance, but there's still a need to check with RedHat support on how to fix the bug. My team can't do the maintenance without support from RedHat developers.

Less than ten people use OpenShift within the company.

I would recommend OpenShift to others because it's a good tool for the financial sector versus public clouds such as AWS and Azure. I'd also advice others that if it's a public cloud, it's easy to manage, but if it's on-premise, then it can't be managed.

My rating for OpenShift is seven out of ten.

My company is a customer of OpenShift.

These are for some of our applications where we wanted high resiliency. In the traditional VM environment, what used to happen is that everything was dependent on the infrastructure. We wanted to move away from that particular concept. Once an application becomes stateless, it should not be dependent upon platform-related things. We wanted it to be more robust and perform at a much better efficiency. We also wanted higher availability.

We are getting everything from OpenShift at this point in time. What we're doing here is pretty much basic. Any of Kubernetes could have done it because all we're looking for is being able to manage the complete cluster.

Its interface is good. The other part is the seamless integration with the stack that I have. Because my stack is mostly of Red Hat, which is running on top of VMware virtualization, I have had no issues with integrating both of these and trying to install them. We had a seamless integration with the other non-Red Hat products as well.

One of the features that I've observed in Tanzu Mission Control is that I can manage multiple Kubernetes environments. For instance, one of my lines of business is using OpenShift OKD; another one wants to use Google Anthos, and somebody else wants to use VMware Tanzu. If I have to manage all these, Tanzu Mission Control is giving me the opportunity to completely manage all of my Kubernetes clusters, whereas, with OpenShift, I can only manage a particular area. I can't manage other Kubernetes clusters. I would like to have the option to manage all Kubernetes clusters with OpenShift.

I would like to have self-service capability. A lot of developers want to become independent today, and they don't want to depend on the Infra teams for managing, provisioning, etc. If we can give a self-service capability, in terms of building a particular Kubernetes cluster end-to-end, to developers, that would be a plus. That's the ask of the hour.

I have been using this solution for the past one and a half years.

It is a perfectly stable product. If an application is ready to be containerized, it is seamless. You will not have any hiccups.

Scaling up and down is happening, but my concern is that if we hit any kind of bugs, the open-source community won't be that active in terms of doing the bug fixes. If I get any bug, there might be a delay in getting the bug release or the patch coming up. When I'm hosting an enterprise data application on an open-source product, I will have a little higher risk of non-availability, and that might lead to revenue impact as well. Keeping that in mind, I would like to go for the enterprise edition, at least for my high revenue-generating applications.

In terms of the number of people working with this solution, I have about eight administrators. I have eight people in my team who manage the complete Kubernetes cluster for me, which is a combination of OKD and Tanzu. It is being used on a daily basis.

We are using the open-source version, and their community support is good. I don't expect a rapid response from the community, but if I post today, I usually get a response in a few hours. 

We have an enterprise agreement with Red Hat for the other products that we are using. Their response is very prompt.

We also use Tanzu, which has more limitations. If I have to use an F5 load balancer or other third-party products, Tanzu shrinks a little bit. It is not as mature as Red Hat OpenShift, which is more open to other products. I have an F5 load balancer, and I struggle a bit to integrate the F5 load balancer with Tanzu, whereas with OpenShift, it happens directly. For Tanzu, I have to have another layer on my load balancer, which is Avi. I have to use their services. Adding one more product into the environment brings some complexity, whereas OpenShift is very agile in nature. It adapts to all kinds of products that are not part of the same stack. So, I had no issues with that. I would rate OpenShift higher than Tanzu because OpenShift is a much more mature product.

It was straightforward. I had a perfect team with prior experience in OpenShift. They were able to do it without any hiccups. The community of OpenShift is very good. There are a lot of exchanges happening in the community space, which helped us in doing it in a seamless way. I would rate it a 5 out of 5 in terms of the ease of the setup.

We are currently using the open version, OKD. We plan to get the enterprise version in the future.

It is an excellent product. There are a lot of items that will be good to have in there, but based on the comparison with others and based on the kind of use cases I have seen, I would rate it a 10 out of 10.