Red Hat OpenShift Reviews

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.

The pod solution and the on-demand solution are well suited, although I have feelings of loss regarding not using VMware.

It is promising though. The project we are on is large scale so further information would be far more pertinent when fully deployed I think.

Right now the major point is cost effectiveness. The improvements I am expecting will be better presented when in full production.

For some reason there have been some DNS issues. At this time I am not convinced it is OpenShift though. I will have to circle back to this one.

We have just bought the solution and started using it recently.

There have been some DNS issues.

We did not yet encounter any issues with scalability but I am looking forward to our first "go day."

This isn't really an issue. I haven't really called upon support yet. Red Hat reps have been really quick to respond on other issues though.

We were using VMware which is more expensive for no good reason. Thank you OpenShift.

Linux in general is a different flavor. Nothing out of the unexpected. Though, as in all things, there is room for improvement. One solid BIN would be nice.

In the installation of ORIGIN, using the playbook and Ansible install in the Docker, there are fixed points which would make the install easier.

Save money and get OpenShift. Literally.

We evaluated VMware, but then I am biased. I will always choose Red Hat as I know all too well what it does as opposed to other solutions. I am not knocking other solutions, but Red Hat wins in the long run.

Do your homework. Take the time to analyze what you really want and need. I am not saying this is the absolute answer to all your questions as that would be unreasonable and naive. I personally believe that at least 75% of cases probably should be directed at Red Hat in general.

The ability to persist data, the security model, the web console, the installation - all of those features make using the product easier.

We develop software for customers that runs on OpenShift, so developing on a standard product like OpenShift supports our customers' need for cloud based container solutions.

The security model is hard to understand and use. Debugging errors can be hard as well.

We have been using the solution for two years.

The product seems to be mature enough to use for production application deployments without stability issues.

The product is able to meet most scalability goals.

The technical support is generally good and there are ample materials available on the web to help find answers to issues.

We have not switched from another product. We also support other cloud offerings like Kubernetes.

The installation is better now than early on and can be complicated to set up if you are not familiar with Red Hat Linux and Docker.

For trials and prototypes, the open source version of OpenShift will suffice for most users and is compatible with the licensed version of OpenShift.

We evaluated Cloud Foundry but decided upon a Docker container based platform like OpenShift.

Start small, try the open source OpenShift Origin first, then develop a sample application to get accustomed to the platform.

Application deployment using YAML with Docker containers, creating services and providing routes. It is simple to build configurations and deploy your changes and promote them to different environments.

We are better able to manage application development and promoting from development to staging to production using configurations.

They could provide a template for application deployment and building services and routes so it can all be promoted as a bundle if needed.

This would allow the promotion of the application (which includes the Spring Boot jar, the Kubernetes Service, the Kubernetes Route, dependencies such as properties or secrets) from development through the production environment.

We have been using the solution for four years.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

I did not use the technical support but I do look up plenty of resources on the OpenShift blog which is useful.

We were using individual Tomcat on VMS for a high availability and scalable architecture.

The setup is straightforward if you understand concepts from a Kubernetes cluster development. I have done CoreOS cluster development so I am familiar with much of the setup.

I would try the online public OpenShift instance first and see if it is something that would provide benefit to each enterprise architecture and then go on from there.

We have found RedHat OpenShift to provide the best solution and ease of use.

Try out OpenShift or read up on it first to see the benefits. Also build a Kubernetes cluster yourself to know what goes on under the hood in OpenShift.

Great GUI and CLI tools allowing developers to deploy, test and delete projects on demand, freeing up time for the operations team to work on production readiness.

Thanks to Docker images and Kubernetes templates, deployments are reproducible. Docker images allow us to package our applications with their configuration files and libraries in a portable format.

Images are built once by the CI/CD pipeline and archived in a repository. CI/CD integration is made easier with built-in Jenkins servers and S2i functionalities.
We can then run these images everywhere, from developer workstations to development, QA and production environments.

OpenShift (in fact Kubernetes) templates are JSON files that list all components of a project: docker image name and version, runtime configuration of the images, services, routes and storage options.

As long as you have proper versioning of all images and the associated template, you can deploy the same project everywhere.

The following issues need some attention:

• Documentation: this is a very complex product and several areas are lacking proper documentation.
• Templates: it takes a lot of effort to write satisfying templates for projects. More real-world examples and specialized editors would be valuable.
• Day 2 tasks: how do I make sure my cluster works in the long term? This includes all tasks that go beyond the installation, i.e. what you’re facing the day after the installation.

I would personally give a list of topics to the OpenShift administrator for reference after the initial installation has been performed, such as:

• What should you monitor?
• What to backup and how often?
• What should you look for when a node seems slow?
• How to clean up Docker caches on various components?

I would even go further and give a maintenance schedule, as with a car (this is just an example) such as:

• Every week: watch for errors in the logs, check disk space on nodes.
• Every month: check for critical updates on nodes, delete unused projects.
• Every second month: update OpenShift version.

We have been using the solution since January 2016.

We had stability issues, especially with earlier versions where the underlying Kubernetes wasn't stable at all.

Today we still have issues with Docker, which has known bugs not being backported to Red Hat supported versions.

We had an issue with the default nodes configuration. Once we gave enough resources to it, it's been fine.

Red Hat technical support is top notch: quick to answer and really caring about issues being solved

However, some fixes may take a long time when they require modifications in Kubernetes for example, as we have to wait for fixes to be released in Kubernetes, then imported into OpenShift.

We did not use a previous solution.

The initial setup was very complex, but that's because we were deploying v3.1 which was only the second release.

Now the Ansible installer is much more robust and offers more options to customize the deployments.

Installation documentation has also improved a lot.

I suggest they take licenses for physical nodes with two sockets and as many cores and as much RAM as possible.

Then use a virtualization solution to create as many Kubernetes virtual nodes, knowing that it doesn't make sense to allocate too much RAM to each node since one should not run more than approximately 80 pods per node.

RHEL licenses are included.

We took a look at: OpenStack, Cloud Foundry, Mesosphere and Swarm.

Take it for a spin with Minishift: https://www.openshift.org/mini...

Use the free version of OpenShift called Origin for the development environment to save on licensing: https://www.openshift.org/

Use the paid OCP version for QA and production environments to get technical support: https://www.openshift.com/cont...

Do not implement your own CI/CD flow, instead rely on OpenShift integrated CI/CD or use something like https://fabric8.io/

OpenShift works as a data pipeline management tool.

There are challenges related to additional security layers, connectivity compliance for endpoints, and integration. Additionally, it needs a little training to understand the process.

It is a highly stable product. I rate the stability a ten out of ten.

We have deployed OpenShift on the cloud. It is a one-time setup and can take longer to deploy. Once implemented, the rest of the deployment becomes easier. I rate the process a six out of ten.

The product has reasonable pricing. It is an affordable solution but needs a learning effort to understand industrial-grade security.

OpenShift facilitates DevOps practices and improves CI/CD workflows in terms of stability compared to Jenkins. We receive new versions of the plugin in timely intervals. If we do not upgrade the plugins, it introduces some security vulnerabilities at a corporate level.

I advise others to go for the product as it offers high security and reliability. I rate it an eight out of ten.

I use the solution for deployments with Java applications in the environment.

The solution has helped us in faster deployments of the applications.

The solution's most valuable feature is its ability to integrate with multiple applications, including inference tutor and container platforms. It helps us enhance the deployment process and make it faster.

The solution encounters lengthier downtime issues for virtual upgrades. In this case, we have to opt for alternative upgrade strategies. This area needs improvement. Also, they should release its serverless version.

I have been using the solution since 2018.

The solution is very stable.

The solution is easy to scale. Our organization plans to increase its usage for the next five years.

The solution's technical support is excellent.

The solution is easy to configure and run.

The solution generates a return on investment.

The solution is expensive but cost-effective.

The solution is an excellent platform with a fast return on investment. I rate it a ten out of ten.