OpenShift Reviews

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 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.

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/

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.

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.

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.

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.

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.