Red Hat OpenShift Container Platform Reviews

As an IT service provider, we work on enterprise technologies for our customers.

We have multiple customers with multiple domains, but the majority of our experience is in the banking and telecom sectors. In banking, they're using the OpenShift platform for their microservices-based requirements, and similarly on the telecom side, they are using it for the microservices-led solutions.

We started with the on-prem deployment of OpenShift Container Platform, version 3.2. But currently, we are also helping our customers to migrate to 4.x and to cloud solutions. The plan is to move to a cloud version, strictly on AWS. We are exploring the OpenShift Container Platform cluster, and ROSA (Red Hat OpenShift Service on AWS) the latest one with the managed services. By mid-2022, we'll probably be on cloud with this.

OpenShift eliminates distractions so that we can focus on innovation and other things. It completely removes overhead for the developers in terms of managing the orchestration of Kubernetes container clusters. It provides all the built-in features for managing these requirements. As a result, our team is more focused on development and on innovations in the underlying services. With microservices or applications that are deployed on OpenShift, they are able to focus more with the business requirements and innovate by further optimizing efficiently, utilizing the resources at a Kubernetes level.

Some of the primary features we leverage in the platform have to do with how we manage the cluster configurations, the properties, and the auto-scalability. These are the features that definitely provide value in terms of reducing overhead for the developers.

Also the Kubernetes cluster management or orchestration is provisioned through the UI and the CLI.

We are using the Red Hat OpenStack OpenShift Platform. It is much faster in terms of deploying the cluster. As of now, our experience rolling it out is more on the on-prem, but I think with the 4.0 version there is a little bit of a change regarding the way it is deployed, either using the installer base or user-driven installations. It takes a couple of days just to roll out the entire cluster and configure it so that it is ready for the applications or the services to be deployed on the cluster.

The robustness, the availability in terms of resilience, and the service availability with the multiple cluster nodes configured automatically, is pretty good. Even if load balancing is required across multiple clusters with the SDN network, it's pretty good. We haven't had many issues when it comes to robustness. We are happy with the performance provided.

From our experience on the on-prem, we know that there are 10 layers of security provisioned by the OpenShift platform, starting from the kernel level, and including the clusters and the container level. That definitely helped us to achieve a lot of enterprise security requirements in terms of accessibility and managing the infra part or the cluster part.

For running business-critical applications, the solution's security is pretty good. We are able to achieve consistent efficiency and availability for all our critical service requirements, when spanned across multiple DCs with the load balancer and DR solutions. We don't have to spend much on it, once we orchestrate the cluster with the proper configurations. At that point, everything is taken care of automatically.

At the service level, I don't see a very granular level of security as compared with the container-based clusters. It is at the Kubernetes level, not at the service level.

Also, when I compare it with the other container or Kubernetes technologies, we have pretty good documentation from OpenShift, but with the recent trend of cloud-native, fully managed serverless services, I don't see much documentation about how a customer should move from on-prem to the cloud, or what is the best way to do a lift-and-shift. Even if you are on AWS OCP, which is self-managed infra services, and you want to use the ROSA managed services, what is the best way to achieve that migration? I don't see documentation for these kinds of use cases from Red Hat. There is some room for improvement there.

We have been using OpenShift Container Platform, as an organization, for the last three or four years.

The stability is pretty good. The industry has been using these enterprise solutions over the long term and we haven't heard of or seen any issues with stability. Of course, it depends on the way you configure it or manage it. But given best practices, the stability is pretty good.

The solution gives us the flexibility to start with a small number of nodes and to scale it to the maximum number of nodes. As of now, we haven't gone beyond whatever the limitations are, in terms of the number of clusters or nodes, within OpenShift. We are well within the limits and are able to achieve our requirements. That aspect makes it more flexible.

Scalability is definitely one of the positives with OpenShift, where you can have a distributed cluster across multiple DCs or multiple Availability Zones with AWS. The only thing we don't see is much documentation. If we want to maintain Active-Active disaster recovery or hot and warm availability requirements, even in on-prem, how do our clusters scale across different regions or different availabilities? And how do I manage the internal cluster storage being replicated across multiple clusters? How does that work, and how do we prove it? That's another use case where, when it comes to documentation, there is a little gap.

But overall, scalability is pretty consistent and achievable with OpenShift.

I'm not involved much in post-production support. Usually, it is the customer team that gets into those kinds of requirements. But what I heard from our customers is pretty good, in terms of the support provided by the Red Hat. We know that they have a very good enterprise support team and provide support fairly quickly for technical issues.

On AWS, we have seen they have OCP-dedicated infra, which is completely managed by Red Hat. Now with ROSA, where AWS and Red Hat are both managing it, we are expecting a similar kind of support from Red Hat.

Whether Red Hat acts as a partner with our customers depends on the customer. Most of our customers use Red Hat enterprise support for technical issues with OpenShift Cluster Platform. But they don't get deeply integrated with Red Hat in terms of exchanging ideas or innovating new solutions. But Red Hat is always providing its innovations and doing research into new products. That has definitely helped our customers.

We embarked on OpenShift as our first enterprise container technology.

There are open-source-based Kubernetes services provided by AWS and there are a number of cluster-based solutions available. But what Red Hat and OpenShift did was that they packaged all of their solutions within their platform so that it provides added features. For our finance or banking customers, adopting an open-source solution is challenging, but the enterprise-grade support from Red Hat makes it much easier for them to adopt the OpenShift cluster.

As for building our own container platform, initially we tried with Dockers, but when we compared other Kubernetes cluster technologies to OpenShift we found that OpenShift is a much better solution in terms of the features.

With the on-prem solution, with OCP, where you have control of your infra, I feel the setup is straightforward, because you know OpenShift 4.0, or other versions, and how to install it. You have the resources and the skill sets and it is easy to just start with that part.

But ROSA is a very new approach, with the fully-managed and serverless cluster. I feel there are some gaps there because you don't have control of infra provisioning. AWS and Red Hat directly provision things once you provide the configurations. But if a customer wants to use a fully managed service with some level of customization, we don't see how we can easily achieve that.

On average, if it's a single-cluster deployment for five nodes, it may take three days to get the infra up and running. And then, to do all the configurations and get the applications deployed, it probably takes another one or two days, including the testing and readiness of the infra. So a total of about five days is the optimum timeline to get a single cluster up and running with the services deployed in it.

As we are exploring the cloud migration side of things, we definitely have a deployment plan where we use the templates, including Terraform templates, when it comes to infra and core provisioning. We then have a clusterized deployment as a basic migration approach or a phased approach. We leverage tools like the Migration Toolkit from Red Hat itself and some AWS tools which are relevant if there are challenges with agent installation and the like.

We have seen return on investment from using OpenShift. The TCO is much better, comparatively, over the course of three to five years. We have seen a reduction in infra and cluster management operational costs. These are some of the aspects where we have definitely seen a return on investment.

OpenShift with Red Hat support is pretty costly. We have done a comparison between AWS EKS (Elastic Kubernetes Services) which provides fully managed services from AWS. It's built on open-source-based Kubernetes clusters and it is much cheaper compared to Red Hat, but it is a little expensive compared to ECS provided by AWS.

Initially, we had this interim state where we wanted to move as a lift-and-shift, meaning we wanted to move OpenShift to OpenShift. We had three choices: OpenShift Container Platform, the OpenShift dedicated platform from Red Hat itself, and ROSA with the fully managed services. For lift-and-shift, we wanted to maintain an as-is state and made a decision to go with AWS OCP, which helps us to control our infrastructure and deployment requirements, while maintaining the as-is state. Price-wise, this option is less than ROSA. In ROSA, we would need to pay the cost for the underlying AWS resources we would be using, plus a nominal cost to Red Hat for managing every cluster and every worker node.

There is no doubt about things, feature-wise. In terms of scalability, availability, stability, robustness, OpenShift stands out. It's the cost and support factors which make the decision a little difficult.

If a customer is looking for a fully controlled or fully managed container technology, OpenShift is definitely a choice for them. But there are other services available, like AWS EKS, which come with similar kinds of services. It depends on if you need a deep-dive solution: Do you want to maintain your own infra or do you want fully managed services? And do you want to leverage other OpenShift cluster services? But OpenShift is the choice.

We don't use the full-fledged automated services for OpenShift clusters as of now, although we do use a few of the automated services. What we are using currently is sufficient and it helps us to meet a lot of audit and telemetric requirements.

In terms of using it for cloud native stacks and meeting regulatory constraints, we are still exploring that. We are currently looking at the AWS OCP and ROSA platforms. ROSA provides flexibility in terms of installations and managing the entire infra. ROSA is completely managed by automated serverless services, where you just provide the initial configurations for the kind of a cluster you need and it automatically provisions the infrastructure for you. Whereas with OCP you have control over the infrastructure and you can play with your cluster orchestrations, configurations, et cetera. In these ways, with the cloud services, we do have flexibility, but the cost factor may be a differentiator in terms of the on-prem and the cloud versions.

We definitely plan to use the CodeReady Workspaces, but we are not there yet. The idea is to move on to the AWS Workspaces.

Overall, I would rate the solution at nine out of 10. It has everything. For me, it is not a 10 because the support and the pricing costs stand out.

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

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

The price needs to be improved in OpenShift Container Platform.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For the majority of use cases, we're actually building APIs for both the enterprise API and also OpenAPI. It's mainly for integrations for the backend. We implement the system for the customer.

It's deployed on a private cloud and on-prem. We are using version 5.8.

The banking transactions, inquiries, and account opening have been the most valuable.

The monitoring and logging could be improved. I think it would help developers in terms of provisioning the database and the whole development lifecycle.

I have been using this solution for two years.

Technical support is standard.

Initial setup was fine. If it's set up on-premise, it takes longer, maybe about four or five days. We actually deployed it on the cloud once using IBM. That takes a shorter amount of time because it's a managed service.

We used a consultant. 

I would rate this solution 8 out of 10.

If you care about your performance and the support, I would recommend it for enterprise mission critical applications.

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

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

OpenShift Container Platform needs to work on integrations. 

I have been using the solution for two years. 

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

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

Red Hat offers good technical support. 

Positive

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

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

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

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

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 primary use case for this solution is, as an open system, to deploy containers on AWS or other platforms and then manage them.

The most valuable feature for me in the OpenShift Container Platform is the option to manage different containers and environments and also being able to switch among them.

My impression is that this solution is pretty expensive so I think the pricing plan could improve.

I have been using this solution for about two years.

I would rate the stability a nine, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate the scalability an eight, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate the technical support of this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best.

Positive

I was not involved in the initial deployment but I heard that it's not too hard to set up with all the support available.

I would rate the pricing of this solution a four, on a scale from one to 10, with one being the most expensive and 10 being the least expensive.

I would advise other people looking into this solution – if they could afford their pricing plan – to go for it as it's a great product.

I would rate this solution a seven, on a scale from one to 10, with one being the worst and 10 being the best.

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.