My main use case for Red Hat OpenShift is serving telco customers. A quick specific example of how I use Red Hat OpenShift for my telco customers involves different applications that reside in containers on those particular container platforms. This workload includes different parts such as AMF and UPF, which are the basic functions that I normally use as applications on Red Hat OpenShift.

Red Hat OpenShift has positively impacted our organization by adding significantly to our revenues because what we were doing through other vendors shows that with vanilla Kubernetes, there are many features and extra advantages in Red Hat OpenShift. It has had a strong positive impact on our organization by standardizing how we build, deploy, and operate applications across environments. One of the biggest benefits is its operational consistency. It provides a uniform Kubernetes platform across both on-premises and cloud environments. From an availability and reliability perspective, Red Hat OpenShift's built-in lifecycle management and automated upgrades, along with self-healing capabilities, have improved overall system stability.

Currently, I am not equipped with specific outcomes or metrics that demonstrate this positive impact, but it has significantly improved all these parameters.

The best features Red Hat OpenShift offers include security, hybrid multi-cloud, and bare metal flexibility. The Operator framework and lifecycle automation are also part of it, along with improved CI/CD and GitOps pipelines, and strong security with compliance features.

In my day-to-day operations, I find lifecycle automation to be the most valuable feature. Additionally, Red Hat OpenShift provides developers with hands-on extra capabilities and experiences.

Red Hat OpenShift can be improved by reducing its complexity. We could also have better UX, especially for day two operations. There is always some scope for optimization that we can address.

I have been using Red Hat OpenShift for four years.

Red Hat OpenShift is stable and offers the most stability among all the competitors and enterprise-level solutions available.

The scalability of Red Hat OpenShift is great, with many options available to scale it according to your requirement or demand. The extent to which you can scale depends on the environment you are deploying it in.

The customer support is great, and we have many channels through which we can approach them.

We have previously used VMware and Wind River, and while we still use them for some of our customers, we switched to Red Hat OpenShift because we found the best features there.

I do not have any readily available data regarding return on investment metrics, but I can say that we see relevant improvements in money saved, time saved, and fewer employees needed.

My experience with pricing, setup cost, and licensing involves a different team that handles all these aspects, so as a SRE, I do not need to worry about these things.

Before choosing Red Hat OpenShift, we evaluated other options such as Mesos, but Red Hat OpenShift is more futuristic.

My advice for others looking into using Red Hat OpenShift is that you need to first get hands-on experience with the technology. It is based on vanilla Kubernetes, but they have added additional capabilities for which having basic knowledge is essential. You should go through their portals and lab environments available.

My main use case for Red Hat OpenShift involves two cases: the first case is about the migration of QRadar and Red Hat OpenShift for the cloud, which relates to the process of antivirus, XDR, and SOAR and SIEM. The second case is the use for the migration in ARO, Microsoft Azure Red Hat OpenShift, for the migration of OpenCTI from on-premise to the cloud.

A quick specific example of how I used Red Hat OpenShift for one of those migrations is the particular process of the migration about the OpenCTI. The OpenCTI migration involved a process where we used Docker for the OpenCTI to function correctly when implemented, which was the main challenge.

I do not have anything else to add about my main use case or the migration processes with Red Hat OpenShift.

In my experience, the best feature Red Hat OpenShift offers is that the environment is easy to use. When I say environment needs, I mean that it is easy for the configuration and the management in the different environments. For example, when I use the API key, the configuration and connector, the environment provides easy visibility and allows me to watch the reports for the leadership in the company.

Red Hat OpenShift has positively impacted my organization, and now we use it more in the QRadar SIEM environment. However, in this case, IBM sold QRadar to Palo Alto, and our client changed the SIEM, so Red Hat OpenShift is not functional at this moment for QRadar.

Red Hat OpenShift can be improved by addressing any features, performance, or usability issues. In my view, the performance is very good, and the automatization of the new environment and new machine is fantastic because it is easier for my job in the company. My colleagues display information and the Docker functionality is good.

There are two small things I would suggest about the SOAR: the connection for the SOAR to send email and send communication to our colleagues and people in the company.

If I could change or improve one thing about Red Hat OpenShift, it would be to provide more information on the web because the information is limited and I need to explore more. I would change this about Red Hat OpenShift because I have known this all year and need more investigation.

I have been using Red Hat OpenShift for about one year, more than one year ago.

Red Hat OpenShift is stable.

In my view, Red Hat OpenShift's scalability is good, although I do not know for certain.

The customer support for Red Hat OpenShift is bad because the support does not respond.

I did not previously use a different solution before Red Hat OpenShift. However, before it, we used VMware.

Before choosing Red Hat OpenShift, we evaluated other options, specifically VMware.

I have seen a return on investment from using Red Hat OpenShift because I save money since I do not need the server in my data center on-premise, and I save money in monthly payments for availability and accessibility in the data center.

I cannot respond to the question about my experience with pricing, setup cost, and licensing because the cost is another area, specifically the area of accounting and finance.

Before choosing Red Hat OpenShift, we evaluated other options, specifically VMware.

My advice for others looking into using Red Hat OpenShift is to explore the tools, understand how Red Hat OpenShift migration to the cloud works, and recognize that the response and return on metric is efficient for good operation.

That is all I would like to add about the features of Red Hat OpenShift. I choose seven out of ten because my use is not total. Perhaps it is interesting for the use, but our environment in the company is easier to use with VMware. I rate this product seven out of ten overall.

I do not have any additional thoughts about Red Hat OpenShift.

I have been using Red Hat OpenShift for more than six years.

I implement Red Hat OpenShift for our customers as we are a service provider, and we implement it in our cloud. We provide it as a service for our customers, and we deploy some of the applications that we have implemented in our company and for my personal use.

I deployed and developed an audit application which runs all the compliance requirements for a company, including multiple platforms and multiple standards such as ISO and others, and NCA for Saudi Arabia, and any other standard can work on it. This is one example. I also created a personal application for a t-shirt integrated with AI where we can create an image and print it on a shirt and ship it to the customer. I implemented another application for waste management, which was totally developed and deployed by myself for my personal use and the waste management for one of our customers. Additionally, I had another application deployed for one of our customers, where my role was to deploy Red Hat OpenShift and to make sure their application is deployed and available. This is for bill invoicing and financial operations. For one of the hospitals, our customer, I deployed the application for monitoring diabetes patients. My role there was to deploy it and to make the application available, providing all the requirements, ingress, configuration, storage, and other things. These are examples of what I have done.

Red Hat OpenShift by default is secure, more than native Kubernetes, as it has a limitation for the run as. The container by default does not run as root; this is one of the examples. The integration with ACS allows centralized policy deployment and enforcement, alongside great observability and monitoring. Red Hat OpenShift is actually enterprise-grade Kubernetes with all the accessories and main features.

One of the best features of Red Hat OpenShift is that it has the catalog, the application catalog, and the operator hub, which allows us to deploy things easily and straightforward without going into a lot of hassles. This is one of the main things, in addition to having integration with ACM and ACS, where we can have the ability to manage multiple clusters and to secure them, deploy them, manage them, run GitOps and day-two operations, as well as upgrades and other functionality which is made easy using these tools. Red Hat OpenShift also provides virtualization capabilities, and I am currently working with Zain to make a project where we will convert F5 appliances to virtual machines and to manage them through Red Hat virtualization, OVE. Red Hat OpenShift is a unique platform because it provides the features for both worlds, containerization, and VMs at the same time, requiring you to learn one skillset in order to manage all of this at the same time.

In the beginning, our cloud depended only on virtual machines, so I introduced this to our management to start to work with microservices and with containerization. This was adapted in our cloud, providing us the capability to sell more of these features and to reduce the hardware requirement by about thirty percent, following the trends of using containerization for all modern applications. In addition, it reduced the time to develop and to deploy a new application; all we need is using Jenkins for CI/CD. Once we commit any code, it gets triggered, and it will implement the new container in a very flexible and easy way, within seconds. This decreased the time to market and increased agility, allowing us to capture new opportunities very fast.

There is perhaps one thing about the deployment of Red Hat OpenShift. Currently, there are two new ways to deploy Red Hat OpenShift, which are easier with assisted deployment and agent-based deployment. However, previously it needed a lot of requirements on the infrastructure side if we are using UPI, user-provided infrastructure. If the deployment of Red Hat OpenShift itself can be easier and more flexible, it would be great.

I have been using Red Hat OpenShift for more than six years.

Red Hat OpenShift is stable.

It is great. Red Hat OpenShift can scale to thousands of nodes, allowing multiple clusters to be managed in different geolocations and managed by centralized advanced cluster management, ACM.

Regarding scalability, Red Hat OpenShift has a lot of scalability capability, including about two thousand machines in one cluster and multiple cluster management, centralized management through ACM and ACS, which provides a very secure way to manage centrally all the features and to enforce policies.

In the beginning, our cloud depended only on virtual machines, so I introduced this to our management to start to work with microservices and with containerization. This was adapted in our cloud, providing us the capability to sell more of these features and to reduce the hardware requirement by about thirty percent, following the trends of using containerization for all modern applications.

The response time for customer support is excellent, and they go deep and can resolve things easily.

The documentation and support that we get from Red Hat are very sufficient, and this differentiates between enterprise-grade Kubernetes and native Kubernetes or perhaps Kubernetes from other vendors.

We used native Kubernetes before Red Hat OpenShift, actually, deploying it through kubeadm. The issue with Kubernetes is that it is just the engine; Red Hat has all the requirements to give you a complete solution. Red Hat OpenShift provides the complete ecosystem, all the integrations, and the tools which I mentioned before, which are already integrated and easy to be used. You do not need to grab open-source solutions for storage or other things, and you do not have to do a lot of customization, needing to comply with each version. Red Hat OpenShift is tested and vetted, making things easier to be deployed, supported, and managed, and it is more trustworthy.

There is perhaps one thing about the deployment of Red Hat OpenShift. Currently, there are two new ways to deploy Red Hat OpenShift, which are easier with assisted deployment and agent-based deployment.

We are a partner with Red Hat; we sell their services and licenses, and we do the implementation ourselves.

We did not measure our return on investment in a very accurate way, but as I mentioned, we could decrease the time needed to deploy any application, enabling us to capture new opportunities faster, go to market faster, and maintain the availability and security of all our applications.

We work with Red Hat or our distributor in Saudi Arabia. We send our requirements as part of the RFP describing what we need, and we get the pricing from our distributor. There is an easy way to price the subscription of the support per CPU, per VM, so it is easy to be priced, but we depend on an official quote usually from our distributor.

Red Hat OpenShift by default is secure, more than native Kubernetes, as it has a limitation for the run as. The container by default does not run as root; this is one of the examples. The integration with ACS allows centralized policy deployment and enforcement, alongside great observability and monitoring. Red Hat OpenShift is actually enterprise-grade Kubernetes with all the accessories and main features.

Our go-to-market and our deployment for any application, the time is reduced perhaps by eight times. It is very fast because you have consistency for all deployed containers; it is not like a virtual machine where you have to deploy individually for each virtual machine or you have to copy code here and there. It takes seconds because the containers spin out very fast; they are very lightweight. The things that we used to do in days, now take a couple of minutes to be done. So, that is approximately the number—mostly it is reduced by eight.

We are providing our cloud to our customers, so we are a service provider. We deploy Red Hat OpenShift in our cloud and host customers' applications through it. Some of our customers prefer Red Hat OpenShift on Azure or on AWS, so we deploy it there when needed, but our main deliverable is through our cloud.

We have our own cloud provided by our company, making us a local cloud provider. We are not a hyper integrator, nor a hyper-scaler. We provide it through our cloud and deployed a couple of customers on Azure; this is what I recall.

I would advise others looking into using Red Hat OpenShift to take the step and to go fast into it because it will save them a lot of money and provide them with all the features, flexibility, security, and others. I give this product a rating of ten out of ten.

My main use case for Red Hat OpenShift is that we had several security tools that we deployed to Red Hat OpenShift platform, specifically when we were migrating our applications from monolithic architecture to microservices, and our OpenShift platform was using some of the AWS VMs as master and worker nodes, so it was completely on AWS, and we actually set it up from scratch, setting up those projects to be used for our applications and then deploying them with Red Hat OpenShift version 4, which we started using five years back, as it was the latest at that point in time, and then we continued to operate and run our applications there.

A quick, specific example of an application I deployed on Red Hat OpenShift is a banking-based application which we moved from a monolithic architecture to a microservices architecture, and we completely deployed it end-to-end, split into 10 plus microservices, and then it was deployed to Red Hat OpenShift platform 4.

The best features that Red Hat OpenShift offers in my experience include being a pre-assembled product where Red Hat actually makes choices for you, which for example, as a CloudOps Engineer, means I don't have to explicitly go into CLI because the web-based UI is simple and helpful for debugging, and they've integrated the logging of the application within Red Hat OpenShift. I really appreciate the automated updates, built-in observability comes with pre-configured Prometheus and Grafana stack for monitoring our cluster health, and the native tooling it has such as Red Hat OpenShift GitOps, which is a Red Hat supported Argo CD, and the integration into clusters are based on role-based access control with security by default, where Red Hat OpenShift is quite secure out of the box, having those strict permissions and using Security Context Constraints, and especially the immutable OS and Red Hat OpenShift virtualization, which is something that is really helpful.

Red Hat OpenShift has positively impacted my organization primarily through observability, as for us, application uptime matters a lot when providing public-facing products consumed by customers, and hence, we're using that to keep refining our application and products through observability metrics and keeping pace with market trends, as we promised 99.99% uptime to our customers, and the observability in Red Hat OpenShift is really helping us a lot with that.

Areas where Red Hat OpenShift can be improved include the licensing being a bit complex and maybe expensive, as that is something in the hands of the organization's higher management, especially when those licensing agreements are done, and I think Red Hat OpenShift is quite resource-heavy because the control plane and default monitoring stack consume significant resources, meaning for small clusters, a large percentage of compute goes just to running Red Hat OpenShift itself, not our apps.

I have been using Red Hat OpenShift for close to six years across those different organizations.

Red Hat OpenShift is stable in my experience.

Red Hat OpenShift's scalability is really good.

Customer support is really good because so far in our case, we have always received a prompt response, and they have been really helpful to us. I would rate the customer support a 10 out of 10.

We did not use any other solution before Red Hat OpenShift.

Red Hat OpenShift is deployed in my organization on AWS.

We have saved a lot of time with Red Hat OpenShift.

My experience with pricing, setup cost, and licensing would suggest that it was more into a high cost, but then again, I'm an engineer, so this is taken care of by the higher management, and I don't have any definitive answer.

We did not evaluate any other solution before choosing Red Hat OpenShift because we wanted to use a licensed product for Kubernetes that has enterprise support.

I would rate Red Hat OpenShift a 9 out of 10 overall. I choose a nine for Red Hat OpenShift because for such kind of tools, there is always room for improvement, as I already mentioned the things that can be improved in my previous answer. I would suggest that it's quite better if you're using Red Hat OpenShift for an enterprise solution, as it's really better to have the enterprise support which Red Hat OpenShift offers, and it's easy to use for Kubernetes-based applications.

Red Hat OpenShift is used to host all services running on containers on specific ports for both production and non-production environments.

Red Hat OpenShift is utilized in the healthcare sector.

Red Hat OpenShift provides good value as a cloud service, comparable to other public clouds such as AWS and Azure, but it functions as a private cloud rather than a public one.

A smaller cloud running on containers enables easy deployment with the ability to scale up and scale down, and it can host multiple services on the same platform.

Red Hat OpenShift is currently running with VMware, and there are some issues on the storage side that are still being addressed.

The support from Red Hat is rated around a six or seven in those kinds of cases.

Support could improve with faster response times, as responses are currently quite slow.

The team has been working with Red Hat OpenShift for over five years.

The initial setup for Red Hat OpenShift is easy to deploy.

There are approximately two resources working on the Red Hat OpenShift cluster for deployment.

The DevOps engineer and the Red Hat OpenShift Linux engineer are the job roles required for deployment.

There is no free open-source version available; a license must be purchased for Red Hat OpenShift.

The pricing for Red Hat OpenShift is considered quite high.

Red Hat OpenShift cannot be compared with other options for PaaS clouds because other private services have never been used.

There is no current knowledge of other available options.

I am not familiar with the mobile app platform for Android.

I don't have experience with VMware or AWS products at this time, although a team member may be working on the technical side.

My focus is on the management side rather than the technical side.

Microsoft tools are not being used.

The team is focused on the Linux side for the private cloud for Red Hat OpenShift.

I have minimal familiarity with Red Hat OpenShift. I don't have experience with Red Hat OpenShift Data Foundation. The technical side of Red Hat OpenShift is handled by a team member. Management tools, help desk software, or ITSMs are not being used. The overall review rating for Red Hat OpenShift is seven out of ten.

We already were having that microservices architecture, so there was not much change from that perspective. We had small services, so here we had to create multiple pod IDs. Even today, we are using a hybrid microservices architecture. Our DB still has two or three services that hit the same database. From that perspective, there was not much change that we did in our case.

We have certain applications on-prem on physical servers. We had some on Windows and some on Linux. There we had requirements where every time we had to manage extra load, we had to spawn a new Tomcat node. Scaling was one of the issues we were facing, and every time we had to scale up, it was a challenge. Plus, we had to procure infrastructure and do a lot of configuration and setup for the new instance being launched.

Once we set that up, scaling down was a challenge as we did not always bring that down when not needed. When we did not have too much traffic, we still had a lot of infrastructure lying idle. At the same time, when we had high load, we were not able to scale up quickly.

There was too much patching that happened, and every time we had to patch something it became a challenge. There were versioning issues with operating systems versus Java and other technologies we were using. That is why we moved to containerization, where we defined what operating system we need, what Java version we need, and what steps we want to do. Containerization helped us create that one unit we wanted to deploy. Red Hat OpenShift helped us with managing scaling up and scaling down.

Because it was centrally managed in our company, many metrics that we had to write code for were available out of the box, including utilization, CPU utilization, memory, and similar metrics. We performed multiple transformations from physical servers to Red Hat OpenShift, and some from virtual servers to Red Hat OpenShift.

The OC utility tool is something we use very often for replication, replica sets, and config maps for managing all environments and secrets. This is very useful for us. Routing is another beneficial feature we get, so we do not need to manage or do too many things for load balancing.

Currently, one of the biggest challenges we face is with services and jobs. For spawning batches, although it has crons, it is not easy to integrate with enterprise systems such as Autosys. The entire company uses Autosys, but we are not able to integrate it effectively.

We need intermediate servers to run OC utility commands and initiate the cron job. We have to do a lot of modifications to ensure our batches work properly. With physical or virtual servers, even in AWS, we are able to write and manage multiple jobs. Managing batches in Red Hat OpenShift has been a significant challenge.

Integrating third parties is a challenge with Red Hat OpenShift. For example, with Elasticsearch, onboarding itself was difficult, running file beats and dealing with routing issues. It is not straightforward, especially since we have some components in AWS as. AWS has many capabilities that come out of the box and are easier to work with compared to Red Hat OpenShift.

Red Hat OpenShift's biggest disadvantage is they do not provide any private cloud setup where we can host on our site using their services. The main reason we went with Red Hat OpenShift was because it is a private cloud, and we have regulatory requirements that prevent us from using public cloud.

The main reason we went with Red Hat OpenShift was because it is a private cloud, and we have regulatory requirements that prevent us from using public cloud. Red Hat OpenShift's biggest disadvantage is they do not provide any private cloud setup where we can host on our site using their services. For the use cases we dealt with, we have not seen much challenge with AWS. It has been better for us, but due to our requirement of being on private cloud for some applications, we are using Red Hat OpenShift.

We do not have any AI products at this time.

We have certain applications on-prem on physical servers, some on Windows and some on Linux. We had requirements where every time we had to manage extra load, we had to spawn a new Tomcat node. Scaling was one of the issues we were facing, and every time we had to scale up, it was a challenge. We had to procure infrastructure and do extensive configuration and setup for new instance launches. Once set up, scaling down was also a challenge as we did not always reduce capacity when not needed. When we did not have much traffic, we still had substantial infrastructure sitting idle. Simultaneously, during high load periods, we were not able to scale up quickly.

We have support available, but we never had to use it because we have our own internal teams who provide support. We have not encountered any issue where we had to reach out to Red Hat.

It is not difficult to onboard onto Red Hat OpenShift. Once you understand deployment configs, configs, replica sets, the basic components, routes and all, it is straightforward to onboard an application there. This applies mainly to services. Beyond that, it becomes challenging. We have not tried too many things because we struggled with batches. Getting things up and running in AWS, such as Kafka and Elasticsearch, is much easier than doing it on Red Hat OpenShift.

It is cost-effective. The only consideration is that you have to use it wisely. Use only what you need because it is not very difficult to add resources. It is always advisable to get the bare minimum that you need, and then add more when necessary. When you do not need the services, bring them down so you are not unnecessarily using compute resources. If you use it efficiently, then it is beneficial, which is applicable to any cloud platform.

If you are dealing with services and need private cloud, go for Red Hat OpenShift. Regarding cost, if you compare to public cloud platforms, it is cheaper. If you are mostly on the services side and need private cloud, Red Hat OpenShift should be the solution. The overall rating is six out of ten, as it is not seen as a complete solution, but rather as a solution only for services. For other requirements such as integrations or batches, other cloud providers might be more suitable.

Our primary use case for Red Hat OpenShift involves leveraging its container orchestration platform to enhance application modernization efforts. We host containerized applications and integrate GPU capabilities for optimized deployment of AI workloads.

Simplifies transitioning from legacy systems to containerized environments, enabling better scalability and flexibility.

Provides GPU integration and infrastructure that support the deployment and scaling of data-intensive AI workloads.

Accelerates delivery pipelines with robust CI/CD features, helping teams bring applications to market faster.

Scalability and High Availability: OpenShift makes it easy to scale applications horizontally or vertically based on demand. Its high-availability capabilities ensure reliability and minimize downtime.

Built-in Security Features: Enhanced security tools like role-based access control (RBAC), network segmentation, and image vulnerability scans protect containerized applications.

Operator Framework: This simplifies the management of Kubernetes applications, automating tasks like installation, upgrades, and maintenance.

Simplified Networking: While OpenShift has advanced networking features, simplifying configurations for complex setups could make it more accessible to users with varying expertise levels

Resource Management Visibility: Improving the display of limits and quotas issues can help developers better manage resources and avoid bottlenecks.

Availability and capacity reporting

We have approximately two years of experience with Red Hat OpenShift.

Red Hat OpenShift is a stable solution.

I would rate the scalability of Red Hat OpenShift as an eight or nine out of ten. The platform has shown significant improvement with each new version, adding valuable features while making it easy to scale by adding or removing worker nodes and storage.

Red Hat's technical support is good, and I would rate it a nine out of ten.

We provide a range of services, acting as implementers, integrators, and partners with Red Hat OpenShift.

Red Hat OpenShift has a high price, and the licensing model can be prohibitive for smaller customers. Initially, licensing was per CPU, with a memory cap, but the price has doubled, making it difficult to justify for clients with smaller compute needs.

Not tested any other solution

Overall, I would rate Red Hat OpenShift a nine out of ten. Despite the higher price and needed improvements, OpenShift is an enterprise-grade solution that meets most business needs. I would rate the overall solution a 9 out of 10.

I used OpenShift for the enterprise service cost system of a bank. We completed the migration of the bank's core banking system using OpenShift as the infrastructure. OpenShift acts as an orchestration platform and is used as our private cloud.

OpenShift is a spin-off of Kubernetes, built on top of Kubernetes. It has features that enhance security, ease of deployment, and service exposure compared to Kubernetes. It also provides good integration with GitOps and ArgoCD.

Additionally, OpenShift offers an easy-to-use graphical user interface for cluster management, making it more accessible for administrators.

I had to frequently upgrade my cluster due to OpenShift's rolling updates every six months, which I found to be excessive. Making updates a yearly occurrence could be beneficial. In terms of self-service for developers, there is room for improvement. The removal of Grafana and HPA from monitoring caused some issues. Observability could be more robust.

I've been working with OpenShift for four years.

OpenShift is very stable. I've had my cluster running for over four years, with issues caused more by poor monitoring or user error rather than the product itself.

OpenShift is highly scalable, allowing us to manage thousands of pods effectively. We've implemented features like Horizontal Pod Autoscaling to adapt based on demand and integrated with F5 for high availability.

Red Hat's technical support is responsive and effective. I had 50 to 59 support cases, many of which were resolved quickly depending on the urgency and expertise needed.

We moved from a legacy system to OpenShift due to its stability and capabilities provided by being backed by Red Hat.

The initial setup was straightforward, especially on the cloud where it was set up quickly. The on-premises setup was more challenging due to additional configurations required.

We handled the implementation internally with our team, which consisted of three engineers managing the analytics environment.

Moving to OpenShift resulted in increased system stability and reduced downtime, which contributed to operational efficiency. Although it increased costs, it helped modernize our infrastructure.

The pricing for OpenShift includes support and licensing, which costs approximately $400.

We did not evaluate any other options aside from our legacy system before choosing OpenShift.

If you have the skill and experience, Kubernetes can be used in production. OpenShift provides extra coverage in terms of security and management. Have a disaster recovery plan due to frequent updates.

I rate OpenShift at nine out of ten.