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 already were having that microservices architecture, so there was not much change from that perspective. We had small services, so here we had to create multiple pod IDs. Even today, we are using a hybrid microservices architecture. Our DB still has two or three services that hit the same database. From that perspective, there was not much change that we did in our case.

We have certain applications on-prem on physical servers. We had some on Windows and some on Linux. There we had requirements where every time we had to manage extra load, we had to spawn a new Tomcat node. Scaling was one of the issues we were facing, and every time we had to scale up, it was a challenge. Plus, we had to procure infrastructure and do a lot of configuration and setup for the new instance being launched.

Once we set that up, scaling down was a challenge as we did not always bring that down when not needed. When we did not have too much traffic, we still had a lot of infrastructure lying idle. At the same time, when we had high load, we were not able to scale up quickly.

There was too much patching that happened, and every time we had to patch something it became a challenge. There were versioning issues with operating systems versus Java and other technologies we were using. That is why we moved to containerization, where we defined what operating system we need, what Java version we need, and what steps we want to do. Containerization helped us create that one unit we wanted to deploy. Red Hat OpenShift helped us with managing scaling up and scaling down.

Because it was centrally managed in our company, many metrics that we had to write code for were available out of the box, including utilization, CPU utilization, memory, and similar metrics. We performed multiple transformations from physical servers to Red Hat OpenShift, and some from virtual servers to Red Hat OpenShift.

The OC utility tool is something we use very often for replication, replica sets, and config maps for managing all environments and secrets. This is very useful for us. Routing is another beneficial feature we get, so we do not need to manage or do too many things for load balancing.

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.