Red Hat OpenShift Reviews

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.

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.

I primarily use the solution for deploying Springboot applications and Engine X among other things. 

In the company, if transactions rise, we can scale up the solution easily. It's flexible and we're able to ensure it meets our needs based on its ability to autoscale. 

The deployment is easy.

The security is good. I'd rate it 4.5 or five out of five. I'm satisfied with the security on offer. 

The product can scale well automatically. 

OpenShift can be deployed on-premises and on the cloud. It helps us comply with regulatory issues that would require at least a portion to be covered by on-prem usage. 

The automated processes are really great. It helps with development time and the end product quality. It helps by being so flexible, which translates into easier development. It helps take some stuff off our plate. 

The solution's code ready workspaces have reduced project onboarding time. It's really simple to deploy on OpenShift. The reduction levels have been around 35%. It also reduces time to market due ot the faster development times. The reduction has been around almost 20% based on some administration we ned to handle in order to maintain compliance.

The flexibility is nice, yet comes with great sacrifice. It's much more complicated in general. We'd like the flexibility on offer to be simplified a bit so that we don't have to do so many workarounds. 

The interface could be simplified a bit more. 

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

The stability of the product is good. There may be a few bugs, however, in general, it works quite well. 

The product is scalable. 

We have 100 or hundred users on the solution right now in our organization. Most are developers. Some are end-users. There might be a handful of admins as well. 

Technical support isn't used really. I've never called them personally. 

We previously used a different solution. We switched to this product since it was more flexible.

We have considered building our own container platform as well since we needed something on-prem. However, OpenShift already provided what we needed, and so it wasn't necessary. 

I'm not sure if we also use any other Red Hat products. 

The initial setup was not done by me. I only work with the solution. 

I don't directly deal with pricing or handle the negotiation on licensing. I can't speak to the exact price. 

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. 

OpenShift is a containerization platform.

OpenShift provides faster container orchestration without the need to know the guts of an already complex system. Kubernetes is complicated for an organization to do correctly on its own, so OpenShift streamlines that process and makes it easier to get up and running.

It allows flexible and efficient cloud-native stacks. You've got a lot of capabilities, such as build packs to automatically access development solutions or different languages like Spring Boot or .NET. Everything is in one place and addresses the developers and administrators.

Two stand-out features are the security model and value-add features that don't exist in Upstream Kubernetes. OpenShift's security throughout the stack and the software supply chain is pretty robust. Including advanced cluster security, OpenShift covers almost everything out of the box.

We are also using Linux Rail and Ansible, and all these Red Hat products have some awareness. However, it's hard to say because some of them previously existed as non-Red Hat products.

One glaring flaw is how OpenShift handles operators. Sometimes operators are forced to go into a particular namespace. When you do that, OpenShift creates an installation plan for everything in that namespace. 

These operators may be completely separate from each other and have nothing to do with each other, but now they are tied at the hip. You can't upgrade one without upgrading all of them. That's a huge mistake and highly problematic. They shouldn't be linked together so that when you upgrade one, you must also upgrade the other. It doesn't make sense if they aren't related as operators.

I have been using OpenShift for three or four years.

OpenShift is mostly stable. It's designed so that you seldom notice if it's unstable. I have no complaints.

OpenShift is scalable. It automatically scales.

I rate OpenShift support seven out of 10. There is room for improvement. We sometimes find the answer before the vendor. You get bounced around to various people and must repeat the issue even though it's all documented.

Neutral

Setting up OpenShift is pretty straightforward, and you can do it in under 30 minutes if you know what to do. We have four admins who maintain it. It requires a lot of maintenance because the underlying platform moves quickly. Kubernetes moves quickly, so new versions are constantly coming out. Keeping current requires lots of maintenance. We do upgrades monthly.

Vendor support is one reason to go with OpenShift. It's an open-source product, but you can pay for support. 

We looked at all the options, including Upstream Kubernetes, AWS, Azure, GCP, and Rancher.

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.

We use the solution for container orchestration and management. 

We have found the cluster management function to be very good with this product. Also, each new version of the product has made upgrading easier and faster to carry out.

We experienced issues around desktop security, which stopped us from implementing a new feature that had been developed. This needs to be improved in order to expand the usage of the product.

We have been working with this solution for around two and a half years.

We have found the solution to be very stable.

We have found the solution to be very scalable during our time using it, and we now have a large number of transactions passing through the product.

The technical support is good, but they have been slow to respond in the past. The issues were resolved effectively, but it took some time for this to happen.

Positive

The initial setup of the solution was hard, and took around three months to deploy completely.

We used a third-party vendor for our implementation, and they were very knowledgeable.

Depending on the extent of the product use, licenses are available for a range of time periods, and are renewable at the end of the period.

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.

We are using OpenShift as a microservice platform.

The most valuable feature of OpenShift is the containers.

OpenShift can improve monitoring. Sometimes there are issues. Additionally, the solution could benefit from protective tools if something was to happen in our network.

In a new release of OpenShift, they should add Kibana, Grafana, and Elasticsearch.

I have been using OpenShift for approximately two years.

OpenShift is stable. However, I feel it could be better but the local implementor is not giving us all the information.

We use OpenShift on a daily basis. We have one engineer for the operation and a pre-engineer for monitoring. Additionally, we have more than five to handle the daily work.

We are using a local vendor for the support. They can handle level one and two support when we have issues.

The initial setup of OpenShift is complex. We have two types we do, but active active does not work, only active passive does.

We used a local vendor to do the implementation and maintenance.

I rate OpenShift an eight out of ten.

OpenShift as a solution is quite broad depending on the industry you are applying it to. For example, telco companies use the entire breadth of applications that the client wants from the web to their middle tier up to the back end. 

OpenShift is a platform for ensuring that your apps are running reliably. 

OpenShift has 100% compatibility with Kubernetes. I find using kubectl, and kubectl commands to be valuable.

The security features of OpenShift are strong when in use of role-based access. The solution is easily compatible with other solutions and the features are easily installed.

OpenShift could be improved if it were more accessible for smaller budgets. I currently mostly use Raspberry Pi, which will be over to use Kubernetes. As a platform, I am using Raspberry Pi rather than using a very large configuration computer. 

The solution requires eight or more cores of CPUs, multiplied over the number of nodes needed to make OpenShift reliable, making it susceptible to failures.

In the future, I would like to see a roadmap to have Wasm supported. If you have WebAssembly as an alternative to Docker, it would be great.

I have been learning how to use OpenShift for years, but actively using it for six months.

The solution is stable. We haven't experienced downtime. 

OpenShift is easy to scale. You just need to make sure you have the capacity to purchase and the number of nodes needed. Scalability only depends on your budget.

Currently, they are more than 10 users of OpenShift in the organization.

Technical support has been efficient, supportive, and communicative. They do not drop the ball. I would rate the customer service and support of OpenShift a five out of five. 

Positive

Previously, I had experience with VMware's Kubernetes version. VMware was very difficult to install. I could not understand the route they were taking and why there were so many steps. 

The initial setup of OpenShift is straightforward if you are an experienced platform engineer. Installing on AWS or Azure could be more complex. The product has a Terraform command to install everything.

If all of the tools that are needed and all the hardware is there, the implementation should be straightforward. I would rate the initial setup a four out of five overall.

Pricing of OpenShift depends on the number of nodes and who is hosting it. OpenShift is more expensive than other solutions, however, I think it is worth it.

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.

We are not using it for our core banking or any critical application. It's just for our remediation services. We have an ITSM tool, which is running on that, et cetera.

The support is very strong in Turkey. We are very happy with its capabilities. The steps are easy in terms of usage.

We need some kind of a multi-cluster management solution from the Red Hat site. With that, we have got some problems; however, right now, we can manage to run the solution without any problems.

The stability has been good. We haven’t had any real issues up to this point. It’s been reliable, and the performance has been good.

The scalability is fine. We haven’t had any problems in that regard.

The main reason that we chose OpenShift rather than Azure or AWS was the scalability. It’s the best one on the market.

We have gotten both local and international support from Red Hat company, so we are covered. We are satisfied with the solution’s support in general.

There isn’t really any initial setup to worry about.

I don’t have any information about the licensing costs or the process.

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.

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.