Red Hat OpenShift Container Platform Reviews

Our client deployed OpenShift on a bare-metal server, and they use it to offer their customers a platform-as-a-service solution with metered billing. It's pay-as-you-go. We are currently developing our own platform. For the most part, we have enough developers, but we'll go to Red Hat when we need support.

OpenShift is an improvement over legacy monolithic applications. With OpenShift, our clients can see the new features quickly, and developers can get any software they need from the Red Hat Marketplace. It has improved our product development and the existing workload on business material applications running on OpenShift. It has improved the performance of our company's IT department. 

OpenShift complies with the security center, where the CS image is hardened by default. OpenShift is very secure. When there are updates, OpenShift will update all the patches necessary throughout the entire cluster platform. It takes care of that easily, reducing many administrative tasks. Using this product improves our compliance code significantly.

The pipelines in OpenShift are handy for developers to build and automate things quickly. It's easy to bring things online. Options are helpful for the customized solutions we can do with this product. Overall, the automations are well aligned with OpenShift. That's what I see.

OpenShift's code-ready workspaces reduce project onboarding time by about 70-plus days while reducing time-to-market by around 50 percent. 

The operating system has a live update and is more secure than any other. It's made for Atomic OS, a lightweight OS new to the market. I also like the source-to-image capabilities. The customer can directly deploy their applications from the repository. It's a highly flexible and easy way to deploy into production. 

It's a simplified network for exposing their application to the outside world. Red Hat has good built-in oversight, where it monitors the cluster performance and records everything built inside the cluster besides OpenShift. Of course, Red Hat is a pioneer in this kind of auditing. 

Telecom clients can use OpenStack as their private cloud to access secure resources on demand. When they deploy to OpenShift, it's easier for them to have a cloud-like field on their own data center. OpenShift and OpenStack are integrated. It's an ideal combination. The infrastructure created in OpenStack is a robust private cloud solution. If the developer wants to consume resources within their organization per the utilization, OpenStack is the right platform for building their private cloud.

In terms of innovation, features, and functionality, a public cloud has much more than OpenStack by itself. I prefer OpenShift on AWS or Azure Cloud. That has made it easier for the customers to benefit because they don't need to worry about their managed solutions anymore. It's the customer's choice to manage services through OpenShift or on-prem. OpenShift can be run on all platforms, including VMware, public, private, etc. It's a great solution from a consumer choice perspective. 

The codes are customized and fixed only for their own environment, so it's more secure, but we cannot assure the client's security. However, the code is validated, and Red Hat support will address any vulnerabilities or security issues that arise.

The support costs are too high. 

I've used OpenShift for the last two years.

OpenShift is a highly stable product if you're using it as a managed service. 

OpenShift is scalable. 

I rate Red Hat support nine out of 10. 

Setting up OpenShift is fairly straightforward. It takes about a week to plan and another to deploy, so two weeks max. 

They can reduce prices because Kubernetes is open-source and freely available to customers. The license cost is for deploying on-prem, so it's costly to go to a client's location to deploy things compared to open source. If they reduce the cost, more customers will choose OpenShift.

I rate OpenShift Container Platform 10 out of 10. This is a great product. Red Hat has been in the field for more than 25 years. Each product they release is more innovative and cutting-edge. 

I am the platform engineer, and the platform serves a function for end users by allowing them to deploy their apps based on their application use cases.

The most valuable feature of this solution is its scalability on demand, which allows for potentially lower costs, and Built-in resiliency. Those are the three most important ones that spring to mind.

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.

I have been working with the OpenShift Container Platform for two months.

We use version 4.9, and our legacy version is 3.9.

OpenShift Container Platform is quite stable.

OpenShift Container Platform is highly scalable.

I have more data regarding the number of net spaces and the number of apps that are tied to it, rather than how many individuals are on the receiving end of such applications which would be considerably more difficult. I would say more than three persons for each application, which is definitely driving the number near 500. This would be an approximate number.

I would rate the technical support a 10 or 11 because, in my personal experience, they are always going above and beyond to deliver the solution.

They are very caring about their customers.

Because the platform I'm working with was inherited, I wouldn't know how that procedure works here. I have, however, performed a few deployments in a considerably smaller context. 

You have at least three distinct techniques to perform that deployment using OpenShift, as well as a few of IPIs and UPIs. 

When I approached that scenario, I was thinking in terms of UPI, which stands for user-provided infrastructure in a non-homogenous, domestic cloud environment, a tiny simulated cloud environment. 

It wasn't simple, and it took a few tries to get a functional cluster structure with various control planes and many worker nodes. 

It's a difficult response to a hard subject, in my opinion, but, it is not an extremely simple or out-of-the-box solution.

The deployment took about two hours if we count the successful attempt once I had my preexisting issue sorted out. 

The upgrade would depend on the scale of the cluster. It can take a couple of minutes per node, so it would depend on the number of nodes.

In terms of the cluster that has workloads that are on production, you need to make sure that the workloads are not experiencing any issues.

I have a vague understanding of it but keep in mind that enterprise pricing differs from, I don't know, people or smaller businesses approaching them.

It largely depends on how much money they earn from the application being deployed; you don't normally deploy an app just for the purpose of having it. 

You must constantly look into your revenue and how much you spend every container, minute, or hour of how much it is working.

I wouldn't have access to that information within my company, therefore I'd assume it's in plus.

As far as I understand the situation, while this solution was inherited, the outstanding technical support is one of the main reasons it was chosen over other solutions.

I would definitely recommend having the vanilla experience because, contrary to popular belief, OpenShift is not Kubernetes; it's actually written on top of Kubernetes and adds an extra value of authentication, auditing, and logging on top of that, but it does require a familiarity with Kubernetes to properly utilize its capabilities. 

After being acquainted with Kubernetes, I believe it is worthwhile to dip their fingers and brains into the distinctions that OpenShift provides in contrast to other basic Kubernetes implementations.

I would rate OpenShift Container Platform a seven out of ten.

It is really expensive. That is not something you would employ unless you had a strong business case for your application. That is, not in terms of the enterprise version.

You may use our OKD, which is a community version we provide, which is less expensive. However, it is not a supported version of OpenShift; it is only supported within the community. However, because the OKD community is small, there is a low likelihood that someone would respond to your inquiry if you run into problems and need to locate answers elsewhere.

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

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

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

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

I have been using OpenShift Container Platform for four years.

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

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

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

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

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

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

We have been developing telco cloud-native applications that need to run on Kubernetes. In our deployments, we've used both, Kubernetes and Red Hat OpenShift.

The primary benefits we've observed primarily revolve around the security aspects.

In comparison to Kubernetes, OpenShift offers additional features, essentially making it an extended version with enhanced capabilities. It performs better, offering approximately thirty percent more than Kubernetes.

The most valuable are security features, particularly when operating in the cloud. It is considered a necessity, especially in our industry, given the critical nature of the infrastructure.

We've encountered challenges when transitioning applications between these environments. For example, an application that runs smoothly on standard Kubernetes might face compatibility issues when ported to OpenShift. This variation has posed some challenges for us, and it's something we're actively addressing. I think it's important to create a plan to ensure seamless compatibility between applications running on vanilla Kubernetes and those on OpenShift. This involves delineating features unique to each platform, such as those specific to vanilla Kubernetes and the additional capabilities offered by OpenShift. The goal is to make it feasible for an application designed for a more basic Kubernetes environment to run smoothly, providing valuable flexibility.

The introduction of OpenShift slowed down our development life cycle due to compatibility issues.

I have been working with it for four years.

We transitioned from Kubernetes to OpenShift because our customers specifically requested it.

Overall, I would rate it seven out of ten.

We primarily use the platform to deploy microservices for all kinds of stacks and to deploy databases. Some of our databases are cached, and we can containerize them. Our entire infrastructure relies on OpenShift because we deploy all our applications to it.

The automatic scaling of applications has been a great feature for us. The solution also provides flexibility; we can deploy small or paid digital microservices with many features.

Autoscaling is an excellent feature that makes it very simple to scale our applications as required.

The tool's console looks fantastic, and the UI is intuitive; we can easily check port health, locks, deployments, and services.

Another great feature is monitoring, as we can integrate and monitor logs.

We use the product's CodeReady Workspaces, and they reduce project onboarding time. We have automated templates and use those scripts to create projects and clusters within OpenShift.   

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. 

We've been using the solution for three years. 

We faced stability issues with the console; a problem we often see is the UI will freeze, and only the command line will work.

The scalability is as expected because it works according to the conditions we set; we can impose limitations on the ECP to stay within the budget if necessary. We have over 100 developers using OpenShift, and 500-700 deployed microservices.

I have yet to contact tech support; a different team in our organization deals with them.

We previously used Kubernetes and installed it on our Compliant Centers, but the infrastructure was complicated to manage as we had so many. So we moved to cloud-based Kubernetes and then to OpenShift because the latter provides more features like a one-console UI, user-friendly installations, and better support, security, and networking.

The initial setup was not particularly complex, but it wasn't easy either. There are good guidelines available to make the deployment steps more straightforward, and setting up clusters is where it gets tricky.

As there is no on-prem infrastructure to set up, the deployment is very quick, and we can put up a cluster in minutes.

We deployed primarily with the assistance of a consultant. 

I'm unfamiliar with the product's price or how it compares to the competitors.

We evaluated Kubernetes and Pivotal Cloud Foundry. Those and other platforms on the market are not up to the same standard as OpenShift; they have different installations, UIs, and limited security features.

I rate the solution nine out of ten.

Regarding automation, we don't build up any pipelines in OpenShift; we have our own tools to automate build processes and then deploy them to the platform.

We didn't consider building our own container platform as it would be difficult. 

My advice to those considering OpenShift is that it's user-friendly, flexible, has robust security, and features are frequently updated. Red Hat provides good documentation, so the solution is easy to learn and adapt to your use cases.

We can deploy microservices on the fly. The time to market has improved for our organization. If any issues are found or any incident is reported, fixes or hotfixes can be done within a fraction of a second. These KPIs are the improvements.

In terms of security, it supports user management. An authentication and authorization solution is embedded in that. There is also certificate management in terms of how it rotates the certificates and the kind of TLS mechanism it uses for the end-users as well as for the communication within a cluster. It also allows our images to be scanned before deployment.

OpenShift comes with a lot of marketplace operator-based solutions. It also allows any open-source operator-based solution. It could also be a Helm Chart-based solution for deploying any cloud-native application or workload.

OpenShift is much better than others as an upstream project for Kubernetes. It also has certain features that are not there in any other flavor of Kubernetes. For example, Source-to-Image (S2I) is a wonderful feature in OpenShift where your code can be in the source repository. It can be built and deployed with a click of a button. That helps the developers' community to deploy their code and see the results on the fly.

In OpenShift, there are a lot of things that are good as compared to any other Kubernetes flavor. The console or the GUI of OpenShift is awesome. You can do a lot of things from there. You can perform administration tasks as well as development tasks. 

The RBAC user management that comes packaged with OpenShift is not there in other Kubernetes. That's a very nice feature. 

The upgrade mechanism is also very good. The upgrades are pushed by Red Hat, and with just the click of a button, your OpenShift cluster gets upgraded. That is another very nice feature. These are a couple of things that I like.

A lot of improvements are required in OpenShift when it's deployed on a public cloud such as AWS, GCP, or AKS. 

OpenShift has certain restrictions in terms of managing the cluster when it's running on a public cloud. For example, identity and access management integration with the IM of AWS is quite difficult. It requires some open-source tools to integrate. This is one area where I always see room for improvement. 

In addition, the RBAC access is only controlled by the OpenShift internal mechanism, whereas the authorization part can be handled by any public cloud. We are already managing and maintaining users in the cloud environment. So, a repetitive or duplicate RBAC mechanism is not required. 

I have been working with this solution since 2018. It has been more than four years.

It's a stable solution. However, most organizations are lagging in upgrading the versions because of various reasons, such as business downtime and the risk involved behind that. If you don't upgrade it on time, then there will definitely be bugs. It normally doesn't create many issues, but we have had instances where when we go to the Red Hat product support team, they always mention going for the next upgrade or the next possible upgrade so that a bug is completely removed. However, it's not always possible to do that. So, stability-wise, it's quite stable, but no product can be perfect. In the version that we are running, there are a couple of bugs, and we have to live with them, unless and until we upgrade to the next version.

Because it's on a public cloud, it's very easy to scale up.

In terms of its users, we have close to 100 users. There are a couple of DevOps engineers in that, and then there are administrators who manage and maintain the cluster. The rest of them are developers. These are the primary users.

It's being used quite extensively, at least in two of our markets. I have no idea about plans to increase the usage of this product, but I also don't see any reduction in its usage in the near future.

Their support is very good. We have a premium subscription for our organization, and we get support whenever we need it. It's quite good. It's the backbone of this product. I would rate them a nine out of ten. Sometimes, the support professionals work from different geographical regions, and when there is a shift change, we lose some time. It happens rarely, but it has been a cause of concern a couple of times.

As a partner for helping us create the platform that we need, I would rate Red Hat an eight out of ten. In terms of support, they provide all the required commands, code pieces, or files required to troubleshoot the issue. They also provide support during any new installation or upgrade.

Positive

When I started working on this project, OpenShift was already there. I don't know if and what it was migrated from. In the accounts that I'm handling, we had OpenShift, and applications were containerized and migrated to OpenShift.

We use other Red Hat products. We use Red Hat OpenStack, and we also use GlusterFS storage from Red Hat, which comes as a part of OpenStack. Apart from that, most of the virtual machines are already using RHEL. OpenStack, for us, is on a private cloud. It's not as friendly as AWS public cloud. Integration-wise, it's seamless, but if we want auto-scaling at the OpenStack level, it's not possible for us. 

An advantage of using multiple Red Hat products together is in terms of the support we get from them. That's very good. If we consider any Kubernetes flavor running on any public cloud, getting support on the components we have deployed is difficult, but Red Hat supports that. Whatever we have deployed, they can provide support on that. The support provided by Red Hat is really great, and that's why they're asking for a premium cost for that.

It was already done before I came, but I know that it was done using Ansible stack and Ansible code. Its deployment is quite straightforward. The 4x versions of OpenShift are very easy to deploy. The older 3x versions were quite difficult to deploy, but in the latest versions, especially on a public cloud, it manages everything. It spins up your cloud virtual machines, installs OpenShift on them, and provides you the endpoint to access it.

If the Ansible code or scripts are available and ready, on a production system, it takes about one hour to one and a half hours. It also depends on how many virtual machines you require to install OpenShift.

Its price is a bit high because it's a premium product, but as long as the business is ready to pay for that, it's okay. 

I would recommend evaluating the product thoroughly for your requirements. That's because OpenShift comes with a lot of bells and whistles, and most organizations don't need that. It also comes with auto-managed components. If you are looking for less-managed components on a Kubernetes cluster, then Red Hat OpenShift is the only answer.

We didn't consider building our own container platform. There are different flavors available for Kubernetes. We use OpenShift, EKS, AKS, and GKE. Even OKE is coming up. It depends on what different markets of our organization prefer and what is cost-effective for them.

Overall, I would rate it a nine out of ten because we are quite happy with it. There are a couple of restrictions in terms of managing clusters on a public cloud, but other than that, it has a lot of inbuilt components, which are helpful for managing the cluster better.

We have working nodes in the OpenShift Container Platform, we have six working nodes and we have a master working node. We have a Jenkins pipeline to operate our deployment and, CI/CD operations. We create some pipelines to deploy the code to the containers and those containers activate on OpenShift Container Platform ports or working node ports.

We had old-fashioned programs before switching. We started to create a new architecture for our developers. After generating our Java framework, we were looking for a new platform to run our systems. For our business clients, we need flexibility, and scalability, while we are searching the environment, because of the regulations. We need some private cloud options, and cloud vendors did not have private options.

I have found the ability to scale up is most valuable. If you do not have any hardware limitations, you can scale up during your busy timelines. It is an excellent tool so you can deploy these products to any of the public clouds. If the regulations allow you, it is straightforward to deploy your codes to another public cloud or another platform. OpenShift Container Platform gives you an opportunity to be flexible.

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.

I have been using OpenShift Container Platform for the past four years now.

The scalability is excellent. Last year we had some hardware limitations, we reached the limit of our hardware platform. After we enhanced our hardware we have not received any additional alarms.

Technical support from my experience is the middle of the road.

Neutral

The initial setup can take twenty-five minutes if it is a large stand-alone monolith. We have six steps in our pipeline. It changed to application certification, for little microservices, it takes approximately two to four minutes. We have six administration users who arranged the pipelines and port visualization for port monitoring.

We currently have an annual license renewal.

I would recommend using OpenShift Container Platform, giving it a rating of eight out of ten.

We use it mainly for the retail space.

Everything is packaged into OpenShift Container Platform, whereas with Kubernetes, you have to create many operators. With OpenShift Container Platform, you just have to point and click.

The setup process is not great and could be better.

We have been using this solution for about two years, deployed both on cloud and on-premises. We can fire up an OpenShift cluster in Amazon. We are using the latest version.

It is very stable and solid. 

It is a scalable solution, and we have more than 500 users. We have about 15 people that manage all the different clusters.

The setup of OpenShift Container Platform is a bit complex when you set it up for the first time, but it is good after setup. The first time we deployed, it took about two days, but since we have mastered the solution, it no longer takes as long. We did not use any integration. Because we buy the Red Hat licenses, they just give us the green light.

We have seen a return on investment.

It costs about $10,000 for a three-year license.

We tested Swamp, Rancher and the US version of Kubernetes before OpenShift Container Platform.

I rate this solution a nine out of ten and recommend it to others.

Our company deploys the solution as a container platform that balances node availability and load. 

The most valuable feature is that the solution can be deployed in the cloud which removes the expense of a server. Everything you need is provided in the cloud where you can make clusters, add masters and worker nodes, and install ports. 

The solution includes an integrated file agent and a control center director that embeds within the release. It is much easier to configure the install or file agent through the GUI than having to work on command lines in a CLI. 

The solution does not work on a route-wise NFS.

I have been using the solution for two years. 

The solution is more stable than others because it allows for redundancies. Data can be stored on the PV and transferred to many worker nodes. 

The solution is easily scalable by joining worker nodes with masters. 

For example, your customers increase so you want to jump your worker nodes from four to forty. You simply install the solution, join worker nodes with masters, and create a larger cluster of servers within a matter of minutes. 

I serve as a DevOps expert for my customers and don't have the need to contact support. 

Our company used Docker but switched around the time it was acquired by Mirantis. 

The initial setup is straightforward. If you have an adequate amount of CPU and memory, then setup can be as fast as eight minutes. 

I rate the initial setup a nine out of ten. 

We currently use both Kubernetes and OpenShift. 

It is beneficial to be aware of Linux or Unix concepts when working with the solution and managing clusters. 

I rate the solution a ten out of ten. 

Our customers value the monitoring and logging functionalities which are also our most valuable features. 

Our customers like the service mesh, so we integrated these to improve customer satisfaction.

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.

We have used OpenShift Container Platform for the past four years. We are using version 4.10, and it is deployed on-premises.

It is a stable solution. We have not had any issues or found any big bugs. However, even though it is stable, we observed that the latest versions of this solution are usually less stable than the previous versions.

Therefore, if I were to rate the stability, I would give it a six out of ten because there are a few minor issues in the latest version.

OpenShift Container Platform is great from a scalability perspective. To my knowledge, there is no limitation when adding many compute nodes in OpenShift. It just requires a lot of hardware since we use on-premises at my company. You will need to increase the capability of master nodes if you want to add worker nodes.

I will rate the scalability a six out of ten.

Technical support from Red Hat is very good. They are proactive and always reply accordingly, depending on the tickets' priority. We never have any issues with the support. I will rate the technical support a ten out of ten.

Positive

The initial setup was very complicated. It took us about a week to deploy a basic three-master and a two-worker node cluster. I was also not aware of the OpenShift documentation at the time.

From an administrative perspective, it is difficult for new people to understand. A few coworkers from different backgrounds who moved to use OpenShift found it challenging. However, it was not as difficult for me because I am familiar with OpenShift.

I rate the implementation experience a five out of ten.

I don't know the exact licensing costs as I never purchase licenses for my organization.

I rate this solution a seven out of ten.

Regarding advice, it depends on the use case and what kind of platform a company wants. For example, if they want something on Kubernetes with at least basic amenities, like logging and monitoring and similar things out of the box, then OpenShift is good for them. But, if they want to modify the Kubernetes how they want, it is not a good solution because it is not flexible. OpenShift Container Platform gives you a lot of features out of the box, but you cannot modify it. So, if they want to use Kubernetes how they want, then the open-source Vanilla Kubernetes is better for them than OpenShift.