OpenShift Container Platform Reviews

We are moving as many applications as possible to a containerized environment. In terms of our environment, we have multiple data centers. One, of course, is for redundancy. Most of them are hot-warm. They're not hot-hot or hot-cold, depending on how you look at it, but pretty much everything that's important is fully redundant. That would be between our own private data centers and within Amazon across regions.

We have an on-premises and private cloud deployment. Amazon is the cloud provider. We've got some Azure out there too, but Amazon has been the primary focus.

Centralized control of container resources is most valuable.

There should be a simplification of the overall cluster environment. It should require fewer resources. Just to run a simple Hello World app, it requires about seven servers, and that's just crazy. I understand that it is fully redundant, but it's prohibitively expensive to get something simple going.

We've had a very difficult time going from version 3 to 4. We need to go to version 4 because of multiple network segments that may be running in a container and how we organize our applications. It's very difficult to have applications from different domains in the same container cluster. We've had a lot of problems with that. I find it to be an overcomplicated environment, and some of the other simpler containers may very well rise above this. 

It has probably been in use in the organization for about a year and a half.

It is fine. I've not heard anything negative about either the performance or the reliability.

Scalability is one of the primary reasons for going with a containerized environment like this. I have not heard that we've had any restrictions there, and I would be shocked and remarkably disappointed if we did. We have not hit any scalability issues yet.

I personally do not have any experience with them. I'm quite sure our low-level implementers do. 

They were just different JBoss containers. It really wasn't a containerized environment. We're looking at some of the AWS solutions.

I didn't do the initial setup. Some other people did that. We're all pretty uber geeks. So, I'm quite sure that we'd be able to figure it out naturally. Because it's a fully-featured and complex environment, you'd have to bone up on OpenShift to figure out how to install it properly, but I wouldn't expect it to be onerous.

Our implementation strategy was to start moving applications to be containerized and then implement them in the OpenShift. We were moving to OpenShift running on our own ECS on Amazon, but we have a lot of on-prem as well.

We're still working out the kinks. A part of that is our own dysfunction in terms of how we organize our apps, and then there is the problem with running apps from different domains in the same container. Some of those are our own self-imposed problems, but some of it is due to the OpenShift complexity.

We definitely hired different experts, but for the most part, we went out and hired people with the expertise, and now, they're employees. So, I'm quite sure there were consultants in there, but I don't know that offhand. 

We have not yet seen an ROI.

It depends on who you're talking to. For a large corporation, it is acceptable, other than the significant infrastructure requirements. For a small organization, it is in no way suitable, and we'd go for Amazon's container solution.

Additional costs are difficult for me to articulate because ours is a highly-complex environment even outside of it.

Ensure that you need all of the features that it has because otherwise, it's not worth the investment. Be careful what version you're getting into because that can be problematic to change after you've already invested in both the training and the infrastructure.

I would rate it a seven out of ten. Considering some of the problems we've had, even though some of them are self-imposed, I would hope that a containerized environment would be flexible to be able to give us some options there. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We embarked on OpenShift as our first enterprise container technology.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The price needs to be improved in OpenShift Container Platform.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenShift Container Platform needs to work on integrations. 

I have been using the solution for two years. 

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

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

Red Hat offers good technical support. 

Positive

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

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

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

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

We use it mainly for the retail space.

Everything is packaged into OpenShift Container Platform, whereas with Kubernetes, you have to create many operators. With OpenShift Container Platform, you just have to point and click.

The setup process is not great and could be better.

We have been using this solution for about two years, deployed both on cloud and on-premises. We can fire up an OpenShift cluster in Amazon. We are using the latest version.

It is very stable and solid. 

It is a scalable solution, and we have more than 500 users. We have about 15 people that manage all the different clusters.

The setup of OpenShift Container Platform is a bit complex when you set it up for the first time, but it is good after setup. The first time we deployed, it took about two days, but since we have mastered the solution, it no longer takes as long. We did not use any integration. Because we buy the Red Hat licenses, they just give us the green light.

We have seen a return on investment.

It costs about $10,000 for a three-year license.

We tested Swamp, Rancher and the US version of Kubernetes before OpenShift Container Platform.

I rate this solution a nine out of ten and recommend it to others.

We can deploy microservices on the fly. The time to market has improved for our organization. If any issues are found or any incident is reported, fixes or hotfixes can be done within a fraction of a second. These KPIs are the improvements.

In terms of security, it supports user management. An authentication and authorization solution is embedded in that. There is also certificate management in terms of how it rotates the certificates and the kind of TLS mechanism it uses for the end-users as well as for the communication within a cluster. It also allows our images to be scanned before deployment.

OpenShift comes with a lot of marketplace operator-based solutions. It also allows any open-source operator-based solution. It could also be a Helm Chart-based solution for deploying any cloud-native application or workload.

OpenShift is much better than others as an upstream project for Kubernetes. It also has certain features that are not there in any other flavor of Kubernetes. For example, Source-to-Image (S2I) is a wonderful feature in OpenShift where your code can be in the source repository. It can be built and deployed with a click of a button. That helps the developers' community to deploy their code and see the results on the fly.

In OpenShift, there are a lot of things that are good as compared to any other Kubernetes flavor. The console or the GUI of OpenShift is awesome. You can do a lot of things from there. You can perform administration tasks as well as development tasks. 

The RBAC user management that comes packaged with OpenShift is not there in other Kubernetes. That's a very nice feature. 

The upgrade mechanism is also very good. The upgrades are pushed by Red Hat, and with just the click of a button, your OpenShift cluster gets upgraded. That is another very nice feature. These are a couple of things that I like.

A lot of improvements are required in OpenShift when it's deployed on a public cloud such as AWS, GCP, or AKS. 

OpenShift has certain restrictions in terms of managing the cluster when it's running on a public cloud. For example, identity and access management integration with the IM of AWS is quite difficult. It requires some open-source tools to integrate. This is one area where I always see room for improvement. 

In addition, the RBAC access is only controlled by the OpenShift internal mechanism, whereas the authorization part can be handled by any public cloud. We are already managing and maintaining users in the cloud environment. So, a repetitive or duplicate RBAC mechanism is not required. 

I have been working with this solution since 2018. It has been more than four years.

It's a stable solution. However, most organizations are lagging in upgrading the versions because of various reasons, such as business downtime and the risk involved behind that. If you don't upgrade it on time, then there will definitely be bugs. It normally doesn't create many issues, but we have had instances where when we go to the Red Hat product support team, they always mention going for the next upgrade or the next possible upgrade so that a bug is completely removed. However, it's not always possible to do that. So, stability-wise, it's quite stable, but no product can be perfect. In the version that we are running, there are a couple of bugs, and we have to live with them, unless and until we upgrade to the next version.

Because it's on a public cloud, it's very easy to scale up.

In terms of its users, we have close to 100 users. There are a couple of DevOps engineers in that, and then there are administrators who manage and maintain the cluster. The rest of them are developers. These are the primary users.

It's being used quite extensively, at least in two of our markets. I have no idea about plans to increase the usage of this product, but I also don't see any reduction in its usage in the near future.

Their support is very good. We have a premium subscription for our organization, and we get support whenever we need it. It's quite good. It's the backbone of this product. I would rate them a nine out of ten. Sometimes, the support professionals work from different geographical regions, and when there is a shift change, we lose some time. It happens rarely, but it has been a cause of concern a couple of times.

As a partner for helping us create the platform that we need, I would rate Red Hat an eight out of ten. In terms of support, they provide all the required commands, code pieces, or files required to troubleshoot the issue. They also provide support during any new installation or upgrade.

Positive

When I started working on this project, OpenShift was already there. I don't know if and what it was migrated from. In the accounts that I'm handling, we had OpenShift, and applications were containerized and migrated to OpenShift.

We use other Red Hat products. We use Red Hat OpenStack, and we also use GlusterFS storage from Red Hat, which comes as a part of OpenStack. Apart from that, most of the virtual machines are already using RHEL. OpenStack, for us, is on a private cloud. It's not as friendly as AWS public cloud. Integration-wise, it's seamless, but if we want auto-scaling at the OpenStack level, it's not possible for us. 

An advantage of using multiple Red Hat products together is in terms of the support we get from them. That's very good. If we consider any Kubernetes flavor running on any public cloud, getting support on the components we have deployed is difficult, but Red Hat supports that. Whatever we have deployed, they can provide support on that. The support provided by Red Hat is really great, and that's why they're asking for a premium cost for that.

It was already done before I came, but I know that it was done using Ansible stack and Ansible code. Its deployment is quite straightforward. The 4x versions of OpenShift are very easy to deploy. The older 3x versions were quite difficult to deploy, but in the latest versions, especially on a public cloud, it manages everything. It spins up your cloud virtual machines, installs OpenShift on them, and provides you the endpoint to access it.

If the Ansible code or scripts are available and ready, on a production system, it takes about one hour to one and a half hours. It also depends on how many virtual machines you require to install OpenShift.

Its price is a bit high because it's a premium product, but as long as the business is ready to pay for that, it's okay. 

I would recommend evaluating the product thoroughly for your requirements. That's because OpenShift comes with a lot of bells and whistles, and most organizations don't need that. It also comes with auto-managed components. If you are looking for less-managed components on a Kubernetes cluster, then Red Hat OpenShift is the only answer.

We didn't consider building our own container platform. There are different flavors available for Kubernetes. We use OpenShift, EKS, AKS, and GKE. Even OKE is coming up. It depends on what different markets of our organization prefer and what is cost-effective for them.

Overall, I would rate it a nine out of ten because we are quite happy with it. There are a couple of restrictions in terms of managing clusters on a public cloud, but other than that, it has a lot of inbuilt components, which are helpful for managing the cluster better.

Our client deployed OpenShift on a bare-metal server, and they use it to offer their customers a platform-as-a-service solution with metered billing. It's pay-as-you-go. We are currently developing our own platform. For the most part, we have enough developers, but we'll go to Red Hat when we need support.

OpenShift is an improvement over legacy monolithic applications. With OpenShift, our clients can see the new features quickly, and developers can get any software they need from the Red Hat Marketplace. It has improved our product development and the existing workload on business material applications running on OpenShift. It has improved the performance of our company's IT department. 

OpenShift complies with the security center, where the CS image is hardened by default. OpenShift is very secure. When there are updates, OpenShift will update all the patches necessary throughout the entire cluster platform. It takes care of that easily, reducing many administrative tasks. Using this product improves our compliance code significantly.

The pipelines in OpenShift are handy for developers to build and automate things quickly. It's easy to bring things online. Options are helpful for the customized solutions we can do with this product. Overall, the automations are well aligned with OpenShift. That's what I see.

OpenShift's code-ready workspaces reduce project onboarding time by about 70-plus days while reducing time-to-market by around 50 percent. 

The operating system has a live update and is more secure than any other. It's made for Atomic OS, a lightweight OS new to the market. I also like the source-to-image capabilities. The customer can directly deploy their applications from the repository. It's a highly flexible and easy way to deploy into production. 

It's a simplified network for exposing their application to the outside world. Red Hat has good built-in oversight, where it monitors the cluster performance and records everything built inside the cluster besides OpenShift. Of course, Red Hat is a pioneer in this kind of auditing. 

Telecom clients can use OpenStack as their private cloud to access secure resources on demand. When they deploy to OpenShift, it's easier for them to have a cloud-like field on their own data center. OpenShift and OpenStack are integrated. It's an ideal combination. The infrastructure created in OpenStack is a robust private cloud solution. If the developer wants to consume resources within their organization per the utilization, OpenStack is the right platform for building their private cloud.

In terms of innovation, features, and functionality, a public cloud has much more than OpenStack by itself. I prefer OpenShift on AWS or Azure Cloud. That has made it easier for the customers to benefit because they don't need to worry about their managed solutions anymore. It's the customer's choice to manage services through OpenShift or on-prem. OpenShift can be run on all platforms, including VMware, public, private, etc. It's a great solution from a consumer choice perspective. 

The codes are customized and fixed only for their own environment, so it's more secure, but we cannot assure the client's security. However, the code is validated, and Red Hat support will address any vulnerabilities or security issues that arise.

The support costs are too high. 

I've used OpenShift for the last two years.

OpenShift is a highly stable product if you're using it as a managed service. 

OpenShift is scalable. 

I rate Red Hat support nine out of 10. 

Positive

Setting up OpenShift is fairly straightforward. It takes about a week to plan and another to deploy, so two weeks max. 

They can reduce prices because Kubernetes is open-source and freely available to customers. The license cost is for deploying on-prem, so it's costly to go to a client's location to deploy things compared to open source. If they reduce the cost, more customers will choose OpenShift.

I rate OpenShift Container Platform 10 out of 10. This is a great product. Red Hat has been in the field for more than 25 years. Each product they release is more innovative and cutting-edge.