I give the solution a nine out of ten.

Depending on how we deploy OpenStack it can be difficult to work with. If we have deployed OpenStack for a couple of years, we have to choose a different type of automation. If we're fully integrated, we have a lot of requirements to map making it hard to change everything to match the OpenShift standards, so we deploy in a user-based install.

We have written down a lot of knowledge about how to run a container platform. Depending on how many clusters and how many teams we have involved in the cluster, we manage 11 OpenShift clusters with people. That's only possible when we completely automate. If we do everything by hand, we require a lot of people. If we don't automate the complete infrastructure in OpenShift, we require 11 people, one person per cluster. Currently, we run  11 clusters with four people.

If you're starting a company and don't have a lot of knowledge in the industry, I would recommend using OpenShift. It will make your life much easier, as Red Hat is a big supporter of the platform and is willing to help build our infrastructure and applications.

You need to follow the prerequisites for the environment and then proceed with the installation. There are different ways to do the deployment but you should do it the way that is most comfortable for you.

You can also deploy OpenShift using Ansible. If you want to automate the entire process of your OpenShift installation, including the server, network, and storage, you can opt for Ansible. That way, you will have end-to-end automation for your entire stack as well as OpenShift. That is good flexibility.

The biggest lesson I have learned from using OpenShift is that you can go with bare metal and you don't need to pay extra for the VMware Hypervisor. In terms of installation or manageability, it's simple. You just need to follow some guidelines and you will be good.

I give the solution an eight out of ten.

Red Hat as a partner helps create the platform we need but we pay for the support as part of the licensing, which is super expensive. Once we have the right technical person and solution architects, we have everything required to be successful.

I'm very passionate about Kubernetes and spend a lot of my spare time contributing to the project. It's something that I find very natural, but for regular developers or administrators, it can be quite new. There's a lot of education necessary for people to understand what Kubernetes is and how it will revolutionize their work. One thing I've learned is that we can never document or spend enough time training the end users. End users include administrators and developers.

My company uses OpenShift currently, but it's still under RFP.

OpenShift is deployed on-premises on a disconnected cluster for a financial institution.

Some maintenance is required for OpenShift. Whenever there's a bug, my team does the maintenance, but there's still a need to check with RedHat support on how to fix the bug. My team can't do the maintenance without support from RedHat developers.

Less than ten people use OpenShift within the company.

I would recommend OpenShift to others because it's a good tool for the financial sector versus public clouds such as AWS and Azure. I'd also advice others that if it's a public cloud, it's easy to manage, but if it's on-premise, then it can't be managed.

My rating for OpenShift is seven out of ten.

My company is a customer of OpenShift.

It is an excellent product. There are a lot of items that will be good to have in there, but based on the comparison with others and based on the kind of use cases I have seen, I would rate it a 10 out of 10.

I’d rate the solution eight out of ten.

It's both very easy to start and learn and to improve yourself to manage Kubernetes environments. It’s very portable. You can easily switch from this product to another if you want. It's not like that with other products. For example, if you have an Azure solution, it's not that easy to port everything over.

I would recommend OpenShift to others because of its stability and usability. We have been promoting it to multiple clients inside our organization.

We use Red Hat Linux and Ansible. Red Hat Linux and OpenShift have good integration and support. We haven't used Ansible much. We have only used Terraform with OpenShift. Ansible is good. It has good integration with OpenShift, but we haven't used it much. 

Red Hat is good at creating technologies. They consistently improvise their products. There is a massive difference in handling and performance between OpenShift version 3.x and version 4.x. In terms of stability, they have shown enormous improvements. So they're good at improving their products.

OpenShift provides the flexibility and efficiency of cloud-native stacks while enabling us to meet regulatory constraints, but our implementation at this level is basic. We haven't implemented any strict rules or compliance setup.

I would rate it an eight out of ten.

I rate the solution a nine out of ten. 

We did not use the solution's automation for development; everything before building and deploying an image on an OpenShift project is done on another program or system, with no interaction. We do the verification and security aspects of the build artifact in OpenShift, but we don't use it to build and run the package, etc.

Red Hat could have been a better partner for helping us create the platform we need, as they weren't particularly helpful or reactive with concern to our specific requirements. They didn't step up as a partner but as more of a vendor; they provided the product in a commercial sense but not with a partnership mindset.

We use another Red Hat product, the Ansible Automation Platform. 

We didn't integrate Ansible and OpenShift, but we once had to connect them, which wasn't straightforward. 

Those considering implementing the solution should go to learn.openshift.com, where they can play around and see if they like the product. The hosted version of OpenShift is better than the dedicated one, as you don't have to manage your own node, deployment, or infrastructure. So, for those who can afford it, I recommend the instance hosted on the Red Hat system.

You have to understand what you're getting into and you have to be committed to upgrading it. There are some people in the world who say they'll never want to upgrade it again. With Kubernetes, if you're going to get into OpenShift, you have to "sign the bottom line," so to speak, that says, "I'm going to update it," because the Kubernetes world moves at a fast pace.

In terms of container orchestration, we are totally OpenShift, but we use other Red Hat products like Linux and Tower. We do have standalone Linux machines that we manage, but we'll be migrating some of the applications from those standalone machines into the OpenShift container world. That's where the cost savings are.

Overall, I would rate it seven out of ten.

Red Hat is quite okay as a partner for helping us create the platform that we need. They do help you. They also provide training.

We use Red Hat AMQ streams and 3scale, and its integration with other Red Hat solutions is okay. The advantage of using multiple products from the same vendor is that you can get help from one company. You don't have to go to multiple companies.

It gives me the security that I need, but I didn't evaluate the security much. There is another department that's responsible for that.

I would recommend this solution to others, and overall, I would rate it an eight out of ten.

It's important to build a team around this. So, invest in getting the correct training. There are a lot of options that Red Hat provides. Start small, scale up gradually, and involve people from different areas. In addition to the infrastructure team, also involve someone from development and the architecture team to be able to see its value from different perspectives.

I would rate it a nine out of ten. I'm very happy with the interface, security, and support.

Anyone looking to implement OpenShift in their organization should start with the most minimal setup for configuration. There is an OpenShift version with just the single master with a built-in worker. You will only need a single CPU and you can start with at least three masters and a single worker and scale from there as the need arises, whether it is to add additional worker nodes or as your app grows.

There is no product that compares to OpenShift. I would rate it a 10 out of 10 overall.

I carried out OpenShift's integration process for two or three firms as a part of the team, so it was not done by myself alone. I did carry out the integration process for AWS. Comparing OpenShift with AWS, I found the former to be much easier.

I rate the overall product an eight out of ten.

If any organization is just working on open-source technologies and wants to have enterprise support and enterprise-grade solutions, then we must go with OpenShift.

Overall, I rate the solution a nine out of ten.

I would rate the solution an eight out of ten. The tool requires knowledgeable people to manage it. 

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. 

I rate OpenShift an eight out of ten.

Go for this solution.

Red Hat does a good job of ensuring that their solutions are operable and you can take advantage of the features within a solution.

We also had Red Hat Ansible for automating server provisioning and some operational tasks.

We didn't get any security breaches from Red Hat OpenShift.

I would rate OpenShift as eight out of 10.

I rate OpenShift eight out of 10. Red Hart is a good partner for the most part. Like anything, it depends on who you work with. Some people will regurgitate the documentation, while others will bring their experiences from other locations.

I would recommend that organizations pay a lot of attention to the initial design and setup of the solution to ensure that it is optimized for their needs, as it isn't easy to make changes once this is complete.

I would rate this solution an eight out of ten.

I rate OpenShift a nine out of ten. It is a wonderful product. I advise others to choose the environment size properly. You can deploy it on a public cloud and not necessarily on-premises. You can decide depending on the workload and data localization requirements.

I would rate this solution a ten out of ten because this solution has been able to adapt to our needs as we continue to innovate. 

We're a customer and end-user. 

I do not use the solution on the vendor's open stack platform.

It's a good idea to explore the solution first before really jumping in. Also, companies need to understand the costing and the SSL before jumping into a deployment. 

I'd rate OpenShift at a nine out of ten. 

I rate the solution an eight out of ten. Regarding advice, I would suggest working on your application to migrate it. For example, if you go with OpenShift, you need to convert your application virtual machine to the container version. I would also recommend networking inside the load balancer and the routing capability.

The CodeReady Workspaces should help reduce time to market if I use the CICD pipelines. That's what we aim for, and that's what the container platform is built for. That's something that goes without saying.

We're using Red Hat Linux across the bank for servers. We will use quite a number of Red Hat products during our core banking deployment, including AMQ, Process Automation Manager, and a couple of other products that are bundled with OCP.

The integration is something that is out of the stack. It's more of a middleware conversation and the middleware for us is an IPaaS. It's less about the stack and more about the application. I don't think there are any issues communicating via APIs. And the access management is pretty adequate. I can plug in any IM or document archival solutions. It's pretty easy to integrate.

Red Hat, as a vendor, has shared ample information with us to help us make decisions. That is where a partner comes into play and we're pretty happy with Red Hat.

I give the solution a nine out of ten.

We currently have 100 people using the solution made up of architects, developers, DevOps teams, and testing engineers.

Maintenance is required every two months to restart the ports that get hung up. The solution requires between two and five people for maintenance.

We have built our own container platform. We have lots of products deployed on OpenShift. And there are lots of namespaces all deployed on the same OpenShift control platform. Everything is running fine.

OpenShift is a very stable solution with a lot of support features. I recommend the solution.

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.

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.

I would rate this solution a ten out of ten. 

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

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.

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.

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/

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.

Developers maturity is a key point.

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

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.

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. 

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.

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.

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

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.

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.