Red Hat OpenShift Reviews

We use it for container orchestration. Some customers don't need to go with the coordinated open source as they need a more enterprise solution, so we use OpenShift. We mainly use it to host IBM CloudSec. We are working with CloudSec for integration, CloudSec for automation, and as a prerequisite for them, they need an OpenShift.

With OpenShift, it gives me the ability and capability to monitor all my microservices and all my containers using its integrated monitoring. Its horizontal pod scaling is more efficient than the one used in Kubernetes.

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 Dev Spaces can reduce project onboarding time. If we have to start over from scratch, Dev Spaces 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 Dev Spaces and have them start developing in that way.

When Dev Spaces 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 Dev Spaces 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 Dev Spaces, it takes one click to add a new user and we're done because we have a standard environment.

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

With Dev Spaces 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.

I used OpenShift for the enterprise service cost system of a bank. We completed the migration of the bank's core banking system using OpenShift as the infrastructure. OpenShift acts as an orchestration platform and is used as our private cloud.

OpenShift is a spin-off of Kubernetes, built on top of Kubernetes. It has features that enhance security, ease of deployment, and service exposure compared to Kubernetes. It also provides good integration with GitOps and ArgoCD. 

Additionally, OpenShift offers an easy-to-use graphical user interface for cluster management, making it more accessible for administrators.

We are building an application that is a containerized application, and we are using Red Hat OpenShift for that application.

The concept of containers and scaling on demand is a feature I appreciate the most about Red Hat OpenShift. 

Our solutions can easily scale to any number of users or requests if we are running on the cloud. The cloud also supports the pay-as-you-go model, so scalability is the biggest benefit.

The main goal is the modernization of our applications. We have a few applications running on mainframes, which increase costs. We aim to modernize them on containers and microservices. We are shifting towards Kubernetes or Docker. As an enterprise client, the best solution is Red Hat OpenShift paired with support from Red Hat.

A valuable feature of Red Hat OpenShift is its ability to handle increased loads by automatically adding nodes. This automation impresses us and benefits us in managing loads on applications. 

Although we have just started the transition and are moving slowly, OpenShift has been helpful in modernizing our applications, and it is a positive step forward.

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.

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.

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.