I mainly use Red Hat OpenShift Container Platform for big data processing applications that require a lot of memory. On-premises solutions are not efficient for this. OpenShift, with its ready-to-deploy environment using pods and the Apache Spark Operator, allows me to deploy, process, and insert data efficiently. I also use it in my DevOps workflows. Using Tekton as a plugin, we have customized tasks integrated with GitHub, which automates pipelines whenever commits happen to branches.

Using OpenShift has allowed us to optimize our application deployment times significantly. It automates the pipeline for new features, from commit to deployment, which speeds up the process.

OpenShift also helps with stability through multi-cluster support in different regions, ensuring continuous service even if one region faces downtime. Additionally, the auto-scaling feature helps manage resources effectively, keeping operational costs lower compared to on-prem solutions.

One of the most valuable features of OpenShift is its efficient deployment process. It automates rolling out new features, packaging the code, conducting security scans, and deploying to OpenShift.

Additionally, the auto-scaling feature ensures resource optimization by provisioning new nodes when utilization thresholds are met. The support for parallel processing in big data applications and consistent region-wise replication for stability are also crucial.

There are several areas where OpenShift could improve. The interface has numerous UI bugs that need addressing.

Furthermore, the latest version has deprecated the deployment config, which has its own advantages compared to the deployment container.

Lastly, there is no built-in auto-scaling plugin at the OpenShift level; this needs to be addressed as it's available at the cloud provider level, like IBM Cloud.

I have been working with Red Hat OpenShift Container Platform for five years, from the start of my career.

We have faced scalability and stability issues at times. To manage this, we utilize multi-cluster support in different regions like US South and US East. When one region is down, we deploy to another to ensure continuous service. This setup mitigates potential downtime and improves overall stability.

The scalability features of OpenShift have been invaluable. We use auto-scaling plugins to configure minimum and maximum nodes and CPU utilization thresholds. This ensures that new nodes are provisioned when usage hits a specific percentage, which aids in resource management and application scaling.

The customer support from OpenShift is poor, with responses typically coming only after a few hours. The technical support, on the other hand, is more knowledgeable and helpful, although the process takes a considerable amount of time.

I have worked with Kubernetes and Azure services for container management. Over the last year, I've also used AWS EC2. Each has its pros and cons, but I've found OpenShift's built-in features to be highly efficient for my use cases.

The initial setup of OpenShift is not complex when using Terraform or Ansible scripts. These scripts automate the creation and setup of resources, making subsequent deployments straightforward and efficient.

Running OpenShift on the cloud as opposed to on-premises significantly reduces costs. Cloud services provide bundled features and scaling capabilities that would be expensive if set up on bare metal.

OpenShift pricing varies by region. For example, a simple cluster with three nodes in DAL-10 might cost around $560 to $580 per month, subject to specific configurations like memory and CPU cores.

I have experience with Kubernetes, Azure, and AWS EC2. Kubernetes and OpenShift are favored for their container management capabilities, while Azure and AWS offer frequent updates and broader feature sets.

Different companies might choose Amazon, Red Hat, or Microsoft based on their strategic goals. For startups or those needing robust container support, Red Hat OpenShift is highly recommended. For those needing frequent new features, AWS might be more suitable. Decision should be based on strategy and problem statement.

I'd rate the solution nine out of ten.

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.

Red Hat is acquired by IBM, there is still a separate entity, but we are more on the partner side.

I work with IBM, and most of our solutions are on the OpenShift platform. I work with our business partners to enable and help them with the technical pre-sales and setup role. So, I'm not involved in production engineering systems but rather in demos, first application implementations, and POCs.

The user experience and security are some of the key features. There are two key differentiators that you have certainly worked on from the customer's perspective.

It is actually very well laid out for a computer product. But maybe, since it has security built into it, it is sometimes very difficult for people to grasp.

It is much easier to work with Kubernetes than OpenShift. On the inside, all the security and other aspects are very much required by the container.

It has a difficult learning curve. Those are the areas where, from a customer perspective, OpenShift is a little challenging compared to other Kubernetes solutions.

I have been using it for five years.

I would rate the stability of this solution a ten out of ten. It is very stable.

I would rate the scalability a ten out of ten. It is a scalable solution. Our customers are mostly enterprise businesses for Red Hat OpenShift.

The technical support is good. One challenge is that sometimes it may be difficult to find the answers to your questions if you are not a Red Hat customer. Many of the answers require you to log in to the Red Hat portal. Unless you are a customer, you cannot ask for a solution. On those lines, it is a little difficult. Otherwise, technical support is good.

I would rate my experience with the initial setup an eight out of ten, with ten being easy and one being difficult.

The initial setup is a little difficult because installing and configuring it is very involved. I don't see it as easy yet.

It's deployed on both the cloud or on-premises. On the cloud, it's much easier where it is managed OpenShift. If we go to managed offerings like Red Hat OpenShift on AWS, Azure OpenShift, or IBM Cloud, it is much easier to provision. But if it is self-managed, where you have to do everything yourself, it is difficult.

Red Hat OpenShift is self-managed, not from a cloud provider. If you are doing it on the cloud, then it is just a couple of hours. But if it is self-managed, then it will depend on the infrastructure, networking, and all that. It is still a team, but not yet a resource to have all that correctly set up.

It has been a good solution to deploy all containerized applications, like our AI and ML applications. We're not missing out on that capability.

The ROI is definitely much better because once it is set up and done, it is very easy to manage and have applications deployed. The user experience is very good. So once you have it in place, it's easy to do the day-to-day operations, and eventually, scalability and all those things become clear.

Overall, I would rate it a nine out of ten. It is a very good solution overall.

I would definitely recommend it to others.

The platform's most valuable features are its regulatory compliance and enterprise support. It does not offer significantly unique features compared to Kubernetes or Docker. The primary advantage is its extensive support and integration with Red Hat's solutions.

The product's setup process could be easier.

We have been using Red Hat OpenShift Container Platform for approximately one year.

The product is quite stable and reliable, offering robust performance compared to other solutions.

We are currently working with a multi-cluster environment, and the product scalability and response time are impressive, with nodes performing optimally.

Compared to IBM support, Red Hat's support team is more responsive.

The setup process is considerably more complex than that of Docker or Kubernetes. Its multi-node cluster setup involves a more intricate and time-consuming method.

OpenShift's core-based licensing model provides significant benefits regarding enterprise support and scalability. Despite its high cost, it offers valuable features and support that justify the investment.

The product is expensive.

I rate the platform an eight.

Our primary use case for Red Hat OpenShift is to deploy applications. We utilize the platform to manage multiple pods and ensure seamless scaling of our nodes and servers to meet the demands of our high-availability applications.

The platform has significantly improved our organization by enhancing productivity and reducing the time required to deploy applications. It allows for faster deployment and continuous delivery, which has streamlined our development processes.

The most valuable features of Red Hat OpenShift include its integration with Kubernetes and the user interface, which enhances the end-user experience and accelerates the deployment process. These features contribute to increased productivity and efficiency for our developers.

The product could benefit from additional operators and tools integrated with OpenShift. Furthermore, enhancements to the user interface and including more features would be beneficial.

I rate the platform's stability a seven out of ten.

The platform is scalable.

I have opened some tickets but did not receive the required technical support.

The initial setup was complex. I rate the process a two out of ten.

The implementation was done in-house.

I rate the product an eight out of ten.

We use the solution to manage our digital assets like containers and applications.

Integrating the product into our existing infrastructure was easy. We did not face any issues.

The price must be improved.

I have been using the solution for six years.

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

The product’s scalability is good. I rate the scalability an eight out of ten. We have around 15 users.

The support people help us whenever we require their assistance. A partner provides us with the first-level support. The support has been good, but it is not direct support. We have a problem that has not been fixed for a long time.

I rate the ease of setup a six out of ten. The project was ten months long. The deployment took a month.

I rate the pricing a four or five out of ten.

I have also used Docker and Kubernetes.

I will recommend the solution to others. Overall, I rate the tool a nine out of ten.

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 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.

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.