Red Hat OpenShift Reviews

We use OpenShift for Health and Human Services to build an integration platform and deliver services. We use it to support public sector companies and organizations and we build an integration platform for the Medicaid information system.

We started using OpenShift because we have an alliance and connection with them from one of our previous projects.

We want to build a solution that can be deployable to any cloud because of client requirements and OpenShift allows us to do this. 

This solution could be improved by offering best practices on standardization and additional guidance on how to use this solution.

I have been using this solution for two years. 

This is a stable solution. 

We are not yet using this solution in production so I cannot speak to scalability yet. 

The customer support for this solution is good. We have a consulting agreement, so we are getting good support.

I would rate their support an eight out of ten. 

We do see a return on investment from using the solution.

I would advise others to review the applicability of the solution to your business. There can be some limitations on the usage of this solution for some products and software.

I would rate this solution a ten out of ten. 

OpenShift's storage management could be better. In the next release, OpenShift should include a console for running scripts.

I've been working with OpenShift for a year.

OpenShift is stable.

OpenShift is easy to scale.

The initial setup is simple, and OpenShift is open-source, so it's easy to install on any cloud platform.

OpenShift 4 is more convenient than 3 because it has better features, which is characteristic of OpenShift's update history. I would rate OpenShift as eight out of ten.

We use OpenShift mainly for building middleware services and web applications. All the applications we have transformed on the microservices architecture have been deployed on OpenShift.

OpenShift could improve by providing the ability to integrate with public cloud platforms. This way we can easily use the services that these platforms offer. For instance, Amazon AWS. However, all the three major hyper-scalers solutions offer excellent DevOps and CI/CD tooling. If there was an easy way to integrate with them it would be beneficial. We need a way to easily integrate with the monitoring and dashboard services that they provide. 

Making use of features, such as serverless technology we easily integrate these services with OpenShift. It would be a win-win, because then you can choose the best of all the worlds, and then build your solution.

I have used OpenShift within the last 12 months.

OpenShift is a stable solution.

The scalability of OpenShift combined with Kubernetes is good. At least from the software standpoint, it becomes quite easy to handle the scalability through configuration. You need to constantly monitor the underlying infrastructure and ensure that it has adequate provisioning. If you have enough infrastructure, then managing the scalability is quite easy which is done through configuration.

We have approximately thousands of users using the solution. The business applications that we build, our customers use them regularly, this includes the banking and insurance applications.

All the platforms that we have, whether it is Pivotal, VMware, Red Hat, Microsoft, or Amazon, are partners or we have an alliance with them. We regularly speak to them and we discuss with them the challenges we face. We have a good relationship with the support.

The initial setup on the OpenShift platform took us a long time to complete for the whole department. It took approximately one and a half months to set it up properly. 

Once the implementation was complete we started looking at how we can achieve reusable scripts for the developers. In a way that they can create the scripts in a quick fashion, instead of them doing the configuration and deployment themselves. It takes time for the implementation, and then it's complex overall too. Once you learn it, then it's quite easy.

The team we have is small for maintenance and support. We have approximately six people managing the whole platform for the entire department. Earlier on, there were more, but the platform has matured, and then the number of applications the platform used to run is going down because they're being moved to Microsoft Azure and Amazon AWS. We keep the team approximately four people who will manage the platform for the next couple of years for the whole department. After that, everything will be on either Microsoft Azure or Amazon AWS.

We are in the phase of moving out of OpenShifh to cloud-native services of Microsoft Azure or Amazon AWS.

If anybody is looking for a solution that can work on-premise as well as on the cloud and gives the flexibility of not tying the solution to the underlying platform, then OpenShift is one of the popular choices you can make.

I rate OpenShift an eight out of ten.

I have used OpenShift in two companies. My earlier company was using a CI/CD pipeline. I customized the CI/CD pipeline in Java and then in Jenkins. We used it to deploy applications in different stages in the CI/CD. In my current company we are using CloudBees Core. They have a CI/CD pipeline and using that we deploy with the OpenShift platform.

If any application team wants to deploy an application on a container platform, we offer a platform for that. If they want to deploy a microservice application and they want to use a microservices architecture, we provide a space for that. OpenShift is running on the AWS platform, which means that deployment is highly scalable and highly retainable. People who want to deploy an application with a zero-downtime infrastructure prefer using the to OpenShift platform.

The solution provides a lot of flexibility to the application team for running their applications in the container platform, without needing to monitor the entire infrastructure all the time. It automatically scales and automatically self-heals. There is also a mechanism to alert the team in case it is over-committing or overutilizing the application.

One of the valuable features is that it's very easy to package an application and deploy it within a short period of time. Since it will be in the CI/CD pipeline, deployment is very easy. And the automation process is very easy and it's highly scalable. It can be scaled up or down at any time. We don't need a person managing the infrastructure all the time because there is automatic self-healing of the application in case something goes wrong.

I've been working with OpenShift for the past two years.

The stability is quite strong, since it's a flavor of Kubernetes. We don't have any doubt about that aspect because we have never seen the infrastructure down for a long time, like a day.

Scaling it is quite easy. We can scale to as many nodes as we want and scale down to as many nodes as we want. That is fast because we have an automated script in place to scale up and scale down the infrastructure. We are quite happy with the solution in that regard.

Documentation and technical support could be improved. The product is good, but when we raise a case with support—say we are having an image issue—support is not really up to the mark. It is difficult to get support compared to other vendors. AWS will get on a call for any problem and start a screen-sharing session. They will immediately start fixing the issue, whereas with Red Hat and OpenShift, we have never seen similar support. When we raise a case, their support people will hesitate to get on a call or a screen-sharing session. That is a major drawback when it comes to OpenShift. Support-wise, they are still lacking.

A friend called me and they are using OpenShift 4.6. They installed a Prometheus box and they upgraded OpenShift and they upgraded the registry. After upgrading, one of the nodes was not able to run the container. When they raised a case, the support guy said that they needed to maintain the old images. Why, when they upgraded the OpenShift, do they need to maintain the old images? My friend called me and told me this and that it is not mentioned in the documentation. He said he raised a case and then followed up with support for the last four days, but there has been no response. The documentation was not clear. Now, we are facing this issue and we don't know how to solve this problem.

That was when focusing on upgrading from 4.6 to 4.7 or 4.8. It seems OpenShift never looks at how to manage earlier versions they sold in the market. Without the proper guidance or support for the product, people will not continue with the product. They need to keep that in mind. It shouldn't be that they only sell the product to the customer and ask them to run the show. They have to think of continuous support. That's why I give it six out of 10.

Before OpenShift we were only using Docker. There was no Kubernetes in our infrastructure. With Docker, there is no scalability. It is just a package. In terms of scalability and availability, Docker will fail. That is why we chose OpenShift as a platform.

The initial setup is okay because there is a straightforward installation process to follow. It is guided by their people and they know how to implement things. We only faced an issue when we started running the infrastructure and that's when support was not up to the mark for OpenShift.

Deployment is quite fast because we have a CI/CD pipeline and we use GitLab for the source code. It can be done within 30 minutes or an hour for the UAT stage. When going to production, there will be a software assessment and then the time needed depends upon change requests and the change window for the application.

We have an implementation strategy for OpenShift. We have prepared a baseline saying that if a given application comes onboard with OpenShift, the team has to learn some basic technical stuff. They have to create a Dockerfile and create the source-to-image. Then they have to use the repository and onboard or copy their source code into it. The baseline documentation exists for people to follow. We will then deploy their application to OpenShift and there will be a dedicated team to further support the onboarding process.

We have seen return on investment. Applications used to run in VMware, but now they are running in OpenShift. There are benefits in terms of scalability and availability, and they can spin up more microservice applications and that is something that cannot be done in the VMware platform.

I don't deal with the cost part, but I know that the cost is very high when compared to other products. They charge for CPU and memory, but we don't worry about it. If people really want to make use of this platform, they don't care about the licensing and costs.

My team members evaluated Amazon EKS and Pivotal Web Services. OpenShift was the market leader in terms of a container platform and that's one of the reasons we chose it for our company.

If you really need an application, meaning one million customers are going to use the application, then this platform will be quite significant. If you only have 10 or 20 or 100 users of an application, OpenShift is not the right choice. The cost is quite high. For that number of people, there is no need to run in a container platform. You need a large number of concurrent users accessing an application and then OpenShift provides the scalability.

We have not considered building our own container platform because it's very tedious to manage the infrastructure and you need a highly skilled person who knows Kubernetes very well, and OpenShift very well. We don't have that kind of team or people with the skill sets.

When it comes to security, we have the Prisma Cloud image scanning so that each and every image is scanned and we get a report regarding the kinds of vulnerabilities there are in particular images. That way, in case there are any vulnerabilities or critical patches that need to be applied to the images, they will be taken care of before going to production. In addition, we have used SonarQube for code scanning and Prometheus for monitoring.

On top of that, there are security properties in OpenShift as well, such as user authentication, user level, access level. But at the image level, we need specialist software to scan the images and report the vulnerabilities. If an application requires additional security in terms of images and the packages, we configure Prisma Cloud in the CI/CD pipeline, so that at each stage it will scan and evaluate the software and report the vulnerabilities to the respective teams.

When we are developing our application to deploy into OpenShift, it can be challenging to refactor the application or redo the application. It takes some time for the team to do that kind of infrastructure stuff at the coding level.

We don't use OpenShift's CodeReady Workspaces because that is for new infrastructure, for people who are new to the OpenShift platform. We just use Docker images and deploy the application.

We're using this solution for newly developed applications in house development applications. I'm an infrastructure architect and we are customers of Open Shift. 

I think the most valuable feature this solution provides is the possibility to have support throughout the whole platform, including logging, monitoring, op features, and the like. It's a simple solution. 

I'd like to see support for more than one server, a mobile user registry. With that, you could divide it more granulary for development and render for testing and using different IDs.

I've been using this solution for six months. 

This is a stable solution. I think we're going to stick with it. 

This is a scalable solution, we have around 40 users. 

We previously used IBM WebSphere.

The initial setup is straightforward, it took around three to four days. We used the support and four or five of our engineering personnel for deployment. 

The licensing costs are quite cheap compared to other similar solutions. 

Our primary use case is to move applications to OpenShift in order to remove legacy solutions. 

The most valuable feature is the high availability for the applications. 

I don't really see any improvements that need to be done.

I have been using OpenShift for two to three years. 

We don't have bugs or glitches. We only have problems that are connected to our deployed applications, the applications that weren't fully prepared for the OpenShift deployment. 

I haven't contacted their technical support. Our devops team does contact them. They contacted them in regards to some problems with the operations. They were satisfied with the support. 

The initial setup was very simple. It was done by our devops team. They did the entire deployment. 

OpenShift is the way of the future. I would recommend it. 

I would rate OpenShift a nine out of ten. Not a ten because it's not a standard solution and the endpoint protection user has to prepare to use it with documentation or has to get training from other people. It's not easy to start because it's not like other solutions. 

Used for multiple environments and clients. Providing details is not possible due to NDA constraints. This main purpose of this kind of Platform is a Production grade Environment where Data Protection and Release Management is managed by the Service Provider.

We are able to operate client’s platform without downtime during security patch management each month and provide a good SLA (as scalability for applications is processed during heavy client website load, automatically).

All security features. Our company is focused on sensible information management and security is the most important part.

The other feature we don't find elsewhere is the ImageStream feature which helps to manage Environments or Release promotion.

We submitted over 25 requests for enhancement to Red Hat from the beginning of the OpenShift version 3.1, and they were implemented in the last version of the product 3.11.

The main drawback was the upgrade from Openshift Enterprise 3.11 to Openshift Enterprise 4 up to now.

But the new release Openshift Enterprise 4.2 add a way to migrate from old cluster to the new one easily based on Appranix solution. Namespaces with all data-protection mechanism is taken into account.

This product is Production Ready. The Common Red Hat ERRATAs (security, enhancement, bug fixing) + Platform ImagesStreams provide a way to be updated with Security Constraints without backward compatibility issue.

Platform agility provides the Blue Green deployment workflow which makes available a new Business Unit version easily. ITOps Engineer defined resource capping, this help to gain stability.

ITOps Engineer manage scalability easily aligned with Client's resources and its SLA's thanks to native features found in this product.

Based on Kubernetes vanilla, or Rancher or other PaaS, security is quite heavy to integrate with RBAC, network policies or namespaces isolation.

With Openshift Origin or Enterprise we avoid security management which is managed automatically at namespace level.

Rancher was in the loop and kubernetes vanilla in ~2015.

Developers maturity is a key point.

We have a PaaS solution built on OpenShift with more templates and shared services for a containerized application environment.

So, the solution built will be using PaaS that is built on Openshift and hosted in a hybrid PaaS (dedicated & AWS) for building, deploying, and managing microservices-based applications.

We will be using many features of OpenShift for scalability, availability, and security (TLS/OAuth, IdAM integration).

This solution is providing a platform with OOTB features that are difficult to build from scratch. As the organization for which I am building solutions is embarking on a digital transformation journey, OpenShift is providing one of the key platform capabilities for the digitization of the application landscape.

The features that I find most valuable are:

• DevOps
• Container orchestration
• Scalability
• Multi-cloud options
• Flexibility in choosing routers, load balancers, and monitoring tools
• Configuration options for creating an automated DevOps pipeline using tools like Maven, Ansible, and Jenkins
• Easy configuration for scalability

Most of the configurations are command based. If we can have a GUI-based configuration with better flexibility then it will be great.

You need to have in-depth technical knowledge of the platform to do any kind of application setup due to the complexity of configurations related to infrastructure, security, etc.

Maybe in the future, we can get multi-cloud options such as GCP, Azure, etc.

I have not used any other container orchestration platform, except Kubernetes, which is the base platform for OpenShift.

My role was not one of evaluation, so I did not participate in choosing the product.

OpenShift is a primary tool in my daily work and in the project I have been working on in recent years – TV streaming services used widely in the U.S. and outside. OpenShift is used for intensive DevOps and running pieces of the project adhering to the microservices architecture. The project's architecture includes physical servers in tens of datacenters. OpenShift plays a central role in developing, testing, and running specific software.

Our small team developed and rolled out everything to production in a short time, mostly thanks to OpenShift. It saves time. Using it, I just work on integrating services without worrying about containers and whatever is needed for them. OpenShift is a tool that does a lot of work for you. You just need to invest some time learning it.

OpenShift helps by doing a lot of work for us. I love to automate everything and OpenShift was been born to do so. It takes care of the network layer itself and I don't need to dive into it; I can work on a top level. Our project has numerous services designed to run in Docker containers, and we have run almost all pieces of our TV services in OpenShift.

I think that OpenShift has too many commands for running services from the CLI, and the configuration files are a little complicated. This scares newbies from learning it. I hope that the OpenShift developers will improve this "dark side" of OpenShift.

OpenShift has been running for the past three years, since the project started. We were developing the project's architecture, trying different solutions. In the end, we chose OpenShift as a well-known and intensively developed software, with many really useful features.

Migration of old and custom APIs and development environments, for both internal and client-facing use. This migration has been going on for two and half years now. It is a rather large endeavour. I would estimate we have another six to nine months ahead.

No longer do I have to pay VMware large amounts of money to only run in-house solutions. (I give a particular heartfelt thank you for that).

This is an easy question to answer: the virtualization of my APIs. 

There have been some issues with security, in particular, that we had to address. At times they make it “clunky." I am quite confident these parameters will appear in the next releases. They have been reported as bugs and are actually in process. Despite this, the competition is rapidly losing ground.