Red Hat OpenShift Container Platform Reviews

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.

We provide it as a service for multiple Dutch government agencies, so we are not really the end user of OpenShift. We only use it a little bit. We mainly just install it for our end users. They use it for all kinds of government work. It is being used for critical work and all kinds of things.

It is mainly for application modernization. We want to be much more efficient as a government. We want to spend the least amount of money on IT because it is all tax money. We need to optimize our deployment as CI/CD, security, etc. OpenShift is helping with that. If you see what we can do now with OpenShift in terms of application development, the speed of delivery has increased a lot for our customers. There has been a good benefit.

We use OpenShift Container Platform's GitOps functionality. It helps with faster development. It is more secure, but it also depends on how you work with it and how you use it. You need to do extra things to make your development more secure. 

We have seen some time savings. For example, we are installing HashiCorp Vault, and we are doing it just on Red Hat Enterprise Linux VMs and OpenShift. The deployment on Red Hat Enterprise Linux VMs with Ansible takes 35 minutes, and on OpenShift, it takes three minutes, so that is a big difference. In the end, it is exactly the same deployment functionality-wise.

OpenShift Container Platform has made our development lifecycle faster. The time saved depends on the complexity of the application, but the deployment time is very fast. That is the main difference.

OpenShift Container Platform has not helped us deploy more apps, but it has made the deployment easier.

It is a little bit hard to determine which feature is the most valuable for our customers. We are never sure what our customers are doing with our OpenShift clusters. For us, the fully automated upgrades are valuable. We have to maintain the clusters in production. For us, it is very important that it does not take too much time to manage all the clusters and do life cycle management and upgrades. Since OpenShift 4, the upgrade path has become one of the most important features for us.

From a technical perspective, it has become a very good product. Since 4.9 or 4.10, it has become a very stable product.

My grief with Red Hat is that they are taking all open-source products and rebranding them as if they are their products. I get questions from our customers. They ask questions such as why are you using OpenShift? Why go for vendor lock-in? I have to explain that there is no real vendor lock-in. They should tone down the aggressive branding a bit.

At times, we also have some problems with getting the proper attention for specific bugs. Red Hat should work on that. We are not big customers of Red Hat, but sometimes, we have severe bugs. We are very innovative, and sometimes, we have to wait for a long time to get proper attention. Red Hat should improve on that.

Red Hat sometimes shifts its focus. We are moving our entire platform from OpenStack to bare metal, so we were running OpenShift on bare metal. They should improve their installers, and they should not change these installers all the time. They can maybe have two instead of four. They have shifted their attention to public clouds, so we now have to wait for our RVs, which is sometimes annoying.

We are not using the Red Hat GitOps operator. We are using the ArgoCD operator because the GitOps operator provided by Red Hat is too old. Our customers are asking for a certain functionality, and the Red Hat operator is lagging behind. It is the same with their Single Sign-On. We are not using Red Hat Single Sign-On because the versions are too old. They should speed it up a bit.

I have been using the OpenShift Container Platform since 2017.

It has become very resilient. We have had some very severe issues. We were very early in adopting OpenShift 4. Red Hat told us that we need to stop using OpenShift SDN and use OVN. We did that, and it became a nightmare. OVM was a beta when we put it in production. We had a lot of issues with it, so we migrated to Calico. We have some trust issues, not from the OpenShift perspective but from the networking side. We have critical workloads, and the clusters just crashed. It was a big problem, so we decided to migrate to Calico. Since then, we do not have any network issues. I know OVN has improved since 4.14 or 4.13, but for us, it is too late now.

It is perfect. You can easily add some resources, but I do wonder why the control plane uses so much memory. We have clusters with 100 nodes. Very soon, we need to upgrade the control plane to 32 gigs per master node. I am just wondering why that is necessary. We get a lot of questions from our customers regarding why our control plane is very expensive. It is designed by Red Hat. They can improve a bit on that.

We have a technical account manager. That works very well for us. Mainly when we moved to OpenShift 4, which was an entirely new product, it was very good to have a technical account manager. He could help us with all kinds of bugs and things. It is working out very well, so we decided to keep them.

On the support case side, I have different feelings. Our experience depends on at what time of the day we file a support case for a severe issue. The support engineers from the United States are the best, but sometimes the support engineers from the other parts of the world seem less skilled. They take longer and ask all kinds of stupid questions. I have had a lot of discussions with them where I have told them that we have a highly qualified engineering team. We know a lot about their products, so they should not ask me all these no-brainer questions. There is a big difference.

We also use Red Hat Key and other things. There are various issues with them, but we do not get the attention. They should fix the issues. If something is filed as a critical bug, I have to call Frank and I need to call Tom to do something about it. I have to ask maybe five or six times and then the ball gets rolling. That is my main concern with Red Hat.

Positive

We switched because of the ease of operations on OpenShift. We had do-it-yourself Kubernetes. We were also CoreOS Tectonic users. We have also tried different products such as Rancher, which is a good product but I am not very experienced with it to make a comparison.

When we started in 2017, we started with open Kubernetes, which is basically do it yourself. It gets really hard. We did do-it-yourself Kubernetes for a couple of months or maybe about a year, and then we decided that it was not the way to go. We were looking for more automation, and then CoreOS created Tectonic. We were using Tectonic, and then Red Hat came along and took over CoreOS. Tectonic just dropped dead, and we had a huge issue. We could not get support anymore. We were forced to go to OpenShift 3.11. It was a real nightmare. So, we had a nice platform and then a horrendous 3.11 platform for two years. It was a nightmare to maintain, and then OpenShift 4 came along. Overall, it was a hard path with a lot of bumps.

It is fair to say that we were forced to go for OpenShift. We are a Red Hat shop, and we wanted a Red Hat distribution. After Tectonic problems, our CTO told us that we were going for a Red Hat stack, so we had to use 3.11. We were very disappointed in that. We knew 3.11, or 3.9 at the time, was not good. It only got better when OpenShift 4 came. Before that, we were not a happy Red Hat customer, but now we are.

The main advantage of OpenShift is the upstream Kubernetes. The most important feature for us is to completely or fully automate upgrades. From the application development side, the entire ecosystem is very strong. There is a total package with it. We can discuss with our customers if they want the entire Red Hat ecosystem or not. We have customers who want to use the entire ecosystem, and then we have customers who want to be more agnostic. It is also difficult for my team to keep that balance right. It is the most difficult part.

To install OpenShift, we have a two-phase process. We are using Ansible to bootstrap things on OpenStack or bare metal. We do the post-configuration with ArgoCD. On the bare-metal side, it takes longer to install OpenShift because they are all physical nodes. They take longer to boot. In virtual environments, it takes about 15 minutes. We have an entire OpenShift cluster, and then we just deploy with ArgoCD.

On our current platform, we install OpenShift on OpenStack, so we are using the UBI installer. It was also a problem for us. We wanted to use the IPI installer but had to use the UBI installer. It meant that we had to do a lot of things ourselves. In the end, it gave us more flexibility. They then changed the IPI installer to make it more flexible, so we can go back to the IPI installer, but teams cannot switch the installers all the time. For our new platform, we are going to migrate all our OpenShift clusters to bare metal with hosted control planes. For the bare-metal clusters, we are using the agent-based installer.

We do it all ourselves. It is very important because you get to know the product very well.

It is a bit hard if you are a cost-neutral organization. We are working for the government. We do not have profit goals. We always have to be able to justify why we made these costs and what the reasoning behind them was. It is a lot of money. I do not have the data, but we are using Red Hat because of the innovation and stable products. We also get good support, which is important. If we are using critical workloads and shared instances, we need to ensure that we have a good partner.

We have saved a lot of time. We just migrated from and stopped using Ansible for GitHub-related things. We are still using Ansible for OpenShift. It is mainly for the bootstrap and the cluster, but for the GitHub stuff, we are moving a lot faster with OpenShift. If you build an application through Ansible, you need to figure out OpenShift LightSpeed and other things all by yourself. You need to sometimes write all the playbooks and all kinds of complex code in Ansible. It takes hours or weeks to get that done, whereas now, the application runs in minutes. In my experience, about 80% of the application deployment using OpenShift and GitOps is very fast. The last 20% is hard if you want to make it production-ready. Being a government organization, we have all kinds of regulations and compliances. That makes it harder, but it is still much faster. Also, by using the container technology, you can try a lot more on your development laptop to speed things up.

Its licensing is completely incomprehensible. We have special people within our company. They discuss with Red Hat subscription managers. It is too complex, and I do not understand it.

We are from the government, and we are trying to be as cheap as possible. Sometimes, I am just amazed at the amount of money that we have to pay. It is crazy.

In the beginning, we evaluated do-it-yourself Kubernetes, Rancher, and CoreOS Tectonic.

Overall, we are very satisfied with OpenShift.

I would rate OpenShift Container Platform an 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.

The product is used to deploy applications. We provide the base image that has the fundamentals for the BPM product. Then, it's in our docker farm and another image is created that extends the base image. The second image adds application-specific requirements on it. Basically, it's layering the application on top of the base image and a new image is created and that is deployed onto OpenShift.

The OpenShift platform is built on the Docker Ecosystem. The image we create is easily portable. OpenShift is built on top of the Docker Ecosystem which is one advantage.

It has run time. It has all the binders required. Once built and once tested that it is working, it'll work wherever it's deployed. 

On OpenShift, it's easy to scale applications. We can easily scale up or scale down.

It's a container platform. It uses resources efficiently - specifically on the CPU RAM limit. We can create as many containers as needed. The underlying resources are utilized well.

It's intuitive and user-friendly. They have a very good UI, through which we can add all the artifacts required for OpenShift. Also, they are providing API through which also we can work on the projects. Apart from that, they also provide the CLI, a command-line interface. In my view, I think it's very good. I don't see anything more that is needed.

Everything is good. I don't see any need or any improvement that can be done. They cover CI/CD and I have not seen something which is missed in this product.

The initial setup can be hard.

It takes some time to learn everything. There's a learning curve. 

I've used the solution for four or five years. 

It's very stable. We've never had any failures. It was always up and running. It's very reliable. 

Our company is quite large. I'm not sure how many people are actually using the solution. We have a small team, and, of us, about four are using it. However, that's not indicative of the company as a whole. 

So far, the scalability is good. 

We're using it regularly, on a daily basis. 

I haven't reached out to support. For this product, we are focused more on the application side. We use the platform, however, our focus is on the application side. Whatever happens, the team that maintains and does the upgrade of the platform, interacts with the vendor. We never interacted with the vendor for OpenShift.

I tried AWS. It's also a cloud product, however, not exactly the same as OpenShift. They offer a different set of services. It's not a past product platform, it is a service product. I have used AWS, which offers cloud services. We cannot really compare both of them.

At the outset, the initial setup was not easy. The learning curve is always there. The lack of materials at that point in time also made learning a little bit hard. However, after some point, we had very good documentation and we could easily handle the product. We could easily start working on it. It's gotten better over time. For the first three or four months, it was hard, however, after that, it was easy.

The first deployment took around four to five months as we had to develop an agent data rate. It took some time. However, the changes, usually, could be done in a week or so. It was not a long time. Every week we can easily make the changes.

There's no maintenance. We don't do it. We use the platform and some other team will automatically do the upgrade. We don't have to do it ourselves. It's done by a separate team.

I'd rate the solution four out of ten in terms of ease of setup.

We handled the implementation ourselves. The solution does not offer any consultants or integrators. We managed everything through the UI.

I cannot speak about the pricing. We never interact with the vendor for that. There is a separate team who takes care of the platform and they work with the vendor for pricing.

While my company has some sort of partnership with eh solution, I am just an end-user.

It's my understanding I'm using the latest version of the solution. 

I'd rate the solution ten out of ten.

I would recommend this product. It's easy to develop applications and it gives you the option to manage your cloud on a private platform. We don't have to rely on public infrastructure. In the private infrastructure, we can have our server and use this product and make the application secure.

The solution being used for application containization.

I like the Flexibility of the solution. 

Metrics monitoring feature needs improvement.

I have been using Red Hat OpenShift Container Platform for five years.

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

The platform's most valuable features include cost reduction through VM application migration to containers, scalability for controlling memory and CPU usage, and the reliability offered by application containerization.

One area for product improvement is the support limitations within the subscription models, particularly the restricted support hours for lower-tier subscriptions.

I have six years of experience working with the OpenShift Container Platform.

The product has proven to be very stable, crucial for supporting our applications effectively.

Setting up the OpenShift Container Platform was straightforward. It's primarily deployed on-premises, although I've also utilized cloud solutions. It takes 15 days to complete the setup. Around three executives are involved in both the deployment and ongoing maintenance. 

I rate the process an eight. 

The migration from VMs to containers has resulted in significant cost savings for us.

The product pricing is competitive and structured around vCPU subscriptions, aligning with our application requirements.

OpenShift integrates seamlessly with our CI/CD pipelines, offering robust automation and deployment capabilities. I would highly recommend it.

I rate it a ten.

It's a good tool and a very comprehensive tool. There are a lot of things to explore. I'm still exploring, I'm not done with it yet.

The UI is good.

It’s user-friendly.

The product offers good customization.

There will be things that can improve, however, at this stage I cannot give a point or two. Maybe after a few months, I can give more details.

One improvement I can suggest is for the people who are not very competent with technology, for the product to give some tips on the screen, to make it easier for them. Things are there and the documentation is there, however, there still needs to be quick guides available. Then it will be easier for people to adapt and learn. Rather than going to big documentation, if there is some quick help or quick guide available and then it would help people to quickly adapt and learn.

It still has to improve compatibility with a couple of more platforms. It works with many however we are still trying to improvise more on a couple of other platforms. Integration seems to take a little bit of time. It would be nice if it was expanded and simplified a bit.

I’ve been using the solution for the last five or six months.

The solution is stable. It works for me. There are no bugs or glitches and it doesn’t crash or freeze.

It is a scalable product. So far, we are not using it in production, so we currently have below 50 users. When it will be in production then there will be more.

If the testing goes well we do plan to increase usage.

I’m getting good support so far. I am happy with them.

We did previously use a different solution. Both are good products. They each have their own benefits.

I don’t have a license. I don’t deal with licensing directly.

I’d rate the solution seven out of ten. We haven’t used it too long. It’s still in production. After six months, we’ll likely have a better idea of how it is going.