OpenShift Reviews

We have deployed OpenShift on-premises on VMware and Azure, but not the managed platform. We manage the deployment ourselves, doing our own customizations.

When we look at traditional web development applications, we'll find that the typical release cycle is one and a half to two months. However, given that customers are now deploying new versions of their applications multiple times a day, OpenShift has improved the way our organization develops, tests, and deploys applications. OpenShift stimulates innovation.

OpenShift provides us with the flexibility and efficiency of cloud-native stacks while enabling us to meet regulatory constraints. No matter where we run our container clouds, as long as we use the right tooling such as Knative, we can run our applications everywhere. Red Hat's nicest feature is that it enables us to develop cloud native applications and put them anywhere. We don't have to run our application on OpenShift. We can also run it in a public cloud like AWS or Azure. We can develop on our primary platform (OpenShift) and build with the right tooling in Knative, using MQ streams, and Kafka, allowing us to connect it everywhere.

OpenShift's automated processes have reduced our development time and increased the quality of our end product. OpenShift has come a long way since its early days. While there were some bumps along the way, the last few years have seen major releases with few, if any, significant bugs. Today, OpenShift is a reliable platform that is easy to use. People act differently when they're listening to the community. If we have a feature request, the vendor works with us to make it happen. I've added multiple requests, especially web UI interfaces, and the team has been very helpful. If we have a feature we require and we work with the vendor, we can have it solved within three months.

Depending on the environment CodeReady Workspaces can reduce project onboarding time. If we have to start over from scratch, CodeReady Workspace can help us set up our development environments quickly. But if we have a running organization with development teams already in place, it can be more difficult to give them CodeReady Workspace and have them start developing in that way.

When CodeReady Workspaces are used we can bring up a complete OpenShift cluster in under two and a half hours. We have already automated the process.  We can launch on OpenShift in less than two and a half hours, completely reconfigured. Using CodeReady Workspaces is definitely worth it if we only have to configure it once. We can have a complete working stack for more than 30 or 40 developers up and running in less than four hours. If we have to do it in the traditional way, it will take 1600 hours. That's 40 hours per application. In CodeReady Workspaces, it takes one click to add a new user and we're done because we have a standard environment.

CodeReady Workspaces helps reduce time to market because our developers can test their applications quickly and easily by developing them directly for Kubernetes or OpenShift.

With CodeReady Workspaces a developer can run the test continuously and start the container test, drop the container, and repeat, saving around 75 percent of the time compared to the traditional way of testing.

I'm a rapid accelerator. I have a lot of contacts in the Netherlands, the USA, and England. It doesn't matter where I am, I can get help from my contacts at Red Hat. As a premium partner, we have sessions every other week to share ideas and knowledge. We are constantly updated about the latest changes that are going to happen in the near future. Our relationship with Red Hat is very good.

We work with Ansible, Satellite, and RHEL itself. We have co-workers and developers who are helping us with the entire Red Hat suite. The integration between the Red Hat solutions is very good. Many integrations are moving to OpenShift. If we look at OpenShift Fuse, it's a Middleware product of Red Hat. It's been running on virtual machines for the last few years. But they are moving to OpenShift. Directing services for maintaining user accounts is a critical part of the integration. The software will run on OpenShift, but not on virtual machines. There are still many integration possibilities. Red Hat develops OpenShift on top of Kubernetes, but also maintains its own applications there, Lenox and Middleware. So, Red Hat will keep it integrated.

OpenShift offers more stability than Kubernetes. With OpenShift, we get a complete ecosystem around the developer, which includes extras that aren't available with Kubernetes. If we build in a Kubernetes environment ourselves, we have to do a lot of work to get it on the same level as OpenShift. One of the nicest parts of OpenShift is the UI, which allows developers to log on and start building their applications very quickly. The integrations are essential to OpenShift, including pipelining and service mesh.

By default, OpenShift is very secure. Out of the box, our role access is in place. We can easily connect to our active directory or our open ID providers. The constraints in the platform are also secure by default. OpenShift is one of the most secure solutions out of the box.

OpenShift's security features for writing business-critical applications are okay. In addition to OpenShift, we use advanced security calls to help developers and application teams keep their applications and projects secure. This depends on a lot of factors, such as the type of application. We work to keep our deployments and applications secure on container versions and solutions, as well as within our applications. We help customers set up their baselines. We recommend not running the applications on the root and staying as close to Kubernetes or OpenShift as possible. This is all we need to do in order to be successful with baselines.

OpenShift has made a lot of strides in the last few months including moving the dashboards to an OpenShift UI making it much easier for a developer to track applications and they no longer need an extra portal to show the metrics or log off their applications.

There are many advantages of using multiple Red Hat products together starting with the integration. We have a one-stop shop for support and we can bundle the products for a huge discount.

The operators need a lot of improvement, with better integrations. 

What we see now is a move from traditional DevOps to GitOps. We use Argo CD for that, which provides a little more integration. It would be nice to have the same UI experience in the OpenShift console without having to log in on a third console.

I have been using OpenShift for seven years.

OpenShift is very stable. I have 11 OpenShift clusters up and running for one customer, and the only issue I've had is with VMware. It's not with OpenShift itself, but with the layer underneath OpenShift.

The solution is scalable. If our bid is high, OpenShift will work right out of the box. For example, if my work is at about 80% capacity, OpenShift can automatically scale a new worker. We can scale down our infrastructure also if needed.

The standard technical support is not great and I would give it a six out of ten. However, with the premium subscription, we get 24/7 support. I usually give support eight out of ten when I need help. This still leaves room for improvement, as almost every issue I have is a P1, which is the highest severity.

Positive

I work with all the Kubernetes platforms depending on the project. I might use OpenShift, Rancher, or even Q&E depending on the needs of the project. 

The initial setup is straightforward, if we follow the documentation and we download the OpenShift install, we can have a very small cluster up and running in less than an hour. However, we will have to do all the day two tasks ourselves. If we run an enterprise, we have a lot of complications. We need to have proxies, separate our infrastructure stack into different nodes, and move storage to storage nodes. This adds a lot of extra work.

The IPI will take about 45 minutes. The second part, if completely automated, will take about two and a half hours.

The first thing we need to know is that Kubernetes is free. However, if we need to maintain a Kubernetes environment, we need 10 people to build, maintain and keep Kubernetes secure and bring it to the same level as OpenShift. Then we have to pay evenly as subscriptions for OpenShift. It's important to start small because the solution is scalable. We can build our cluster and look at the bundle option, not the external subscriptions. Talking to the people at Red Hat can save us money.

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.

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.

Usually, we use it as a test environment and to quickly develop the proof of concept for various projects. So, it's mainly for quick deployment and testing.

It's deployed on the cloud and on-premises.

The biggest benefit is the speed. When developing a new PoC, if we don't have a container-based environment, we would have to set up virtual machines. We would have to install different software to make sure that there are secure ways to do that, which would most likely need a couple of days, whereas, with a container-based platform, such as Kubernetes or OpenShift, we can do that in a matter of minutes or hours.

The security throughout the stack and the software supply chain is very good. It's a step-by-step procedure to obtain new software. It's very secure. We cannot have access without a safe, provisioned way. For troubleshooting a fault, I like the new oc debug feature where you spin up a new pod for debugging. You can spin up a new test pod for a complete copy of the problematic one. We are very happy with it security-wise. I would rate it a nine out of ten in terms of security features for running business-critical applications. That's only because I never give a ten.

It provides us with the flexibility and efficiency of cloud-native stacks while enabling us to meet regulatory constraints. We can automate these checks. For example, in the hybrid cloud model, we can check for different things, such as the accessibility of many different classes not only in the cloud but also on-premises. We can use the hybrid view to check many things very quickly. If someone comes into the company from a regulatory body whose job is to run a couple of scripts and check if certain rules apply to all servers, without having this kind of interface, we would have to give him a week to be able to connect to everything and check everything one by one, and of course, we would have to pay him for that. With OpenShift, from one panel, we can automatically run a script across several different servers or even connect manually to each of them, which is a big benefit. It saves a lot of time and money.

It can speed up the development time. There's only Jenkins, but I'm not so sure about that. Because the development and testing phases are sped up, the time to market can also be very good. However, it also depends on other factors, such as any back-and-forth changes, because we can have a lot of feedback. Overall, there is about a 10% improvement in the time to market.

The CodeReady Workspaces reduce project onboarding time. There is about a 20% reduction.

Its security is most valuable. It's by default secure, which is very important.

It's very easy to manage deployment across different environments. It doesn't matter if it's a private or a hybrid cloud. It's very well-suited for the type of work that we do, which is the deployment for our PoCs. It's very easy to start with small ideas and then gradually scale up. 

It's very easy to integrate with different systems and products, which is another plus point. 

It also has a very nice user interface. It's very self-explanatory, and that saves a lot of time from training new users. You can cut a lot of time to quickly familiarize yourself with the base.

OperatorHub is another big plus. It's very easy to use and very useful.

One thing that can be improved but is surely difficult to improve is the cost. We have a lot of customers who would prefer a Vanilla Kubernetes solution or another solution that combines Kubernetes with some cloud provider, especially if they are already using a specific cloud provider. When we try to work with them, some customers complain about it.

Another thing is that the installation and setup process is a little bit complex, but I must admit that it has improved a lot as compared to the older version. 

Autoscaling is a very unique feature, but it could be useful to have more options based on traffic statistics, for example, via Prometheus. So, there should be more ready solutions to autoscale based on specific applications.

I've been using this solution for about one and a half years.

It's a very stable solution. Usually, problems occur when there's an application error or someone does something wrong and there is a human factor. For example, once there was an application creating a lot of automatic snapshots. There were volumes of snapshots, which couldn't be deleted easily. So, occasionally, there may be some bugs, but generally, it's very stable.

Scalability is a big plus. There is scalability from nodes to machines and so on. However, I would prefer more options on scalability based on statistics. That would be very interesting and very nice to see in the future.

Currently, we have less than 100 users who use this solution. They are mostly developers. There are also some end-users, assessors, architects, administrators, and project managers. The end-user experience is quite self-explanatory, and it's very important.

Once I'm able to talk to a technician, the support is very good. They are very knowledgeable and polite. I'm very impressed, and I've only good things to say about their technical support even though there's a lot of bureaucracy until you reach the right department, which can take some time, but I understand that. All big organizations have a bit of a challenge. I would rate them an eight out of ten.

As a partner for helping us create the platform that we need, I would rate Red Hat a nine out of ten. They're helpful. Whenever I'm in contact with the technical team, they're knowledgeable and helpful.

Positive

I'm not sure because I wasn't involved in the installation. 

We never considered building our own container platform. I've only seen customers using Vanilla Kubernetes because OpenShift is a little bit expensive, and some specific organizations have chosen to invest in a strong team because they would need a strong team to build Vanilla Kubernetes. They are succeeding in maintaining that way of working. I have seen this a couple of times.

I wasn't involved in its initial setup, but I talked to a lot of the people who were involved. Compared to a simple or Vanilla Kubernetes, it requires lots more work and has a lot of default processes constantly running, but, in my opinion, it's something where OpenShift is getting better and better. It's getting quicker. It's going in the right direction.

The deployment took a few days.

I believe there is an ROI for organizations where security is very important, and because of privacy requirements, the public cloud cannot be an option. Especially in the banking sector, there's almost no competition. There is about 15% ROI.

It's expensive. It may be cheaper to invest in building Vanilla Kubernetes, especially if security is not the number one motivation or requirement. Of course, that's difficult, and in some business areas, such as banking, that's not something you can put as a second priority. In other situations, a Vanilla Kubernetes with a sufficiently strong team can be cheaper and almost as effective. In addition, people who are already working with a specific cloud provider tend to find cheaper solutions by combining Kubernetes on the specific cloud and choosing that over OpenShift.

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.

We use the solution to run our own software. Our software is different from the banking system, and it's mostly written in Java with a backend, an Angular frontend, MongoDB, and some caches.

I cannot compare what we had before to OpenShift because it was virtual machine provisioning, and we use OpenShift in the context of a read/write of our internal tech. We don't take an existing application and put it in OpenShift. It's part of the read/write process in Spring Boot. Overall, instead of taking two to three days to request a VM install, deploy, patch, and then put an application on it, we are down to approximately 10 minutes when using OpenShift.

OpenShift provides us with the flexibility and efficiency of cloud-native stacks while enabling us to meet regulatory constraints. We have tools, such as OPA, where we can define security requirements for the deployments for the different channels, and these checks are made during the admission of the pod so we are sure that any workload that goes through this gate complies with our requirements automatically. This guarantees that we do not deploy anything that breaches those requirements. The solution provides proactive security versus reactive.

OpenShift is very beneficial in the development time and our end product because it's easy to request new deployments, we can have different versions of the same software deployed by different developers, and they can iterate quickly without stepping on each other's feet. We save a lot of time because it's easy to create and destroy environments where everybody can work on different features without blocking each other.

OpenShift is based on Kubernetes and we try to use all the Kubernetes objects of OpenShift. We don't use features that are specific to OpenShift, except internal certificates for the services. The one feature that is missing from Kubernetes and that is really useful in OpenShift is the lifecycle of the cluster and the ease of installation. We use VMware and VMware integration internally with the OpenShift installer, which is very good. With OpenShift it's easy to spin up or scale out a cluster.

OpenShift's security throughout the stack and the software supply chain is good.

The defaults in OpenShift are favorable and secure. Red Hat usually takes a lot of time to ensure compliance with the CIS benchmark and by default, it's the most secure out-of-the-box solution for security.

OpenShift's security features for running business-critical applications are suitable.

The solution needs to support the new features in Kubernetes more quickly. For example, there are some Kubernetes features that we rely on that are not yet integrated into OpenShift, even though they have been available for six months. Another aspect that needs improvement is the console and the user interaction with the console itself.

I have used the solution for a total of five years and consecutively for the last two years.

OpenShift is really stable and works solidly as long as we do not make obvious mistakes. Any issues that we have encountered are usually caused by human error or application bugs.

Our clusters currently have between 32 and 36 nodes and we have had no scalability issues with OpenShift.

The technical support is not good. We don't have a technical account manager, which would help, but we're not at the scale to justify paying for one. We go through the regular support line, and usually, it takes one day to go back and forth to pass the first levels of support. They always ask standard troubleshooting questions. It's really painful until we reach the very technical people, but once we do, the support is good. What we don't like is the lead time to reach those people.

Neutral

I previously used Kubernetes from Canonical. Everything in OpenShift is more secure out-of-the-box. If we take a Kubernetes installation like the one from Canonical, everything is open, nothing is secure. We require a security person to look at the cluster and create secure settings. On the other hand, we have all the advantages of having Kubernetes because we get all the new features the day they are out, and Canonical is really responsive to having the newest Kubernetes as soon as it's out. 

The integration with VMware is not nonexistent, but not as good as OpenShift, in how we roll out. I have not used Kubernetes in three years but at that time, everything was done by hand. It lacked an integrated installer, unlike OpenShift.

OpenShift has several advantages over Kubernetes, one of which is the installation process. This process is much better integrated with VMware than Kubernetes, but it is not straightforward. We still need to understand what is required, especially the network layout and the addressing because once we make our selections and deploy, some settings cannot be changed. The solution requires careful planning before deployment otherwise the entire deployment may require scrapping and starting over.

The deployment process takes up to one afternoon but it can take weeks to understand our needs and to get the process right. The same decisions are required in deciding the best size for our cluster, or how to separate our environment, which can be difficult. We may want two active clusters for production, one in each data center, or two clusters in each data center. All of these architectural decisions come with time and experience.

When deploying, I recommend having a platform team of four to eight people who can cover all areas. This team should include one or two people from security, one or two people from infrastructure, one or two people from production who know how to handle alerts, and also some people from development. The platform team should consist of between four to eight people and cover all the customers within the company. Having a team of this size will ensure that all areas are covered, and if someone is unavailable, there is still somebody else to provide backup.

The implementation was completed with the help of a consultant.

We invested a lot of money in our current system, but now it would be more cost-effective to do things differently. We have reached the tipping point and in the future, it will be too expensive to maintain our current system. However, I believe that the money we invested was worth it and we got our money's worth.

I think it is a good idea to start looking at alternatives to Red Hat, perhaps a more open-source solution. This way we can save on licensing costs and have more control over our infrastructure. We get to the point where we can afford to pay skilled people to look at our code instead of paying for a license. OpenShift is really good when we need to start, but once we get to a certain scale, it becomes too expensive. It is more cost-effective to go with a cloud-managed Kubernetes if the organization is already on the cloud.

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.

Our company uses it as a platform as a service. We have business units with developers who deploy their containerized applications in OpenShift. We have a team that supports the infrastructure of clusters all over the world. We run thousands of applications on it.

It's deployed on-prem and in the cloud.

One benefit is that it provides you with the flexibility and efficiency of cloud-native stacks while enabling you to meet regulatory constraints. They have a catalog of the ratings of the base images that we use to build our containers. We reference that to show our security team that an application we're building has passed the security with vulnerabilities that are acceptable. We won't deploy it if something is not unacceptable.

In terms of our organization, the business units are able to deploy changes to the code rapidly. They can test it on the test cluster and, once it's tested, they can deploy an image in seconds. It has saved us time. Our guys are continuing to move to the OpenShift platform from whatever they were on, whether it was a mainframe or a standalone machine. And they're doing that for the cost savings.

In addition, a perfect example of the solution's automated processes and their effect on development time is the source-to-image feature. The developer can use that tool to improve his code's quality and it saves him some time. He doesn't have to understand the specifics of building a container.

There is also an advantage due to the solution's CodeReady Workspaces. That definitely helps reduce project onboarding time. There are prebuilt packages that they use. We have a lot of Java and some .NET and Python and the CodeReady packages help. Conservatively, that feature has reduced onboarding time by 50 percent. It also helps reduce the time to market by about the same amount.

Overall, Red Hat is a handy tool to have, like an electric screwdriver instead of a manual one. We don't have to write things manually. We can use what they've already written to make us more productive.

The developers seem to like the source-to-image feature. That makes it easy for them to deploy an application from code into containers, so they don't have to think about things. They take it straight from their code into a containerized application. If you don't have OpenShift, you have to build the container and then deploy the container to, say, EKS or something like that. It's a little different.

In terms of the solution’s security throughout the stack and the software supply chain, it meets our needs. It's excellent as far as we're concerned. It goes right along with the Kubernetes role-based assets control. OpenShift's security features for running business-critical applications are excellent. A lot of our external-facing applications have been protected. We do use Apigee for a lot of it, but we also do security scans so we don't expose something to a known vulnerability.

The software-defined networking part of it caused us quite a bit of heartburn. We ran into a lot of problems with the difference between on-prem and cloud, where we had to make quite a number of modifications. That heartburn meant millions of dollars for us. That was a year ago and the product has matured since then. They've since resolved it, so it's not really an issue anymore.

The storage part of it was also problematic. There were quite a few things that really hampered us. But it's much better now.

I've been using OpenShift for five years.

It's extremely stable. We haven't had any outages that were caused by the software. There have been issues due to human error on our side, such as not buying enough memory for the host. 

It's also extremely scalable. On our dev cluster, we auto-scale from 50 nodes up to 130 on a weekend, when there is a need. It also scales itself down to save money over the weekend. When people start hitting it on Monday, it scales back up, seamlessly.

In terms of users, we have about 20,000 developers, all over the world. It's used 24 hours a day. We have centralized development clusters that are being used all the time because we have deployments on every continent except Antarctica.

We're moving off mainframes and monolithic apps into the containerized world. Increasing our usage is a stated management decision in our organization. OpenShift has been growing in our company in the last couple of years.

We use the tech support daily and they're pretty good. There are always going to be a few rough spots, but most of the time they're responsive.

You may get one support guy who doesn't understand the solution or the problem and they give a wrong solution, and we all know that it's the wrong solution. The problem is that we have people who have different first languages, so they don't always phrase the question well. I can see where a tech support guy might get a little confused because of the wording of an issue.

Red Hat, as a partner for helping to create the platform we need, has shared code, information, and ideas. They've been very helpful and open. We have a couple of technical account managers who meet with us once a month. One is in the UK and the other is in the US. They're very responsive when it comes to any problems we run into.

Positive

Previously, all we used were standalone Unix machines. We didn't use a different container orchestration, like Mesos. We never considered building our own. We took a look at OpenShift a long time ago and it was really the best at the time.

Version 3 is very complex but it's 1,000 times better than five years ago, and it's even much better than it was a year ago. The deployment was a pain point for our company, but it's irrelevant for someone buying it now. They have fixed a lot of stuff.

We have huge deployments, hundreds of nodes in a cluster. The deployment time is relative to the size of the cluster, but the deployment time has gone from a week to a day for a 100-node cluster. Red Hat has improved the process considerably.

It provides us with good value.

There weren't a whole lot of options. There was Mesos or home-grown or Kubernetes using Rancher. There wasn't anything that really compared to OpenShift at the time. OpenShift was a complete package. There were a lot of things you had to do manually with the other products. The Kubernetes world has changed a lot since then.

The fact that Red Hat was open source was a factor and the security was what we really liked about it. They use CRI-O, which is a secure runtime container, as opposed to using Docker, which is super-insecure running as root. Red Hat is definitely the leader in the container security world.

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.

We use OpenShift as an accelerator for our projects. We provide an environment for containerization. Our company has multiple clients using the infrastructure to build and test their applications.

We've both cloud and on-prem installation of the tool. For the cloud installation, we use the AWS cloud.

The quality of the product is good. There are no performance issues or any tools-related issues. We get excellent performance and application integrity. We use multiple internal applications, and they are integrated with OpenShift. Our end users are happy using the platform, and they are able to test everything using the OpenShift testing environment.

OpenShift provides good security throughout the stack and the software supply chain, and we use it in conjunction with Azure authentication. We haven't had any security breaches or issues with the tool. We don't run any business-critical applications with the product, but it offers good security and prevention. Overall, we're satisfied with it from a security perspective.

The solution is very reliable. We have excellent documentation, and we get good support for open-source products. If we need to learn new features or do new types of implementation, documentation is available. 

In terms of implementation, OpenShift is very user-friendly, which is an advantage. We are using it along with GitLab for implementing CI/CD pipelines. That's a feature that other products also have, but in OpenShift, we find it good.

Upgrades are easy. We could do upgrades with a single click. The GUI is very user-friendly. We are also very comfortable with the CLI.

We want to see better alerting, especially in critical situations requiring immediate intervention. Until we go to the dashboard, it can be challenging to quickly recognize that there's an issue for us to deal with. Therefore, a popup of the event or a tweaked GUI to catch our attention when it's alerting would be a welcome change. Everything else is good. We don't need any additional features. From the operations perspective, as an administrator, there is nothing concerning.

Red Hat has to improve its support. They should provide quicker and better support for issues with lower severity.

We've been using this solution for around two years. 

It's stable. The cluster is pretty stable. With version 3.11, we were having some issues, and it wasn't a pretty stable cluster. We had issues often on the backend nodes, but version 4.x is very good. We have been using it for more than one year. We have had multiple versions such as 4.7, 4.8, and 4.9, and now, we are into 4.10. We upgraded our staging cluster to 4.10, and that upgrade was very smooth. We had some issues, but we were able to fix them.

It's very scalable. We can see the cluster size we need. We can also scale down. So, scalability is good. The MachineSet feature in OpenShift is very good. It's user-friendly, and we can scale up and scale down as per our needs.

We have thousands of projects. So, many users are using this solution. We have around three production clusters and two development clusters. For now, we don't have any plans to expand its usage. Currently, the market is still in a stagnant state, and there is not any plan for expansion. If the number of users increases, we might increase the number of clusters.

The support people who join our calls or take care of the issues are technically strong. There is no doubt about that. They're able to find out the issue, and they give us a quick solution. If there is any bug, they coordinate with their engineering team and provide us a bug fix in the next version or internally to upgrade it. Overall, their technical support is good, but for the lower priority cases, their response is not very satisfactory. If we open a case with severity 3, 4, or 5, we don't see an active response. We get a good response only for severity 2 and 1. I would rate their support an eight out of ten.

Positive

We were using Kubernetes. We switched to OpenShift because we wanted an enterprise-level usage tool. So, we needed a more stable product.

We chose OpenShift mainly because we get good vendor support. In case of any issues, we can easily collaborate with the vendor to get a proper solution. From the operations perspective also, OpenShift is good. That's also the main reason why it's being used here.

For the installation of OpenShift, we used the IPA method of installation in AWS. It's pretty straightforward and easy. It isn't complex, but you have to go through the documentation. You have to read the documentation before implementing it. Overall, the initial setup is good. There isn't any complexity in the installation.

We have a good procedure to implement it. We just followed our internal procedure and the OpenShift document, and we were able to install it.

When we deployed a cluster, it took us about one and a half hours to bring the cluster. It took us around two days to complete the setup. After installing OpenShift, we needed to do some peripheral installations, such as authentication, creation of objects such as resource quota limitations, creation of templates, etc. In a maximum of two days, we were able to bring the cluster back into the required state.

In terms of maintenance, we have five clusters that are being taken care of by four people. My team doesn't only take care of OpenShift. We also take care of GitLab, so that also takes some resources. Overall, four people are taking care of five clusters.

I didn't work on its deployment. For the on-premise installation, my colleagues worked with the vendor to implement it. We got help from the vendor. 

We considered VMware Tanzu. They are still in the pipeline. We are planning to implement VMware Tanzu inside our environment. OpenShift is very good, but we are considering VMware Tanzu because we already have a good VMware environment. We thought of using that VMware environment also for the containerization application. That's the reason for considering VMware Tanzu.

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.

Our service order management platform was cloud-native. We deployed its microservices on Red Hat OpenShift. When we did that, we were able to increase the capacity of order processing from 100,000 a day to at least 400,000 orders daily. That is the incremental capacity that OpenShift gave us.

The company had a product called device financing, where the company worked as a partner with Google. It allowed customers to take mobile phones on loan or via credit. When we migrated those services to OpenShift in February last year, we were able to sell over 100,000 devices in a single day, which was very good.

We deployed some microservices to handle Airtime Advance and Data Advance. This product from the consumer commercial team needed a throughput of around 2,500. They were able to get that from Red Hat OpenShift.

The self-healing of pods is a valuable feature. This feature goes a long way in helping us ensure our uptime for services, improving the performance of the system.

The solution provides us with the flexibility of cloud-native stacks while enabling us to meet regulatory constraints. Since most of our services were deployed on-premises, this allowed us not to get into data privacy issues for services with personally identifiable information belonging to customers. It is microservice-ready from a cloud-native perspective, which is a benefit.

With the automation that OpenShift gives you, you can automate as much as possible. This goes a long way in reducing time to market and errors due to human intervention. So, if an organization can do a lot of automation, e.g., automating deployments, that can go a very long way in reducing the time to market and the time required to fix issues that arise out of deployment.

The whole area around the hybrid cloud could be improved. I would like to deploy a Red Hat OpenShift cluster on-premise and on the cloud, then have Red Hat do the entire hybrid cloud management.

I was using this solution at my previous company. I left that company in October of last year.

We implemented the project mid-2019. We went live just before the pandemic in 2020.

It is very stable.

From some issues in production where some nodes went down, we just needed to improve in monitoring the Red Hat cluster. Then, we could know when there was degraded performance and repair it before it could cause an impact to the customer.

It is able to scale based on load.

The support is amazing. They stick to the SLA, and even go out of their way to research and assist customers to resolve issues. I would rate the support as nine out of 10.

Red Hat is amazing. With the proper leadership in place and proper partnership, you can do a lot more with Red Hat. There is a very active community where they share codes, information, and ideas.

Positive

Initially, we used to run Vanilla Kubernetes, which is open source. Then, we realized we were short on skill sets. Another organization had done a PoC of Red Hat OpenShift, and it passed. So, our organization was gracious enough to allow us to spend money on Red Hat OpenShift licenses. That was in 2019.

With Vanilla Kubernetes, we were not able to successfully implement service mesh. That comes already preconfigured for you with Red Hat OpenShift. 

In terms of traffic routing and firewall management, it was a nightmare managing that in Vanilla Kubernetes. However, with Red Hat OpenShift, you only add specific IPs in firewalls, as opposed to the nightmare that we used to see with Vanilla Kubernetes.

Red Hat's commitment to open source is one of the reasons that we went with it. We knew that we would get continuous updates. Also, the option of keeping our OpenShift cluster up-to-date with new services was a headache that we passed onto Red Hat. 

Initially, the deployment process was complex. However, with repeated use, it made more sense. Deploying TIBCO BusinessWorks Container Edition and optimizing it on Red Hat OpenShift is complex.

We teamed up with Red Hat's OEM to do the Red Hat OpenShift implementation. So, it was a small team. We just did a waterfall implementation, not agile.

We did see ROI.

The solution's CodeReady Workspaces reduced project onboarding time by over 50% and time to market by 70%.

The organization really wanted to go open source for a very long time to reduce its CapEx and OpEx costs.

We had a Red Hat Enterprise Linux (RHEL) license for all our servers' operating systems. By having multiple Red Hat products together, you can negotiate costs and leverage on having a sort of enterprise license agreement to reduce the overall outlay or TCO.

The pricing and licensing for OpenShift is okay.

At the time of our evaluation, our options were only OpenShift and Vanilla Kubernetes. Now, there is also VMware Tanzu, which wasn't as mature a product when we did the PoC in 2019.

I am currently implementing VMware Tanzu in my new role at another company. I have not seen any significant differences between Tanzu and OpenShift.

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.

These are for some of our applications where we wanted high resiliency. In the traditional VM environment, what used to happen is that everything was dependent on the infrastructure. We wanted to move away from that particular concept. Once an application becomes stateless, it should not be dependent upon platform-related things. We wanted it to be more robust and perform at a much better efficiency. We also wanted higher availability.

We are getting everything from OpenShift at this point in time. What we're doing here is pretty much basic. Any of Kubernetes could have done it because all we're looking for is being able to manage the complete cluster.

Its interface is good. The other part is the seamless integration with the stack that I have. Because my stack is mostly of Red Hat, which is running on top of VMware virtualization, I have had no issues with integrating both of these and trying to install them. We had a seamless integration with the other non-Red Hat products as well.

One of the features that I've observed in Tanzu Mission Control is that I can manage multiple Kubernetes environments. For instance, one of my lines of business is using OpenShift OKD; another one wants to use Google Anthos, and somebody else wants to use VMware Tanzu. If I have to manage all these, Tanzu Mission Control is giving me the opportunity to completely manage all of my Kubernetes clusters, whereas, with OpenShift, I can only manage a particular area. I can't manage other Kubernetes clusters. I would like to have the option to manage all Kubernetes clusters with OpenShift.

I would like to have self-service capability. A lot of developers want to become independent today, and they don't want to depend on the Infra teams for managing, provisioning, etc. If we can give a self-service capability, in terms of building a particular Kubernetes cluster end-to-end, to developers, that would be a plus. That's the ask of the hour.

I have been using this solution for the past one and a half years.

It is a perfectly stable product. If an application is ready to be containerized, it is seamless. You will not have any hiccups.

Scaling up and down is happening, but my concern is that if we hit any kind of bugs, the open-source community won't be that active in terms of doing the bug fixes. If I get any bug, there might be a delay in getting the bug release or the patch coming up. When I'm hosting an enterprise data application on an open-source product, I will have a little higher risk of non-availability, and that might lead to revenue impact as well. Keeping that in mind, I would like to go for the enterprise edition, at least for my high revenue-generating applications.

In terms of the number of people working with this solution, I have about eight administrators. I have eight people in my team who manage the complete Kubernetes cluster for me, which is a combination of OKD and Tanzu. It is being used on a daily basis.

We are using the open-source version, and their community support is good. I don't expect a rapid response from the community, but if I post today, I usually get a response in a few hours. 

We have an enterprise agreement with Red Hat for the other products that we are using. Their response is very prompt.

We also use Tanzu, which has more limitations. If I have to use an F5 load balancer or other third-party products, Tanzu shrinks a little bit. It is not as mature as Red Hat OpenShift, which is more open to other products. I have an F5 load balancer, and I struggle a bit to integrate the F5 load balancer with Tanzu, whereas with OpenShift, it happens directly. For Tanzu, I have to have another layer on my load balancer, which is Avi. I have to use their services. Adding one more product into the environment brings some complexity, whereas OpenShift is very agile in nature. It adapts to all kinds of products that are not part of the same stack. So, I had no issues with that. I would rate OpenShift higher than Tanzu because OpenShift is a much more mature product.

It was straightforward. I had a perfect team with prior experience in OpenShift. They were able to do it without any hiccups. The community of OpenShift is very good. There are a lot of exchanges happening in the community space, which helped us in doing it in a seamless way. I would rate it a 5 out of 5 in terms of the ease of the setup.

We are currently using the open version, OKD. We plan to get the enterprise version in the future.

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.