Red Hat OpenShift Container Platform Reviews

OpenShift Connect Platform is on a private cloud setup. There, we deploy all of our applications.

They have built on top of Kubernetes. Most of the Kubernetes latest technology is already supported by the solution. The only thing is, we need to change our view of the routes. 

The stability needs improvement. 

I have been using OpenShift Container Platform for one year. 

Stability wise, I think there were few issues, but I'm not sure whether it was on an organization level or it was from OpenShift. The stability is a seven out of ten. 

The initial setup is not very complex but it is not as easy as Kubernetes. 

We have to pay for the license. 

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

It is used for containers.

It is very lightweight and can be deployed very fast, especially when it comes to containers. It can spin the web and the DB very fast, so we don't need to deploy the server and the VM. Everything is in the container.

There is room for improvement with integration.

I have been using the solution for one year.

The solution is stable.

The solution has good scalability. I rate the scalability of the solution a nine out of ten. There is also room for improvement in the scalability of the solution.

One or two users are using OpenShift in our company, and we hope to increase the usage.

The support is very good. Their response and technical skills are good.

I have used Docker before. We shifted to OpenShift because we were using Docker for self-learning.

The initial setup is complex. The solution is deployed on-premises. However, it can also be deployed on the cloud.

To deploy OpenShift, first, you must get the installer and then prepare a minimum requirement. You will need a key physical server as a load balancer. OpenShift has a lot of roles in its nodes, with worker nodes and master nodes. Since different nodes have their role, the setup is complex. You will need to set up ten or 12 nodes like this. After you have set up all the nodes, you need to do the integration and set up OpenShift.

It takes a month or a year to deploy it.

The deployment can be done in-house. There are two people required for maintenance.

The pricing is expensive for licensing. The customer has to pay for the license.

Before choosing OpenShift, I advise you to know your application landscape very well. Only then will you know if you require OpenShift. If you are unclear about your application environment, layout, and structure, it is potentially not a good idea because you don't understand it.

Overall, I would rate the solution a five out of ten.

On-premises

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.

On-premises

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 have working nodes in the OpenShift Container Platform, we have six working nodes and we have a master working node. We have a Jenkins pipeline to operate our deployment and, CI/CD operations. We create some pipelines to deploy the code to the containers and those containers activate on OpenShift Container Platform ports or working node ports.

We had old-fashioned programs before switching. We started to create a new architecture for our developers. After generating our Java framework, we were looking for a new platform to run our systems. For our business clients, we need flexibility, and scalability, while we are searching the environment, because of the regulations. We need some private cloud options, and cloud vendors did not have private options.

I have found the ability to scale up is most valuable. If you do not have any hardware limitations, you can scale up during your busy timelines. It is an excellent tool so you can deploy these products to any of the public clouds. If the regulations allow you, it is straightforward to deploy your codes to another public cloud or another platform. OpenShift Container Platform gives you an opportunity to be flexible.

The monitoring is problematic. The product monitoring tool does not work for us. We had to purchase the Dynatrace solution to monitor our product and our applications, and this is a weakness of OpenShift Container Platform. If there was some orchestration with mini services because microservices can be complex.

I have been using OpenShift Container Platform for the past four years now.

The scalability is excellent. Last year we had some hardware limitations, we reached the limit of our hardware platform. After we enhanced our hardware we have not received any additional alarms.

Technical support from my experience is the middle of the road.

Neutral

The initial setup can take twenty-five minutes if it is a large stand-alone monolith. We have six steps in our pipeline. It changed to application certification, for little microservices, it takes approximately two to four minutes. We have six administration users who arranged the pipelines and port visualization for port monitoring.

We currently have an annual license renewal.

I would recommend using OpenShift Container Platform, giving it a rating of eight out of ten.

Private Cloud

Other

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.

Our customers value the monitoring and logging functionalities which are also our most valuable features. 

Our customers like the service mesh, so we integrated these to improve customer satisfaction.

It is difficult to deploy the OpenShift cluster in a bare-metal environment. For example, when there are errors during the cluster deployment, it is hard to find the error on any documentation. So, from the cluster deployment perspective, there could be improvements.

Also, the machine config and machine config tools need improvement. The machine config tool implements changes related to files over the worker and master nodes in OpenShift. However, sometimes it starts without warning, and it is unclear how the error can be fixed.

In terms of additional features, it will be good to have the support of the CNI or OVN for the Multus CNI. Currently, in OpenShift, the additional networks added by the Multus and the pods do not support the OVN CNI plugin. OVN is supported in OpenShift, but only for the non-Multus interface, which is the primary interface of pods.

We have used OpenShift Container Platform for the past four years. We are using version 4.10, and it is deployed on-premises.

It is a stable solution. We have not had any issues or found any big bugs. However, even though it is stable, we observed that the latest versions of this solution are usually less stable than the previous versions.

Therefore, if I were to rate the stability, I would give it a six out of ten because there are a few minor issues in the latest version.

OpenShift Container Platform is great from a scalability perspective. To my knowledge, there is no limitation when adding many compute nodes in OpenShift. It just requires a lot of hardware since we use on-premises at my company. You will need to increase the capability of master nodes if you want to add worker nodes.

I will rate the scalability a six out of ten.

Technical support from Red Hat is very good. They are proactive and always reply accordingly, depending on the tickets' priority. We never have any issues with the support. I will rate the technical support a ten out of ten.

Positive

The initial setup was very complicated. It took us about a week to deploy a basic three-master and a two-worker node cluster. I was also not aware of the OpenShift documentation at the time.

From an administrative perspective, it is difficult for new people to understand. A few coworkers from different backgrounds who moved to use OpenShift found it challenging. However, it was not as difficult for me because I am familiar with OpenShift.

I rate the implementation experience a five out of ten.

I don't know the exact licensing costs as I never purchase licenses for my organization.

I rate this solution a seven out of ten.

Regarding advice, it depends on the use case and what kind of platform a company wants. For example, if they want something on Kubernetes with at least basic amenities, like logging and monitoring and similar things out of the box, then OpenShift is good for them. But, if they want to modify the Kubernetes how they want, it is not a good solution because it is not flexible. OpenShift Container Platform gives you a lot of features out of the box, but you cannot modify it. So, if they want to use Kubernetes how they want, then the open-source Vanilla Kubernetes is better for them than OpenShift.

On-premises

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

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

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

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

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

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

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

The initial setup can be hard.

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

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

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

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

So far, the scalability is good. 

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

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

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

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

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

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

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

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

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

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

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

I'd rate the solution ten out of ten.

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

For the majority of use cases, we're actually building APIs for both the enterprise API and also OpenAPI. It's mainly for integrations for the backend. We implement the system for the customer.

It's deployed on a private cloud and on-prem. We are using version 5.8.

The banking transactions, inquiries, and account opening have been the most valuable.

The monitoring and logging could be improved. I think it would help developers in terms of provisioning the database and the whole development lifecycle.

I have been using this solution for two years.

Technical support is standard.

Initial setup was fine. If it's set up on-premise, it takes longer, maybe about four or five days. We actually deployed it on the cloud once using IBM. That takes a shorter amount of time because it's a managed service.

We used a consultant. 

I would rate this solution 8 out of 10.

If you care about your performance and the support, I would recommend it for enterprise mission critical applications.

Hybrid Cloud

We are using OpenShift Container Platform to build microserivces which are financial business logics, such as payments, transfers, KYC etc. These serve as the defacto logic consumed by any channel. We are also leveraging the networking and securing capabilities of OCP which serves to secure and control on granular level.

First and foremost we have benefited vastly in cost reduction.

The abstraction provided by OpenShift of the underlying infrastructure gives us the ability to extend the application across data centers (on-prem or cloud) that gurantees the uptime by 50%.

The ability to push new changes without hampering the current version given us almost 100% business continuity and zero downtime deployments.

OCP gives the ability to use the resource effectively which has helped in maximizing the use of underlying infra and it further has the intel to scale up the  the running app in case it is running out of resources thus auto-scalablility is inherent when apps are ran on OCP.

It would be unjust to not mention the automation capability introduced by OCP makes the whole development and deployment seamless and almost eradicates the operational overhead of running this platform.

The auto scalability feature, which is based on smart agendas, determined from pre-prepared rules is the most valuable feature. You can also create different routes for deployment. Deployment types can be provided with an identifier, such as AB deployment. This really helped in rolling out releases without disrupting services for the end-users.

Secondly, there is the ability to control at a granular level. For example, they can release two versions of the same service and control the traffic towards it to a specific percentage.  Other organizations don't seem to use this feature in the same way we did. Additional rules can be specified to determine individual versions of a service, and rules for governing users access to such services.

Marketing can also make use of OpenShift by analyzing logs to provide useable data. This is one of the features that I really like about OpenShift. It is also a secure environment, with user access configurable at a very granular level. Depending on the API and the ecosystem, it is possible to completely plug and integrate. You control how the deployment works and the testing process.

With OCP 4.x the capability of configuring and controlling your ingress controller has also introduced an immense ability to provide an experience which is pertinent to a particular app. With this we can introduce app specific compliance and security without enforcing similar requirements on all services, which was the case with earlier versions.

From a networking perspective, the routing capability can be matured further. OpenShift doesn't handle restrictions on what kind of IPs are allowed, who can access them, and who cannot access them. So it is a simple matter of just using it with adequate network access, at the network level.

It should be possible to whitelist IPs so that you can allow and restrict access to the API. That would be a fantastic feature. OpenShift would then encapsulate the entire security and access. This is one improvement that I would seriously want our client to have, and for that reason, I have joined the OpenShift community, and it is a project I could probably work on myself. 

The second thing is that deployment is more of a strategy rather than a feature in OpenShift. Although you can create different routes, and it works fine, it is not an innate feature of OpenShift that it understands that you want to run specific versions of the same service as needed. Though you can define routes to serve different versions.

I have been using OpenShift Container Platform for almost four years.

It is very stable when it's running. So far, I haven't found any issues. We went through operating system upgrades. We did need to perform some patching, so there was some vulnerability and there were many tasks we had to undertake to assist with stability. In fact, we use two clusters. One of them is used for non-production purposes. It is a developer's structure and is a very stable solution.

Further by the design OCP will keep running the cluster is left with only one node, which makes it very robust and reliable platform.

The auto-scalability feature, which is based on smart agendas, can be determined from pre-prepared rules. You can also create different routes for deployment. Deployment types can be provided with an identifier.

This is very flexible and saves resources when you don't need them, and scales up when you do. This is a very powerful feature.

We used the Redhat TAM service. They assign a technical application manager to you, and we have used that. The support is very, very responsive. They respond very quickly. What I like about them is that they have a very precise, clear and rationale way of working they will ask guide you to take a decision towards one single solution you require. That's it. They will come back to you and provide pinpoint in-depth guidance into the problem that you have.
Unlike most support companies, you usually obtain a workable solution in a good time frame.

Positive

We were using 3.x and now we have swtiched to managed OCP 4.x on cloud. This has given us helped in reducing cost and given the ability to expand and configure OCP without involving infra team, what was a months process has reduced down to minutes.

3.x was a complex setup but with 4.x this has been addressed drastically and now it comes with a setup engine which handles 90% of the setup itself. Though it still does gives you the ability to do it 3.x way but it still less complex than 3.x.

This was an in-house implementation.

Costs reduced by 70%, this includes infra and operation costs.

It is a costly solution but then again, it's intended for enterprise-level business, and the license has to reflect that. It is appreciated what the GPU's processing power requirements will be higher. The licensing is very flexible. The license is related to the processing power you need, and the infrastructure of any clusters which go with that. If your current application, internally, has more then 5 workflows that have significant resources requirement I will suggest to consider using OCP. Anything below would be more costly on OCP in terms of license and infra setup.

We had a comparison between OpenShift, Azure Kubernetes Services and Elastic Kubernetes Services (AWS) but OpenShift is more mature, it has understands the corporate more especially from security and compliance perspective. We also have the leverage to be multi-tenant with OCP over IaaS that lets us leverage the best of all infra flavours out there.

A common mistake is to assume that the solution can change the architecture type. e.g. some people think by using this solution they can change their application architecture into a microservices architecture. OpenShift is an orchestration platform. These types of solutions are not intended to be run as a microservices architecture. Very often, the two become synonymous which leads to decisions which incur huge costs. Especially the conventional thought process kicks in and OCP looks more like an application server rather than a platform.

As the cost of this product is expensive it should only be considered for large enterprises. There will also be a need to hire technical people, and this may also involve a training cost.

There has to be a cost-benefit. It can be done as a single solution, but the solution itself has to be huge. 

You also need to make the best use of the solution. If you are processing millions of transactions, that would describe an adequate use. You need to calculate the solution costs against the work it is designed to do, otherwise, it becomes a cost overhead. Certainly, for a single application, it would be a waste of money.

I would rate OpenShift Container Platform a nine out of ten.

Last but not the least, considering running multiple application on OCP to maximize the cost of licenses and it the budgeting of OCP should not reside with an application team where it will hard for them to budget and run the platform and would innately require other application teams to have a separate cluster which dissolves the whole purpose of OCP.

Public Cloud

Microsoft Azure