I'm a DevOps Architect for our on-premises multi-cloud solution. The core business of the company I work for is clearing between all the banks in my country.

We're now in the phase of implementation of major projects for Instant Payments and Open Banking API HUB (PSD2). One of our requirements from solution providers was that the solutions should be "Kubernetes agnostic", so we can deploy the solution on OpenShift, vanilla Kubernetes, etc.

At the same time, for all newly developed in-house applications, we strongly prefer to be able to be deployed on Kubernetes too.

Since we're a small company we need to be efficient and that is why we are implementing automated releases, automatic testing, and CI/CD pipelines using seamless microservices.

When I started using OpenShift, it proved to be a very resilient platform with strengthened security. My responsibility was to build up the whole on-premise private multi-cloud. We designed a practice in GitOps manner so that the source code of all the applications, including the manifests for Kubernetes clusters and the database scripts management, are stored on our private GitHub repository that is used as a single source of truth. At the same time, we realized, that we cannot store sensitive data in GitHub like credentials to other systems, certificates, API keys, etc.

To solve this, we deployed and configured another system place for the secure storage of sensitive data - HashiCorp Vault.

Since we have two data centers, we decided to do multi-cloud deployments in a manner that we don't have one OpenShift cluster stretched across different data centers, but for each data center, we have a separate deployment where both of the OpenShift clusters are connected to the same database and the same external persistent storage. The production databases are not deployed on OpenShift.

We heavily use cloud-native CI/CD pipelines. Practically, there are two cloud-native projects that are supported by RedHat. Tekton is used for Continuous Integration and ArgoCD is used for Continuous Deployment.

Red Hat developed operators for these two tools and we embedded those tools in our day-to-day work. Whenever a developer performs a specific action on GitHub, like Pull Request, separate processes automatically start through the use of webhooks. Then, that source code is built, tested, packaged into a container, pushed to our private docker registry, and deployed to various environments depending on the GitHub branch (dev, test, prod).

We created generic CI/CD pipelines for APIs and databases and by using these pipelines we're speeding up the process of day-to-day deployments, like manually copying files and assigning privileges to various environments. Now, the rest of the staff has more time for more concrete jobs rather than repetitive tasks that are also very prone to errors. We're much more efficient now.

Our developers aren't using CodeReady workspaces and they don't have isolated environments on their laptops, but they do have access to the OpenShift clusters in a very controlled manner since they're directly deploying the solution via these pipelines to the OpenShift platform.

We're currently using version 4.10. I have also used versions 3.10 and 3.11. We are testing deployment on OpenShift 4.12 too where the Kubernetes version is 1.25+ which brought a lot of major improvements.

We primarily work on middleware applications to communicate between front and backend services and use the solution to deploy our platform as a container. Our entire application goes into OpenShift containers.

We initially started with OpenShift 2.0 and 3.0, which were on-prem platform versions. Then we moved on to OCP 4.0, a hybrid platform in the Red Hat cloud.

We don't use the solution on the vendor's OpenStack Platform; we integrate with vendors, but they have their own capabilities and manage their services and infrastructure. We build our services and then deploy them on the OpenShift platform, and if the vendor deployed their services or APIs on a different system, then we integrate with them, but we don't control vendor platforms.

Our use case is primarily to do with DataPower. We wanted to configure DataPower and move away from appliances to a software-based solution, which is CP4I. DataPower is an IBM product, and we were using their firmware machine. We wanted to move from hardware or firmware to software, and CP4I is a software-based solution for DataPower, and that works primarily for any Kubernetes, but IBM had both. So we moved to Kubernetes, and on top of that, we had CP4I.

We did the implementation for one organization. It was widely used, and there was a huge customer base. It was primarily in the telecom domain. Those APIs were used, and we were getting a lot of incoming traffic and outgoing traffic through DataPower.

This solution is deployed on our private cloud.

I work in a bank and we develop new microservices based on mainframe legacy systems. They want to start developing new microservices to reduce the calls to the mainframe. DevOps in Bank Hapoalim uses OpenShift as a platform and all the services are deployed automatically to avoid the problem of services being unavailable. So the main use case is to modernize the existing legacy systems. All the big projects of the bank are going through this modernization, with a new architecture and deploying stuff through microservices.

We are moving as many applications as possible to a containerized environment. In terms of our environment, we have multiple data centers. One, of course, is for redundancy. Most of them are hot-warm. They're not hot-hot or hot-cold, depending on how you look at it, but pretty much everything that's important is fully redundant. That would be between our own private data centers and within Amazon across regions.

We have an on-premises and private cloud deployment. Amazon is the cloud provider. We've got some Azure out there too, but Amazon has been the primary focus.

Our primary use case for this solution is, as an open system, to deploy containers on AWS or other platforms and then manage them.

I am the platform engineer, and the platform serves a function for end users by allowing them to deploy their apps based on their application use cases.

It is used for containers.

Our company deploys the solution as a container platform that balances node availability and load. 

As an IT service provider, we work on enterprise technologies for our customers.

We have multiple customers with multiple domains, but the majority of our experience is in the banking and telecom sectors. In banking, they're using the OpenShift platform for their microservices-based requirements, and similarly on the telecom side, they are using it for the microservices-led solutions.

We started with the on-prem deployment of OpenShift Container Platform, version 3.2. But currently, we are also helping our customers to migrate to 4.x and to cloud solutions. The plan is to move to a cloud version, strictly on AWS. We are exploring the OpenShift Container Platform cluster, and ROSA (Red Hat OpenShift Service on AWS) the latest one with the managed services. By mid-2022, we'll probably be on cloud with this.

The principal use case of the platform is the transition and migration to the cloud. The second one is the modernization of our integration platforms.

I usually help companies design their environments, find workloads efficiencies, suggest best practices, and provide an overview of the environment, which involves consultation and a focused-oriented approach. I also deploy and develop solutions for companies. I do end-to-end deployment for companies.

OpenShift Container Platform is used by companies moving from their old monolithic environment to a microservices-oriented architecture. If a company wants to do a BAU sort of stuff, they already have OpenShift Container Platform, but they need someone to drive it or work on its day-to-day automation while looking at its integration with Ansible or Puppet.

We use the OpenShift Container Platform to deploy applications. It helps to deploy them from a monolithic to a microservices approach. 

We use it mainly for the retail space.

Our client deployed OpenShift on a bare-metal server, and they use it to offer their customers a platform-as-a-service solution with metered billing. It's pay-as-you-go. We are currently developing our own platform. For the most part, we have enough developers, but we'll go to Red Hat when we need support.

We have a monolithic application, and our primary use case is to implement microservices. We needed Kubernetes, but instead of going with plain Kubernetes, we chose OpenShift because it has a well-designed UI, more advanced features, and better security.

We primarily use the platform to deploy microservices for all kinds of stacks and to deploy databases. Some of our databases are cached, and we can containerize them. Our entire infrastructure relies on OpenShift because we deploy all our applications to it.

Our primary use case is to deploy Java and Angler UI codes into the platform's containers. We will soon migrate our product infrastructure to OpenShift. 

We have working nodes in the OpenShift Container Platform, we have six working nodes and we have a master working node. We have a Jenkins pipeline to operate our deployment and, CI/CD operations. We create some pipelines to deploy the code to the containers and those containers activate on OpenShift Container Platform ports or working node ports.

We have been developing telco cloud-native applications that need to run on Kubernetes. In our deployments, we've used both, Kubernetes and Red Hat OpenShift.

Our customers value the monitoring and logging functionalities which are also our most valuable features. 

The product is used to deploy applications. We provide the base image that has the fundamentals for the BPM product. Then, it's in our docker farm and another image is created that extends the base image. The second image adds application-specific requirements on it. Basically, it's layering the application on top of the base image and a new image is created and that is deployed onto OpenShift.

For the majority of use cases, we're actually building APIs for both the enterprise API and also OpenAPI. It's mainly for integrations for the backend. We implement the system for the customer.

It's deployed on a private cloud and on-prem. We are using version 5.8.

We use OpenShift Container Platform for load balancing, scaling, self-healing, and distributed key database features. It helps us monitor cluster configuration.

We are using OpenShift Container Platform to build microserivces which are financial business logics, such as payments, transfers, KYC etc. These serve as the defacto logic consumed by any channel. We are also leveraging the networking and securing capabilities of OCP which serves to secure and control on granular level.

Our company supports most of the banks in India. We use four kinds of solutions broadly categorized as UPI and IPI deployed on AWS called ROSA and on Azure called ARO.

We use OpenShift Container Platform for on-premises services.

It's a Kubernetes container orchestration solution. Ideally, we will deploy it in the cloud, but it is on-premises for now. We also use Red Hat Linux servers. Some of our operating systems are also Red Hat Linux. All the Red Hat products work well together, and people at my company are familiar with the platform. 

I mainly use Container Platform for hosting and orchestrating our internal application.

We are using it for a payment system.

The way our consultancy works is we have a number of internal products which we use, such as testing systems. We deploy our applications in scientific products and take advantage of automation. We are focusing on automation development for our customers.