Red Hat OpenShift Reviews

NetApp is our storage provider and we have a product called Astra Control Center. We can back up and restore our containerized applications that are running on OpenShift. We use it to create a disaster recovery site for our business-critical containerized application.

Our second use case is for cloud bursting. When we have fewer resources available on-prem, we can move some of our non-critical applications to the cloud.

Our production environment can be run on AWS or any other cloud where we've deployed OpenShift, while we have our test and development environments on-prem. Once an application is certified, it can be moved from development to the production environment using Astra Control Center.

The CodeReady Workspaces reduce project onboarding time. With my experience, I was able to deploy the OpenShift cluster to make development ready in one day, with all kinds of related post-installation configurations.

And CodeReady Workspaces also reduce time to market. Red Hat OpenShift provides its OperatorHub from which you can find all the certified applications that are readily available on the portal itself. It gives you a cloud catalog-type feature directly on the OpenShift console. Through that, you get a GDP that is already certified, while deploying any kind of application. That means they are made to run with your OpenShift environment. You don't need to do any research to make it work with OpenShift.

OpenShift also provides us with the flexibility of cloud-native stacks while still making it possible to meet regulatory constraints.

The most valuable feature of OpenShift is the security context constraint (SCC). The solution’s security throughout the stack is good. And security context constraints provide port-level security. It's a granular level of control, where you can give privileges to certain users to work on certain applications. That's a great security feature.

The solution also provides a lot of security features on top of a regular Kubernetes cluster, which you can control. For example, in the namespace of OpenShift, there are different kinds of access levels. If you have a development team, you can provide limited access so that a developer can only deploy your application. If you're running any business-critical app, you can restrict the users' access to that app.

Also, Red Hat provides advanced multi-cluster management. You can manage multiple clouds with one solution, and I'm happy with that.

One area for improvement is the documentation. They need to make it a little bit more user-friendly. 

Also, if you compare certain features and the installation process with Rancher,  Rancher is simpler.

I have been using OpenShift for more than two years.

I have found some minor issues related to pod networking in which some of the OpenShift pods were not performing well. To resolve that, I needed to do a reinstallation of the cluster. Apart from that, OpenShift is pretty stable.

The scalability of OpenShift is good, but a competitor like VMware Tanzu can run more pods on the same system or the same hardware. So there's a little room for Red Hat to make it more scalable.

For us, OpenShift is an enterprise-level platform. We have about 10,000 users and we have plans to increase our usage.

The best part is the support from Red Hat. If you face any issues you can get great support.

As a partner, Red Hat is a nine out of 10 for helping us create the platform we need.

Positive

The installation is very good. There are a lot of options with which you can deploy OpenShift and you can deploy it on different environments. You can directly deploy it on a bare metal server, or if you already have a VMware-based infrastructure, you can deploy it there. That automation is very flexible.

The initial setup is straightforward, but for a first-time user, it might be a bit challenging because there are certain prerequisites that you need to follow. But if you follow the installation guide and you're able to do all the prerequisites, it's very straightforward. It takes less than an hour.

I used the Assisted Installer and did the IPI installation for OpenShift. I had all the infrastructure ready and deployed one cluster on bare metal. Then I deployed the OpenShift cluster on AWS.

For deployment and maintenance of OpenShift, a team of 10 should be fine. They can handle the installation and the post-installation operations for your day-to-day tasks.

I did it on my own. 

I have tested VMware Tanzu but we didn't go with it because it comes in different flavors. If you want to use VMware Tanzu, for certain things, you need to buy another VMware product. For example, if you want to have pod services for your environment, you need to buy NSX. That's an extra overhead because you need a separate team that can manage NSX for you.

You need to follow the prerequisites for the environment and then proceed with the installation. There are different ways to do the deployment but you should do it the way that is most comfortable for you.

You can also deploy OpenShift using Ansible. If you want to automate the entire process of your OpenShift installation, including the server, network, and storage, you can opt for Ansible. That way, you will have end-to-end automation for your entire stack as well as OpenShift. That is good flexibility.

The biggest lesson I have learned from using OpenShift is that you can go with bare metal and you don't need to pay extra for the VMware Hypervisor. In terms of installation or manageability, it's simple. You just need to follow some guidelines and you will be good.

We use the solution to run our own software. Our software is different from the banking system, and it's mostly written in Java with a backend, an Angular frontend, MongoDB, and some caches.

I cannot compare what we had before to OpenShift because it was virtual machine provisioning, and we use OpenShift in the context of a read/write of our internal tech. We don't take an existing application and put it in OpenShift. It's part of the read/write process in Spring Boot. Overall, instead of taking two to three days to request a VM install, deploy, patch, and then put an application on it, we are down to approximately 10 minutes when using OpenShift.

OpenShift provides us with the flexibility and efficiency of cloud-native stacks while enabling us to meet regulatory constraints. We have tools, such as OPA, where we can define security requirements for the deployments for the different channels, and these checks are made during the admission of the pod so we are sure that any workload that goes through this gate complies with our requirements automatically. This guarantees that we do not deploy anything that breaches those requirements. The solution provides proactive security versus reactive.

OpenShift is very beneficial in the development time and our end product because it's easy to request new deployments, we can have different versions of the same software deployed by different developers, and they can iterate quickly without stepping on each other's feet. We save a lot of time because it's easy to create and destroy environments where everybody can work on different features without blocking each other.

OpenShift is based on Kubernetes and we try to use all the Kubernetes objects of OpenShift. We don't use features that are specific to OpenShift, except internal certificates for the services. The one feature that is missing from Kubernetes and that is really useful in OpenShift is the lifecycle of the cluster and the ease of installation. We use VMware and VMware integration internally with the OpenShift installer, which is very good. With OpenShift it's easy to spin up or scale out a cluster.

OpenShift's security throughout the stack and the software supply chain is good.

The defaults in OpenShift are favorable and secure. Red Hat usually takes a lot of time to ensure compliance with the CIS benchmark and by default, it's the most secure out-of-the-box solution for security.

OpenShift's security features for running business-critical applications are suitable.

The solution needs to support the new features in Kubernetes more quickly. For example, there are some Kubernetes features that we rely on that are not yet integrated into OpenShift, even though they have been available for six months. Another aspect that needs improvement is the console and the user interaction with the console itself.

I have used the solution for a total of five years and consecutively for the last two years.

OpenShift is really stable and works solidly as long as we do not make obvious mistakes. Any issues that we have encountered are usually caused by human error or application bugs.

Our clusters currently have between 32 and 36 nodes and we have had no scalability issues with OpenShift.

The technical support is not good. We don't have a technical account manager, which would help, but we're not at the scale to justify paying for one. We go through the regular support line, and usually, it takes one day to go back and forth to pass the first levels of support. They always ask standard troubleshooting questions. It's really painful until we reach the very technical people, but once we do, the support is good. What we don't like is the lead time to reach those people.

Neutral

I previously used Kubernetes from Canonical. Everything in OpenShift is more secure out-of-the-box. If we take a Kubernetes installation like the one from Canonical, everything is open, nothing is secure. We require a security person to look at the cluster and create secure settings. On the other hand, we have all the advantages of having Kubernetes because we get all the new features the day they are out, and Canonical is really responsive to having the newest Kubernetes as soon as it's out. 

The integration with VMware is not nonexistent, but not as good as OpenShift, in how we roll out. I have not used Kubernetes in three years but at that time, everything was done by hand. It lacked an integrated installer, unlike OpenShift.

OpenShift has several advantages over Kubernetes, one of which is the installation process. This process is much better integrated with VMware than Kubernetes, but it is not straightforward. We still need to understand what is required, especially the network layout and the addressing because once we make our selections and deploy, some settings cannot be changed. The solution requires careful planning before deployment otherwise the entire deployment may require scrapping and starting over.

The deployment process takes up to one afternoon but it can take weeks to understand our needs and to get the process right. The same decisions are required in deciding the best size for our cluster, or how to separate our environment, which can be difficult. We may want two active clusters for production, one in each data center, or two clusters in each data center. All of these architectural decisions come with time and experience.

When deploying, I recommend having a platform team of four to eight people who can cover all areas. This team should include one or two people from security, one or two people from infrastructure, one or two people from production who know how to handle alerts, and also some people from development. The platform team should consist of between four to eight people and cover all the customers within the company. Having a team of this size will ensure that all areas are covered, and if someone is unavailable, there is still somebody else to provide backup.

The implementation was completed with the help of a consultant.

We invested a lot of money in our current system, but now it would be more cost-effective to do things differently. We have reached the tipping point and in the future, it will be too expensive to maintain our current system. However, I believe that the money we invested was worth it and we got our money's worth.

I think it is a good idea to start looking at alternatives to Red Hat, perhaps a more open-source solution. This way we can save on licensing costs and have more control over our infrastructure. We get to the point where we can afford to pay skilled people to look at our code instead of paying for a license. OpenShift is really good when we need to start, but once we get to a certain scale, it becomes too expensive. It is more cost-effective to go with a cloud-managed Kubernetes if the organization is already on the cloud.

I give the solution an eight out of ten.

Red Hat as a partner helps create the platform we need but we pay for the support as part of the licensing, which is super expensive. Once we have the right technical person and solution architects, we have everything required to be successful.

I'm very passionate about Kubernetes and spend a lot of my spare time contributing to the project. It's something that I find very natural, but for regular developers or administrators, it can be quite new. There's a lot of education necessary for people to understand what Kubernetes is and how it will revolutionize their work. One thing I've learned is that we can never document or spend enough time training the end users. End users include administrators and developers.

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 OpenShift as an accelerator for our projects. We provide an environment for containerization. Our company has multiple clients using the infrastructure to build and test their applications.

We've both cloud and on-prem installation of the tool. For the cloud installation, we use the AWS cloud.

The quality of the product is good. There are no performance issues or any tools-related issues. We get excellent performance and application integrity. We use multiple internal applications, and they are integrated with OpenShift. Our end users are happy using the platform, and they are able to test everything using the OpenShift testing environment.

OpenShift provides good security throughout the stack and the software supply chain, and we use it in conjunction with Azure authentication. We haven't had any security breaches or issues with the tool. We don't run any business-critical applications with the product, but it offers good security and prevention. Overall, we're satisfied with it from a security perspective.

The solution is very reliable. We have excellent documentation, and we get good support for open-source products. If we need to learn new features or do new types of implementation, documentation is available. 

In terms of implementation, OpenShift is very user-friendly, which is an advantage. We are using it along with GitLab for implementing CI/CD pipelines. That's a feature that other products also have, but in OpenShift, we find it good.

Upgrades are easy. We could do upgrades with a single click. The GUI is very user-friendly. We are also very comfortable with the CLI.

We want to see better alerting, especially in critical situations requiring immediate intervention. Until we go to the dashboard, it can be challenging to quickly recognize that there's an issue for us to deal with. Therefore, a popup of the event or a tweaked GUI to catch our attention when it's alerting would be a welcome change. Everything else is good. We don't need any additional features. From the operations perspective, as an administrator, there is nothing concerning.

Red Hat has to improve its support. They should provide quicker and better support for issues with lower severity.

We've been using this solution for around two years. 

It's stable. The cluster is pretty stable. With version 3.11, we were having some issues, and it wasn't a pretty stable cluster. We had issues often on the backend nodes, but version 4.x is very good. We have been using it for more than one year. We have had multiple versions such as 4.7, 4.8, and 4.9, and now, we are into 4.10. We upgraded our staging cluster to 4.10, and that upgrade was very smooth. We had some issues, but we were able to fix them.

It's very scalable. We can see the cluster size we need. We can also scale down. So, scalability is good. The MachineSet feature in OpenShift is very good. It's user-friendly, and we can scale up and scale down as per our needs.

We have thousands of projects. So, many users are using this solution. We have around three production clusters and two development clusters. For now, we don't have any plans to expand its usage. Currently, the market is still in a stagnant state, and there is not any plan for expansion. If the number of users increases, we might increase the number of clusters.

The support people who join our calls or take care of the issues are technically strong. There is no doubt about that. They're able to find out the issue, and they give us a quick solution. If there is any bug, they coordinate with their engineering team and provide us a bug fix in the next version or internally to upgrade it. Overall, their technical support is good, but for the lower priority cases, their response is not very satisfactory. If we open a case with severity 3, 4, or 5, we don't see an active response. We get a good response only for severity 2 and 1. I would rate their support an eight out of ten.

Positive

We were using Kubernetes. We switched to OpenShift because we wanted an enterprise-level usage tool. So, we needed a more stable product.

We chose OpenShift mainly because we get good vendor support. In case of any issues, we can easily collaborate with the vendor to get a proper solution. From the operations perspective also, OpenShift is good. That's also the main reason why it's being used here.

For the installation of OpenShift, we used the IPA method of installation in AWS. It's pretty straightforward and easy. It isn't complex, but you have to go through the documentation. You have to read the documentation before implementing it. Overall, the initial setup is good. There isn't any complexity in the installation.

We have a good procedure to implement it. We just followed our internal procedure and the OpenShift document, and we were able to install it.

When we deployed a cluster, it took us about one and a half hours to bring the cluster. It took us around two days to complete the setup. After installing OpenShift, we needed to do some peripheral installations, such as authentication, creation of objects such as resource quota limitations, creation of templates, etc. In a maximum of two days, we were able to bring the cluster back into the required state.

In terms of maintenance, we have five clusters that are being taken care of by four people. My team doesn't only take care of OpenShift. We also take care of GitLab, so that also takes some resources. Overall, four people are taking care of five clusters.

I didn't work on its deployment. For the on-premise installation, my colleagues worked with the vendor to implement it. We got help from the vendor. 

We considered VMware Tanzu. They are still in the pipeline. We are planning to implement VMware Tanzu inside our environment. OpenShift is very good, but we are considering VMware Tanzu because we already have a good VMware environment. We thought of using that VMware environment also for the containerization application. That's the reason for considering VMware Tanzu.

I would recommend OpenShift to others because of its stability and usability. We have been promoting it to multiple clients inside our organization.

We use Red Hat Linux and Ansible. Red Hat Linux and OpenShift have good integration and support. We haven't used Ansible much. We have only used Terraform with OpenShift. Ansible is good. It has good integration with OpenShift, but we haven't used it much. 

Red Hat is good at creating technologies. They consistently improvise their products. There is a massive difference in handling and performance between OpenShift version 3.x and version 4.x. In terms of stability, they have shown enormous improvements. So they're good at improving their products.

OpenShift provides the flexibility and efficiency of cloud-native stacks while enabling us to meet regulatory constraints, but our implementation at this level is basic. We haven't implemented any strict rules or compliance setup.

I would rate it an eight out of ten.

I'm currently engaged in developing containerized microservices applications, managing thirteen modules within an OpenShift environment. These modules collectively handle automated payment processes for various services. My role involves closely monitoring these modules on OpenShift, ensuring optimal resource allocation such as storage and CPU usage. Additionally, I'm tasked with implementing solutions for scenarios of resource overutilization, including autoscaling capabilities to accommodate high traffic periods efficiently. I also focus on scaling down resources during low-traffic periods to optimize cost and performance.

OpenShift has significantly enhanced and streamlined our organization's application development and deployment processes. It offers more than just Kubernetes clusters, providing additional features like the Dashboard, which greatly simplifies tasks for developers. Moreover, OpenShift adds an extra layer of security, ensuring that applications run securely with features like hashing upgrades.

It offers a vast repository of images and tools tailored for deployment and application development. This rich ecosystem makes deployment and performance optimization much easier compared to our previous methods. Additionally, by opting for OpenShift, we gain access to comprehensive support from their expert team.

It streamlines our development and deployment processes through automation. From development to deployment, all processes are automated, providing efficiency and productivity gains. Developers can submit their changes for approval, and once approved, the deployment to production can proceed without requiring manual intervention. This streamlined workflow not only makes the process easier but also enhances productivity across the team.

The integration capabilities of OpenShift with other platforms and services have greatly enhanced our workflow. When you opt for OpenShift, whether through a subscription or by installing it on your servers, you gain access to a comprehensive support system provided by Red Hat. OpenShift features a marketplace with a wide array of operators, facilitating seamless integration and deployment of various services. For instance, popular services like Elasticsearch can be easily integrated into the cluster directly from the user interface and dashboard, making the installation process much simpler and more user-friendly.

The broad support for multiple languages and frameworks in OpenShift has positively impacted the productivity of our development teams. We've observed significant improvements in our tools and team collaboration since adopting this platform. As we continue to enhance our processes, it's evident that most of our development team members are actively engaged and contributing, particularly our dedicated engineers and architects.

When comparing the efficiency of OpenShift Container Orchestration to other solutions we've considered, such as Kubernetes, we find that OpenShift aligns well with our existing architecture and team structure. Our approach resembles the architecture of OpenShift, with a team leader overseeing multiple workers.

One of the most valuable features of OpenShift for our operations is its auto-scaling capability. This feature is crucial for handling high loads or traffic spikes in our applications. With OpenShift, we have the flexibility to scale our applications up or down as needed, providing a significant benefit to our operations.

OpenShift offers robust tools for monitoring application traffic, allowing us to analyze client requests and other business-related metrics. This enables us to effectively manage our applications and make informed decisions to optimize performance.

An enhancement to consider for the future might involve incorporating a comprehensive solution for CI/CD tailored specifically for OpenShift.

I have been working with it for three years.

I would rate its stability abilities eight out of ten.

I would rate its scalability capabilities seven out of ten. More than three thousand users use it daily.

We are experiencing dissatisfaction with the technical support as we often receive delayed responses when raising questions. I would rate it five out of ten.

Neutral

We previously worked with Kubernetes cluster, but we switched to using OpenShift, as advised by our architect. This change is aimed at achieving greater scalability and stability for our product, as we've encountered challenges with our setup at the time.

The initial setup was relatively straightforward.

We manually installed the deployment three months ago, utilizing grid protection systems. I have been handling both development and production environments. In the development phase, I build deployments from scratch, while for production, I collaborate with another vendor. I manage all steps of installation and ensure smooth migration to the production environment.

The cost is quite high. I would rate it eight out of ten.

Overall, I would rate it seven out of ten.

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.

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.