Red Hat OpenShift Container Platform Reviews

I work with Red Hat OpenShift Container Platform, specifically the Container Platform, OCP. We are using Red Hat OpenShift Container Platform to deploy our application for continuous deployment, to deploy it on this application, and to administrate our application. To see everything, if we have an incident or we have a problem, we go to this platform to check where the problem is, and if we have to fix it or increase resources, we do it in this platform.

I have been working with Red Hat OpenShift Container Platform for less than six months as we are migrating to this platform. We are starting to use it. We have other people that are helping us to administrate it to administrate our application on this platform. I am not the most senior one in this area, but I can share what I have seen and how we use it.

The powerful thing about Red Hat OpenShift Container Platform is for deploying how to install our application, how to deploy it, and it is easy to work with this platform to do DevOps or CI/CD. It is easy to do CI/CD with this platform and to add functionality in our application. We can add functionality in our application easily with this platform. We can go quickly from dev testing, integrating, and deploying quickly with this platform.

The integrated CI/CD pipelines of Red Hat OpenShift Container Platform have a time-saving impact on our development process. When we use the CI/CD functionality, the main saving is really important compared to combining many other tools to have the same result. In Red Hat OpenShift Container Platform, you have everything integrated, but in other platforms, you have to set up many tools to have the same output. In Red Hat OpenShift Container Platform, it is ready to set up, or almost set up; you only have to configure it. Time-saving is one of the important things.

I have something regarding Red Hat OpenShift Container Platform. It is a little bit complicated to set up Red Hat OpenShift Container Platform on a local server. You have to buy or have many resources, many physical resources to set it up. If they could do something lighter to set up or a light version for a personal computer or something that does not need enormous resources, that would be helpful.

I have been working with Red Hat OpenShift Container Platform for less than six months as we are migrating to this platform.

The auto-scaling capabilities of Red Hat OpenShift Container Platform have helped handle workload variations. Scalability is the main argument. You can configure it easily by just modifying one file. You can scale your application as you want, easily. It is really the easy part that is interesting in Red Hat OpenShift Container Platform, to scale.

I rate the customer service as three out of ten.

Before Red Hat OpenShift Container Platform, I used something else; it is a tool of IBM called WebSphere. I decided to switch from WebSphere to Red Hat OpenShift Container Platform because IBM stopped the support of WebSphere to let everyone move to Red Hat OpenShift Container Platform.

From my perspective, this configuration process of Red Hat OpenShift Container Platform is straightforward. With the internet, you can handle it.

I participated in a part of the configuration of Red Hat OpenShift Container Platform, not the setup. In Red Hat OpenShift Container Platform, you have two profiles, an administrator and a developer. I belong to the developer part. I participated to configure one part of Red Hat OpenShift Container Platform.

I am not really in the financial part to see the benefits of Red Hat OpenShift Container Platform, but we see that we have less spending costs. I think we had to move to this platform because our older platform is not yet supported. We had to move to this platform. Maybe we had to move to this platform more than we did it by choice, more so than searching for financial advantages.

Before choosing Red Hat OpenShift Container Platform, I was not the only one evaluating options. The big managers chose to follow the IBM advices.

I am not really in the financial part to see the benefits of Red Hat OpenShift Container Platform, but we see that we have less spending costs. I think we had to move to this platform because our older platform is not yet supported. We had to move to this platform. Maybe we had to move to this platform more than we did it by choice, more so than searching for financial advantages.

I cannot really describe how Red Hat OpenShift Container Platform's policy-based governance has helped my organization in maintaining application security at scale because we have other services that are more focused on security and respecting confidentiality. I think it respects everything to be integrated in a professional area.

Red Hat OpenShift Container Platform's developer-first workflow has contributed to enhancing my team's productivity by helping us to increase our reactivity. When we have problems, we can fix them quickly. I would say the main benefit is having more reactivity to address a bug or problem to fix. My overall rating of Red Hat OpenShift Container Platform is eight out of ten.

My main use case for Red Hat OpenShift Container Platform is to manage our banking application, where we manage a number of microservices. We use four to five clusters, and under those clusters, we have 50 plus namespaces, which are projects.

We manage those microservices with Red Hat OpenShift Container Platform by working on end-to-end CI/CD deployment where our task is to monitor the application that we have deployed. We have 50 plus microservices, and daily we deploy those microservices with new images.

With the help of Red Hat OpenShift Container Platform, we don't need to use Prometheus and Grafana separately, as Red Hat OpenShift Container Platform's inbuilt feature provides monitoring and logs for a pod and a node. It is also great for project management because it is GUI-based, making it very helpful.

One of the best features Red Hat OpenShift Container Platform offers is that it is GUI-based and enterprise-ready. We can see logs directly and solve issues such as crash loop back errors and image pull back errors if anything happens. We can check events, logs, and we also use it to store secrets.

Red Hat OpenShift Container Platform has positively impacted my organization by allowing us to check logs whenever an error occurs, or a pod is in a pending state or in a crash loop back error. It makes end-to-end deployment very easy, and the secret management, certifications, and everything are very helpful.

After using Red Hat OpenShift Container Platform, I have seen outcomes such as reduced crash loop back errors and image pull back errors. The certificate management is also easy with this, and we can check metrics such as CPU and memory usage.

Red Hat OpenShift Container Platform can be improved by adding more features such as viewing things in dashboard mode, which would be helpful. An inbuilt chat AI feature would also be very helpful for managing errors.

Regarding Red Hat OpenShift Container Platform's AI capabilities, I find its governance and security to be strong enough. However, the secrets we store in Red Hat OpenShift Container Platform are base64 encoded and should be encrypted to prevent unauthorized access if someone else is using Red Hat OpenShift Container Platform.

I have used Red Hat OpenShift Container Platform for application deployment for a total of four years.

Red Hat OpenShift Container Platform is stable in my experience.

The scalability of Red Hat OpenShift Container Platform is good.

Customer support is great.

I would rate the customer support 10 out of 10.

Before choosing Red Hat OpenShift Container Platform, we did not evaluate other options because we have Kubernetes, but we chose Red Hat since it is enterprise-based.

We can say that we have seen a return on investment from using Red Hat OpenShift Container Platform in terms of time saved, but I am not aware of any money saved. It is definitely time-saving.

My experience with pricing, setup cost, and licensing is that the pricing is not that much due to the pay-as-you-go model of AWS. However, I am not aware of the setup cost as I have only worked on it and have not purchased it personally.

I would rate Red Hat OpenShift Container Platform an eight out of ten.

I rate it an eight because the features that I have mentioned are not in Red Hat OpenShift Container Platform yet, which stops it from being a ten.

My advice to others looking into using Red Hat OpenShift Container Platform is that they must go with it, especially if they lack knowledge on CLI-based systems since it is also GUI-based, making it scalable and reliable.

I have a great experience with Red Hat OpenShift Container Platform.

The primary use cases include troubleshooting issues, installation, implementation, and design.

The benefits I have seen from using Red Hat OpenShift Container Platform include that it provides a seamless application business, and the business is never going to be impacted because deployments and upgrades can be completed without impacting the real business. Seamless activity can also be performed on the cluster without impacting the application.

Red Hat OpenShift Container Platform's policy-based governance has helped my organization maintain application security at scale because ACS is also there, and Red Hat is always maintaining things with hardening methods, always coming with hardened images, and we are frequently upgrading the minor and major versions, so it will be mitigated in that way.

Red Hat OpenShift Container Platform's hybrid and multi-cloud support will help to move applications, and if in the future any other platform wants to move, it is easy for the application to move from one platform to another without major impact.

Red Hat OpenShift Container Platform's auto-scaling capabilities have helped handle workload variations majorly at the HPA level at the pod level, but at the node level, we are not using the cloud mechanism, and that is why we are not enabling the node level.

Red Hat OpenShift Container Platform's developer-first workflow has contributed to enhancing my team's productivity because we have many custom scripts that give us reports of everything, ODR, and health-related things, so based on productivity, we are taking actions on that.

Red Hat OpenShift Container Platform needs some improvements, for example, in upgrade time, as normally, an extended upgrade method should be allowed, but sometimes if anyone clicks twice, it tries to upgrade the second level and gets stuck, so that area should be enhanced.

The strictness of the SSD and HDD also should be aligned, because in some environments, we cannot strictly make some rules related to HDD, since Red Hat is strictly making a rule after 4.16 to adopt SSD instead of HDD, which in some environments will not allow, so some workaround should be done on that.

Red Hat OpenShift Container Platform is the best option, but as many companies and the world are mainly looking for security purposes, the clear text format needs to be adopted instead of any third party. Red Hat has to develop its own product, as HashiCorp and CyberArk Conjur exist, but Red Hat needs to protect the clear text format because the secret should not be seen by anyone. Currently, it is a clear text method allowing anyone in the namespace to see the username and password, which should be controlled in that way.

The major improvements needed are related to upgrade time and strict rule-making.

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

Before Red Hat OpenShift Container Platform, I also worked with OKD separately and Kubernetes.

The initial setup for Red Hat OpenShift Container Platform is straightforward because I am using extra features like govc from VMware to update the parameters and these kinds of things, so it is easy on that, with no issues.

I feel that the pricing of Red Hat OpenShift Container Platform depends on the salespeople, as they can decide that, with some companies giving a cheap price and others giving a high price for the same things. I would rate this product an 8 out of 10.

In our country, our customer's main use cases for the Red Hat OpenShift Container Platform involve a journey that has begun to migrate the old legacy banking solutions towards the new containerized platform. Hence, in these cases, the Red Hat OpenShift Container Platform is a de facto standard, and there are a lot of requirements regarding that.

Currently it is mainly used in banking, and in some telcos as well, but we are not exposed to telcos right now for the OpenShift. We are mainly focused on financial sectors.

In terms of features in Red Hat OpenShift Container Platform, I find the orchestration itself quite useful for my customers because it integrates with lots of tools. For the platform plus, the security layer and automation itself are quite amazing.

Regarding how Red Hat OpenShift's policy-based governance helps to maintain application security at scale for my customers, that is also another education part we have to explain a bit. We face a struggle in explaining it to our customers as well, but the feature is quite good.

Regarding the learning curve, the customers actually do not need the technical nitty-gritty details; they need to know about the containerization journey because they are not familiar with it. They know it as a theory, but they don't understand anything about its practical implications. That's the main challenge. The solution itself doesn't require a high learning curve; it is actually quite good to manage. However, application developers and managers have to understand the beauty of it, and that is the challenge. If Red Hat can execute some programs regarding that, it will help.

Regarding Red Hat OpenShift Container Platform, it is expensive according to market feedback. Notably, the platform plus is perceived as quite expensive and some features from an infrastructure perspective are lacking.

I have been working with the Red Hat OpenShift Container Platform for approximately two years from now.

Regarding the auto-scaling capabilities, in most cases, the applications are not ready to handle the auto-scaling part. The reason is that the development was not done that way.

In most cases, the software has to support that auto-scaling feature, and we face that scenario quite often. In very few cases, the applications are quite ready, but in most cases, they don't support it.

I have no complaints regarding the stability of the platform. It is always stable.

Not yet have I ever been in contact with Red Hat support for the Red Hat OpenShift Container Platform, but there may be some scenarios coming in the future.

Neutral

We have experience with VMware solutions, as we are quite familiar with these infrastructure solutions.

We are quite familiar with VMware Tanzu, VMware ESXi, vSphere, vCenter, and vCloud Foundation as well.

Regarding the initial setup, it is pretty easy to set up the container platform.

Regarding return on investment, my customers have not yet seen value in money while or since implementing the Container Platform. We can only comment on that one or two years later, as the customers just began to adopt it. We need to see at least one or two cycles before commenting on that.

Regarding whether Red Hat OpenShift Container Platform is expensive or if the price is reasonable for my customers, to me, the services it provides should incur some costs, but based on market feedback, it is quite expensive. Notably, the platform plus is quite expensive according to the market. While the features it provides and the benefits it adds should have some upfront license fees—this is quite okay with me—marketing it is seen as expensive.

If I summarize the main benefit of this solution for my customers, it is the management of both virtualized and containerized environments, where the containerization will be more focused in the future. The benefit is clearly visible. However, for the customers who are mainly virtualization focused, the benefits are not quite exposed to them, resulting in struggles with customers who focus only on virtualization as they want some alternative to VMware, VMware ESXi and similar solutions.

Through my experience, I do not actually have any suggestion for improvement for Red Hat OpenShift Container Platform because it is a platform as a service provider cloud. While we work with OpenStack as an infrastructure as a service provider system, OpenShift lacks some of its features from an infrastructure perspective. However, from an application point of view, the current features are quite good, and the flexibility of using the system is commendable. In the near future, there will be some upgrades according to market demands, but actually, nothing to blame at it.

Before planning to use the Red Hat OpenShift Container Platform, my advice is that each customer should have a try from a technical point of view, as businesses think in a different way. Before deciding, they should compare features side-by-side and should not ignore OpenShift. Once they have tried it, I think they will stick with it.

It is scalable for my customers, and it is easy to scale.

On a scale from one to ten, I rate Red Hat OpenShift Container Platform a nine.

We run multiple applications on Red Hat OpenShift Container Platform.

Currently, we host all our customer-facing applications on Red Hat OpenShift ROSA and a few on Azure ARO. We deploy them via pipelines using Bamboo, Jenkins, or whatever the specific development teams choose to use.

Red Hat OpenShift Container Platform handles security and compliance within our deployments effectively, so I would rate it as nine; it's quite secure with the SCC it employs and the image security features in place.

Approximately 200 users in our organization work with Red Hat OpenShift Container Platform, and we have roughly 900-1,000 applications running on the platform.

The features such as Red Hat operators, CI/CD, the monitoring stack, and the observability stack enhance our application scalability and management.

Building source to image helps us significantly here as well.

The cluster scaling features, such as the auto-scaling of cluster nodes and application replicas using horizontal and vertical pod auto-scaling, significantly impact our operations.

I would like to see advanced cluster management added in future releases, such as a single pane of glass to manage multiple clusters without needing to pay an extra subscription for it.

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

The deployment process was initially a bit of a challenge because of the DNS Route 53 on ROSA, but the on-prem part was simple.

The deployment process was a bit tricky four years ago, particularly when we did ROSA on the cloud, and I would say it required some improvements to be less complicated, but I haven't done any recent deployments in the cloud to gauge if improvements have been made since then.

There haven't been any issues so far; it remains stable with no downtime or crashes, and even the upgrades are handled seamlessly without issues.

In terms of stability, I rate Red Hat OpenShift Container Platform as a nine based on my experience.

The product is scalable based on my experience; however, there are some limitations preventing changes such as those allowed with Open Source solutions like EKS, which provides more cluster control.

I rate the scalability of Red Hat OpenShift Container Platform as a nine, as I haven't encountered any issues with scaling a cluster or applications.

There are some occasions when support from Red Hat is not what we expect; in instances of outages, it sometimes takes a substantial amount of time to resolve issues.

My thoughts on the technical support of Red Hat are mixed; initially, when we logged a priority call, the assigned engineers were not senior-level, which delayed our support. However, we ultimately received the help we needed, but they should prioritize skilled engineers for urgent issues.

Based on my experience with technical support, I rate it five out of ten.

Positive

We chose Red Hat as our primary vendor because after working with previous vendors such as SUSE, we found Red Hat OpenShift Container Platform to be a more mature, secure, and overall better product for our needs.

When we first started out, the deployment took one or two days when we did a user provision installation for on-prem. We did UPI before, and we managed to change it as well, because later on we found out that we could do installable provision installation for VMware on-prem. Obviously, there's installable provision installation for the clouds as well.

Basically, two people from our company were involved in deployment, along with guidance provided by the service provider, Red Hat, mainly for Azure ARO and AWS ROSA.

We didn't really use third-party help, just some guidance, so we did it ourselves. Initially, we got some guidance but managed to resolve issues independently by consulting them and receiving direction when needed.

The current licensing cost for this solution is around $23,000 per year, per month.

Regarding the current licensing cost, I would rate my satisfaction around seven or seven and a half; there's always room for improvement, especially in financial institutions where budget is a concern.

I requested a document to compare EKS and ROSA because we found costs slightly increasing due to different licensing models, but for total cost of ownership and less complexity, we want to examine each product thoroughly before deciding if we'll save $1,000 a month by transitioning to EKS at the expense of hiring more engineers for maintenance.

I definitely recommend Red Hat OpenShift Container Platform to other organizations due to its high availability, security, ease of use, and all the built-in features it offers.

We do no maintenance for Red Hat OpenShift Container Platform since ROSA is fully managed, and that's why it is a bit more expensive than EKS. The fully managed service includes 24/7 support, scheduling, and upgrades; we only need to inform Red Hat support about upgrades, and they manage the process end to end.

Overall, I rate Red Hat OpenShift Container Platform as a nine; although I would say ten, I think it's important to allow room for improvement.

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.

Neutral

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.

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.

Our primary use case for Red Hat OpenShift Container Platform is to enhance our Kubernetes management by leveraging the additional features and tools it provides. We use it to deploy applications, set up pipelines with Tekton, integrate secure networking, and facilitate AI and machine learning projects through MLOps.

Red Hat OpenShift has made the development processes more manageable and secure, particularly by providing its own DNS system, a pipeline solution called Tekton, and features like source-to-image. These enhancements simplify the complex tasks seen in plain Kubernetes, making it user-friendly and improving DevOps efficiency.

The most valuable features of OpenShift include its advanced security, integrated DNS system, built-in pipeline management with Tekton, enhanced networking routes, and dedicated platforms for DataOps and MLOps. These features make it a robust choice for handling enterprise-level tasks securely and efficiently.

Setting up OpenShift locally can be challenging, particularly because it requires RHL Linux and has specific restrictions. Additionally, the documentation for local setups is lacking. Improving these aspects would make OpenShift more accessible to the community for trial and development purposes.

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

OpenShift is highly stable. Its performance is comparable to Kubernetes, with enhancements where Kubernetes lacks certain features.

Scalability is customizable and straightforward. We can deploy it on any cloud service or our server center and scale it easily. Red Hat and AWS provide excellent support, making it easier to scale quickly.

The technical support from Red Hat and AWS is reliable and friendly, aiding problem resolution effectively.

Neutral

I have experience with Kubernetes, Docker, and Sravan for container management. However, OpenShift stands out for its security and feature enhancements.

The initial setup for OpenShift on the cloud platform is straightforward and quick, taking five to ten minutes to initiate and up to one day to deploy all resources, depending on the complexity. For local setups, the process is more complicated and error-prone.

Typically, three to four people are needed for deployment. This may include configuring nodes and setting up multi-cluster or hybrid environments to ensure scalability and ease of management.

If your concerns are primarily security and feature enhancement, OpenShift offers substantial value. It is suitable for larger teams concerned about security and usability. Smaller teams with less stringent requirements might consider other solutions. Careful cost estimation is crucial to avoid unnecessary financial burdens.

I'd rate the solution nine out of ten.

I'm a DevOps Architect for our on-premises multi-cloud solution. The core business of the company I work for is clearing between all the banks in my country.

We're now in the phase of implementation of major projects for Instant Payments and Open Banking API HUB (PSD2). One of our requirements from solution providers was that the solutions should be "Kubernetes agnostic", so we can deploy the solution on OpenShift, vanilla Kubernetes, etc.

At the same time, for all newly developed in-house applications, we strongly prefer to be able to be deployed on Kubernetes too.

Since we're a small company we need to be efficient and that is why we are implementing automated releases, automatic testing, and CI/CD pipelines using seamless microservices.

When I started using OpenShift, it proved to be a very resilient platform with strengthened security. My responsibility was to build up the whole on-premise private multi-cloud. We designed a practice in GitOps manner so that the source code of all the applications, including the manifests for Kubernetes clusters and the database scripts management, are stored on our private GitHub repository that is used as a single source of truth. At the same time, we realized, that we cannot store sensitive data in GitHub like credentials to other systems, certificates, API keys, etc.

To solve this, we deployed and configured another system place for the secure storage of sensitive data - HashiCorp Vault.

Since we have two data centers, we decided to do multi-cloud deployments in a manner that we don't have one OpenShift cluster stretched across different data centers, but for each data center, we have a separate deployment where both of the OpenShift clusters are connected to the same database and the same external persistent storage. The production databases are not deployed on OpenShift.

We heavily use cloud-native CI/CD pipelines. Practically, there are two cloud-native projects that are supported by RedHat. Tekton is used for Continuous Integration and ArgoCD is used for Continuous Deployment.

Red Hat developed operators for these two tools and we embedded those tools in our day-to-day work. Whenever a developer performs a specific action on GitHub, like Pull Request, separate processes automatically start through the use of webhooks. Then, that source code is built, tested, packaged into a container, pushed to our private docker registry, and deployed to various environments depending on the GitHub branch (dev, test, prod).

We created generic CI/CD pipelines for APIs and databases and by using these pipelines we're speeding up the process of day-to-day deployments, like manually copying files and assigning privileges to various environments. Now, the rest of the staff has more time for more concrete jobs rather than repetitive tasks that are also very prone to errors. We're much more efficient now.

Our developers aren't using CodeReady workspaces and they don't have isolated environments on their laptops, but they do have access to the OpenShift clusters in a very controlled manner since they're directly deploying the solution via these pipelines to the OpenShift platform.

We're currently using version 4.10. I have also used versions 3.10 and 3.11. We are testing deployment on OpenShift 4.12 too where the Kubernetes version is 1.25+ which brought a lot of major improvements.

When there are a handful of APIs and microservices, you can orchestrate them manually and use Docker Swarm. However, when there are dozens of applications consisting of hundreds of microservices, you must use tools for orchestration. That's where Kubernetes comes into play.

When I came to this company all of the deployments to various environments (dev, test, prod) were done manually.

As I said, there are two main types of deployments. One type is the deployment of databases, DB tables, new procedures, new functions, etc. 

The other type is the deployment of APIs. For that deployment, my colleagues were manually building the project. They did not use any kind of SCM tool at that moment. When they got the compiled artifacts, like DLL files, they were copying those files to another team. People from that team were picking the files and manually copying them to our web servers.

For databases, it was practically the same. Developers built escrow scripts, and another team deployed the scripts and tested them on a test environment. After successful testing, the third team deployed the scripts to production.

This was a very manual, lengthy, and error-prone process where a lot of things could go wrong.

We now use our private GitHub repository for software development and version control, as well as CI/CD pipelines for both API and database deployment to each environment.

It's a very automatic and predictable process.

Deployment of a new release to the test or production environment is protected, and developers can't deploy a new version any time they want. They need to have approval from the release manager. If the release manager approves the deployment to a specific environment, the pipeline automatically picks up that information and deploys the whole solution.

This control of deployment to a specific environment (four eyes principle) is managed with policies on GitHub.

We have reports in the form of audit logs that show who did what, at what time, and in what environment and we have total control over the production environments.

We have achieved zero downtime on almost all levels, because of the way that OpenShift and the containers work. When a new container is deployed, the old one is still running. When the new one starts and all of the readiness probes work, then the old container is practically terminated. Most of the time, we don't have downtime for some of the manual work.

Using GitHub and CI/CD pipelines, we have avoided a lot of manual work and have sped up the process of deployment of new releases to various environments by at least 30%. Now, we have a more reliable process, which is automatic, and we're avoiding human-prone mistakes during this process.

OpenShift also comes with integrated monitoring. It uses internal metrics collected by Prometheus and Grafana for visualization of those metrics, but you can export all the logs and metrics from OpenShift to another system. You can also transfer the logs and metrics to Elastic Stack using filebeats, metricbeats, and auditbeats, and you can easily monitor the cluster from outside because you need to be on top of it all the time.

When everything goes down, you must intervene quickly and get information very quickly through different channels like Slack, SMS, email, Teams, or chat.

Security is the most valuable feature. If you get Vanilla Kubernetes, they lack security. Red Hat OpenShift comes in two flavors. One is OCP, OpenShift Container Platform, for which you need licenses. We're using that for production environments. For developing environments, there is the OKD Community edition of OpenShift.

They're very similar because OCP uses Red Hat CoreOS certified from Red Hat, but the community edition uses Fedora CoreOS. We're trying to deploy applications to be “Kubernetes agnostic” about the underlying infrastructure. Whatever we deploy should work on both OCP and OKD. In that pattern, we're also practically saving on licenses because we use them for the production version of OpenShift only. For development and testing, we use OKD.

Three years ago, deployment of the OpenShift cluster wasn't easy. It required a lot of knowledge of load balancers, networking, DNS and DHCP services, and virtualization. For version 3.11, OpenShift came with Docker as a container's run-time engine. From version 4, Docker was replaced with Podman, which is quite a good approach because Docker needs to run as a daemon with elevated privileges. Podman doesn't require such elevated privileges.

In the beginning, it was very difficult to install OpenShift even by following the documentation. There were some YouTube videos, but we struggled. That installation was named UPI, which stands for user provision infrastructure. That means that you need to deploy your own load balancers to configure them correctly and enter your DNS and domains. Only if everything is configured correctly, the OpenShift cluster will work.

Then, Red Hat came up with a solution. We use virtualization technologies on-premises. We do not use bare metal, so this was a very hard task on VMware, but then Red Hat from version 4.5. updated their installer to use IPI (installation provisioned infrastructure). For day-to-day jobs, we prepared one helper machine from which we can manage, deploy, destroy, and operate multiple clusters from one place. The bare installation of deploying an OpenShift cluster is now an easy task for us.

The stack in the software supply chain is one of the main reasons that we use OpenShift. When I came to this company, we bought hardware from IBM named Bluemix, and they used ICP, which stands for IBM Cloud Private.

Today, you can have Kubernetes on IBM, Amazon, Microsoft, Google, name it. You can also have different installations on various platforms like VMware and Tanzu, which are commercial products. Also, there are some open-source variations of Kubernetes like Rancher and Platform9.

At that point in time, IBM bought Red Hat. They very cleverly recognized that their product, IBM Cloud Private, was an inferior platform to Red Hat and OpenShift, and they invested a lot in Red Hat and in OpenShift. OpenShift is an enterprise-grade standard Kubernetes orchestration system for huge enterprises. There are more flavors of Kubernetes, but I believe OpenShift is practically a standard one, so whether or not you use it on the cloud or on-premises, OpenShift has a huge market share.

Vanilla Kubernetes lacks security. We have role-based access controls to tune and perform grant-level access to specific service accounts, roles and permissions. There is very good isolation between the namespaces. Practically, we have four clusters on-premises for each huge specific production grade system. Two of those clusters run several independent environments that are different from each other on the same clusters (dev, performance, smoke, test). Only production clusters are separate from those. No deployment sees another deployment, so they cannot interfere.

We connected our OpenShift platform with our LDAP, so we also have security that shows who accesses it and what permissions they can perform over the operative clusters and applications that run on them. We have a DevOps team, developers, and infrastructure guys, and there haven't been any complaints so far about the day-to-day usage of OpenShift. I believe all the aspects of security that we need are practically covered from both the user perspective and the application perspective.

OpenShift has a pretty steep learning curve. It's not an easy tool to use. It's not only OpenShift but Kubernetes itself. The good thing is that Red Hat provides specific targeted training. There are five or six pieces of training where you can get certifications. The licenses for OpenShift are pretty expensive, so they could be cheaper because the competition isn't sleeping, and Red Hat must take that into account.

There are a few versions of OpenShift. There is the normal OpenShift and an OpenShift Plus license. Red Hat could think of how to connect those two subscriptions because, with Red Hat Plus, you have one tool called ACM (Advanced Cluster Management), where you can manage multiple clusters from one place. We deployed this functionality by ourselves, but if you don't pay the license for Red Hat OpenShift Plus, you'll lack this functionality. If you have a multi-cloud environment and you have a lot of work to do, it would be a plus if the Red Had OpenShift Plus license came in a bundle with the regular solutions. This ACM tool should be available in the normal subscription, not just the Plus version.

There are new versions on an almost weekly basis. I found myself that the upgrading of OpenShift clusters is not a task that will successfully finish every time. It's a simple and quick, but not reliable process.

That's why we use multiple clusters. We use v4.10.3, but we want to move to v4.12.X. The upgrade process itself can fail, and we don't have backups of our OpenShift cluster because we have backups of all the Kubernetes manifests on GitHub.

We destroy the cluster, bring up a new one quickly, and apply those scripts. The upgrade itself could be more resilient for us as administrators of OpenShift to be sure that it'll succeed and not occasionally fail.

They can improve the reliability of their upgrade process. They also have implementations of some Red Hat-verified operators for a lot of products like Elasticsearch. They're good enough for development purposes, but some of the OpenShift operators still lack resilient production-grade configurations.

Red Hat says that we have a few hundred operators, but I believe that only half of them are production-grade ready at this moment. They need to work much more on those operators to become more flexible because you can deploy all of them in development mode, but when we go to production grade and want to make specific changes to the operator and configuration, we lack those possibilities.

I have used Red Hat OpenShift for three years.

There are some undocumented features and well-known bugs, and Red Hat is aware of them. I don't know why they haven't been fixed so far. Otherwise, it's a stable product. We use it in production for critical areas, since we learned how to avoid some of the known bugs. Bugzilla is a tool we use to report some of the bugs to RedHat Support.

We usually have initial scripts where we deploy the solution for a new cluster and eliminate or manually fix some of those issues. It's a stable product, but Kubernetes is a platform for making platforms. It gives us the flexibility to easily speed up our process and not waste manual work. It can be improved in many ways, but that will take some time.

The scalability is the main reason why we use OpenShift. We heavily use automatic scalability because we use horizontal and vertical pod auto scalers. When we configure our OpenShift clusters in a way where we defined the required resources for each and every pod and when that pod comes to 80% of CPU or memory usage, the system automatically brings up a new pod.

It can scale up to a certain amount of pods and if there's very heavy utilization of the OpenShift cluster itself, they OpenShift automatically provisions a new worker node for you. We tested it and it works.

When it's required that the system isn't under heavy load, those nodes can be destroyed automatically. It's a very nice feature compared to the monolithic applications and automatic provisioning of the new virtual machine installation and all of the configurations and operating systems. The scalability and orchestration of many containers is the main reason why we use OpenShift.

We contacted support a few times, but it wasn't great. It could be improved a lot.

We contacted them about licensing. It wasn't clear whether it was being done on CPU or an entitlement level because we bought our product from IBM, but IBM bought Red Hat. Still, we struggle with the support because we report our complaints to IBM first, and then IBM redirects us to Red Hat.

About four years ago, IBM bought Red Hat. They still don't have one unified ticket system. You have to buy licenses from Red Hat separately. Although you can buy them from IBM, you need to import those licenses for Red Hat on a separate portal. It requires some overhead from us, which isn't good. There were a few times when we contacted them, and they were quite efficient, but still not enough for us to wait for the OpenShift cluster to be fixed, so we redeployed the cluster.

I would rate technical support a five out of ten.

Neutral

Previously we had mainly monolithic applications and a fair number of APIs running on IIS. In order to be more efficient and resilient we switched to containerized APIs running on OpenShift Kubernetes.

When we initially used ICP IBM private cloud, that platform used something called patterns. We had a pattern for the deployment of OpenShift. At that point in time, we used OpenShift 3.11. In the background, those patterns were practically Ansible scripts simulating UPI installation as IPI. Ansible is a Red Hat product for automatic infrastructure and configuration deployment.

At that time, we had user provision infrastructure, but instead of doing everything manually like provisioning load balancers, configuring them, and putting in the DNS records, those patterns were doing that for us. They were somehow simulating IPA, installation provision infrastructure. Then, we purchased a VxRail platform from Dell, and from there we can do everything on our own.

Starting from OpenShift v4.5. Red Hat, came with IPA installation for VSphere, so we can deploy OpenShift clusters quickly and efficiently on VMware with a few lines of code and a few YAML configuration changes. In the beginning, it was a hard task, but now once you prepare everything, it’s a quick and easy task.

Setup depends on how well you're prepared. I prepared a small helper machine and configured it with a lot of tools, and I manage all my clusters from that machine. It has a connection to my GitHub. I have all of my repositories and Kubernetes manifest for various deployments stored on that machine too.

If you're deploying OpenShift for the first time, it can take several hours if everything goes well. When we first performed all of these prerequisites, we imported the VMware certificates and performed all the configurations, and we only needed to change very small details for the new OpenShift cluster. It's usually a few commands, and the installation itself takes approximately 40-60 minutes.

After initial installation, it takes approximately another 30-40 minutes to configure a freshly deployed OpenShift cluster. In about hour and a half, I can deploy any cluster with all the applications and configurations running, assuming that we have everything prepared, and stored on GitHub.

As I said, we rarely contact Red Hat support because we use GitOps practices. For High Availability, we always have at least two clusters in two different data centers and in case we cannot fix the cluster itself within 30 minutes we recreate it from scratch. In front of the OpenShift clusters there are few clustered load balancers. If one cluster is down, the traffic goes to another cluster.

I would rate OpenShift an eight out of ten.

My advice to new users is to try OpenShift Container Distribution. You can try to deploy some applications from source code or a Docker container. That product is free, so you don't need to pay anything. If you want to try the real thing, Red Hat offers a 60-day trial so you can install Red Hat OpenShift on-premises on a virtualization platform or on bare metal.

After each trial period, if no license is activated in the cluster you are losing the ability for upgrading the cluster. The good thing is that anybody can try it, but it's very different if you use OpenShift in the cloud or on-premises. On-premises, you can use whatever you want. You can use a few laptops and desktops or you can have a virtualization platform, but you should always check the documentation and see whether that platform is supported.

The first steps are always hard. You must go through the documentation and learn how to set it up and how to make the first installation. When you make the first installation, it's a lot easier, but it's not only the installation of OpenShift itself. It's the Day-2 Operation activities, how to monitor the OpenShift cluster, how to deploy workloads, and how to automate the workload deployment. It's a steep learning curve, but we have seen great satisfaction from our colleagues. It's good to invest in this knowledge.

Red Hat has OpenShift.TV, which is a YouTube channel where they discuss new ideas, tips, and tricks once or twice a week. I contacted a few Red Hat ambassadors that I saw in those YouTube videos. I was surprised when I received a response from them within 24 hours. It helped me a lot.

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.

Positive

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.