Red Hat OpenShift Reviews

We were running many of our products on OpenShift.

We had to discontinue this solution due to many limitations.

Has a better UI and is good as a CICD solution.

Some of the features are platform-specific, so if it is ported to other cloud solutions it requires a lot of changes.

I am using OpenShift as a container platform to host various applications in a containerized environment.

It has really helped me a lot in debugging the issues.

The most valuable thing about it is the support available. 

Installation and setup are a bit tedious, especially in a proxy environment.

Java and WildFly.

OpenShift is great for flexibility, agility, and speed of delivery. We use WildFly as an application server. We have not started to use OpenShift mainly, yet.

• WildFly, because it standardizes infrastructure.
• The git repository and docker. Git is essential for source code and Docker for infrastructure.

It would be great if it supported Bitbucket repositories too.

In short, OpenShift is about running and developing applications in a very efficient manner without the need to mess with virtual machines and other environments.

Longer version: OpenShift is a system for developing and running container-based applications. It uses Kubernetes for the orchestration and deployment, but it is much more than that. With excellent self-provisioning capabilities, it helps power users (developers and administrators) to do their jobs in the shortest time possible. If applications are built with the best practices for cloud or on-premise deployment, they will run well. Such setup saves time and hardware resources by being optimized from the start. Security is also an important part of this solution. By default, things are running with limited privileges and securely confined to their own resources. This way, different users and projects can all use the same infrastructure.

Self-provisioning support saves a lot of time and unnecessary work from the system administrator who can use this time to run and monitor the infrastructure. For the developer, this means less time waiting for the provisioning and excellent flexibility for development, testing, and production. Also, in such systems it is easy for developers to monitor applications even after deployment.

• Excellent GUI support, so one does not need to use the command line client for almost any tasks.
• Great support for building images directly from Git repositories with hooks.
• Great integration with Jenkins for constant integration and development.
• Supports all the major languages and environments - PHP, Java, Node.js, Ruby, etc.

The area for improvement is mostly in support for legacy applications. I believe OpenShift/Kubernetes will play an even more important role in the future, where it will eliminate a lot of the need for virtualization solutions. Such solutions are the proper building blocks for DevOps needs.

I rate this product a 10 out of 10, as this is one of the best options for developing and running modern applications. Easy to use, easy to scale. Offers great command line and Web client. Excellent also for automation.

• Continuous integration between different technologies

• Single Sign-On

• Security enhanced

• Easy deployment and follow-up of entire pipeline process

We connected Jenkins as the main build operator with API calls to the OpenShift Pipeline. It is amazing the amount of time saved. You can see the logs of pipeline process on Jenkins and follow it in real-time or by notifications if something goes wrong. We used Slack for build notifications as well.

• Build

• Deployment

• Product delivery

These areas would save time for the entire team.

We have used this solution for one year so far. We have been following all the improvements on the tool since the launch.

There were only deployment problems on my end, but I did have to reconstruct pipelines.

There were no stability issues.

There were no scalability issues, but only some Docker issues.

Customer service is perfect.

Not available.

I started using another technology, whose name I don't recall. The goal of OpenShift is to make things easier by connecting all tools in one switch.

The first installations were tricky. There were some bugs and workarounds, but it was never hard.

Newer versions were smoother and the problems no longer exist.

The first implementation was done on my own, where I was learning, testing, and exploring. All the documentation is updated on their website.

The ROI is in terms of productivity and saving time. I can't measure how much money I saved by using this technology, but know for sure that the money was well invested.

Go for it. Red Hat is professional on solutions.

I tried Rancher and other similar technologies, but their goals weren't the same as mine.

Try using OpenShift Origin (free version) for a instance. It is pretty stable and has new nice features. The code is on GitHub, so you can always suggest improvements and bug fixes.

The software defined network is the best feature in my opinion. While not as flashy as the container scheduling and health monitoring, the usage of a software defined network means administrators existing expertise can be leveraged.

The SDN's usage of existing protocols means it's easier to modify and customize OpenShift.

I've assisted our clients in streamlining with development and deployment processes, achieving orders of magnitude reductions in time to market.

Possibly, the most complicated part is the configuration for an application. Other solutions do have easier ways to configure an application deployment, but they also come with greater restrictions.

Three years. I've been involved since some of the initial installations with Red Hat pilot customers.

No, I have not had any stability issues with OpenShift.

No, OpenShift is imminently scalable. Easy to deploy more containers. Easy to deploy additional nodes. Automating dynamic scaling capabilities was trivial.

OpenShift is supported by Red Hat, with their usual industry leading SLAs.

As a consultant, I have no installed OpenShift for my own solutions. But I have worked with Openshift and Cloud Foundry. Both are excellent products. But some of the limitations inherent in Cloud Foundry made it unfeasible for several of my clients.

The initial installation is trivial. Red Hat has automated the installation using Ansible.

OpenShift is available in Red Hat's usual open source support subscriptions.

Not really applicable to my situation. I support several products and recommend, then implement the best solution for my clients' needs.

While a PaaS is not for everyone, OpenShift mixes the best combination of new technology with the reuse of existing technology. This reuse of familiar options gives OpenShift simpler integration, and greatly reduces the learning curve for new users.

If you need a PaaS with the ability to customize it to handle more complex deployments using protocols other than HTTP, or you need a solution that will scale from a developer's workstation to a multi-site global installation only, OpenShift gives you that flexibility.

The use of creating environments (Development, Staging, and Production) using easy to use PaaS dashboard, and through the use of RHC.

It has a simple yet powerful way of managing environments, without many governance issues.

The product has helped kick off applications for developers at speed. New joiners can just start using the platform, without bothering to set up an application stack and/or server stack on their local laptop.

It has also helped us ship products at ease, using the Docker and Kubernetes platform, which forms the basis of RedHat OpenShift 3.

Scaling has a few defects, such as not scaling up at threshold values. This needs improvement. Also, require little more integration perspective, such as Service Desk integration and Source Code/CI integration.

I rated the solution as an eight out of 10 for two reasons:

1. Autoscaling issues. It does not increase in a seamless manner. Sometimes, CPU utilization/Memory utilization exceeds and the application just hangs or gets into HeapSpace or OutOfMemory error.
2. Sizing. Maintaining the number of pods at scale.

I've used this solution since 2013. Over almost four years, the product has evolved from a basic PaaS to a full-fledged PaaS and Private Cloud solution (with OpenShift 3)

Yes, as specified in areas for improvement answer.

It's good. Community support is also good. Easy to deal with.

Yes, we used IBM SoftLayer and we were not happy with it. Another solution that we are using is AWS, and we are pretty happy with it.

The initial setup was straightforward; not complex.

Pricing is good in comparison with AWS. The enterprise pricing is also competitive and is specifically fine-tuned to the type of environments we have.

IBM SoftLayer.

It's a solid solution if you are looking for a perfect enterprise-level PaaS. AWS is a better solution if you are looking for IaaS.

The CI and CD are fast, easy, and secure. Customers need this product and Red Hat certifies it on the RH product. The container customization with S2I is problematic.

In a couple of months, we can move from physical infrastructure to a container. There is no need to worry about service, since Red Hat does it for us. Consequently, we can focus on development.

I think that container development needs to be improved. The source 2 image is very comfortable, but it is not documented. There are no precise guidelines from RH. The source 2 image is the biggest addition that Red Hat gives to Kubernetes, but you cannot depend on Red Hat for every customization.

I have used this solution for 1 year.

The product is stable, but it must be well designed.

I have not encountered any big issues with scalability, but the application must be designed for scalability.

In Europe, support is not as fast as it needs to be. If you follow Red Hat's guidelines when designing the architecture, it has a very difficult blocking situation (you must be skilled on the OpenShift product before putting it into production...as usual!).

I prefer Kubernetes. But customers need very good support from developers, which Kubernetes do not have.

The initial setup was not straightforward. You must understand every single component. Only then is everything clear and goes fast. Teaching developers how to implement the application with new methodology is problematic.

I think OpenShift PREMIERE costs a lot more, compared to the support given in Europe. If you buy directly from the service on the cloud, the level of support is not the same.

In order to understand OpenShift, you must try Docker. Afterwards, you must understand orchestrators like Kubernetes (the OpenShift underground) and Swarm. You must work with developers. I also implemented Jenkies and Nexus in order to attain full, real automation.

It is a very good product. But before implementing it, verify that the product matches your expectations. Remember that the product changes very quickly, so read news as often as you can! This is not the only solution, so be ready to work with it. But this solution was selected by Red Hat.