Red Hat OpenShift Reviews

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.

The OpenShift environment will be used by medical applications. This environment is still in the development/QA phase.

Not yet.

The scaling and uptime of the applications.

Needs work on volume handling (although this is already better with GlusterFS). Security (SSSD) would also be an improvement.

Not at this moment (still running in dev/QA phase).

Not at this moment (still running in dev/QA phase).

Five stars out of five, all issues were solved in an acceptable timeframe.

This was my first installation. It was not straightforward due to internal limitations, not the product.

I rate it a six out of 10. There are still some issues with it. I have several cases at Red Hat that need to be resolved.

Do a test to try the solution.

Migrate to microservices.

Has helped us with faster deployment time, zero downtime.

• Scaling
• Fast deployment
• Zero downtime when releasing a new version
• Auto-recreate pod if pod fails
• Fast rollback, with one click, to previous version

It could use auto-scaling based on criteria such as transaction volume, queue backlog, etc. Currently, it is limited to CPU and memory. 

Credential not hidden, so people on the same group can view it.