OpenShift Container Platform Review

Can be controlled at a granular level and has good auto-scaling features


What is our primary use case?

We use the solution for a financial institution, with a niche implementation. They're re-architecting their entire functions, flows, and creating microservices. They're running a security infrastructure platform as a service on OpenShift. We provide and develop services for the client. 

How has it helped my organization?

The client benefited from greatly improved Infrastructure improvements in relation to cost.
For each kind of module, there are several approaches that can be used. For example, within the transfer module, there are multiple different kinds of transfers that are associated with different aspects such as international laws, central bank laws, and regional laws. The solution has to deal with a number of metrics and compliances. They had several servers just to handle all these demands, including necessary compliance checks. Security is also very important.

OpenShift has reduced its reliance on different hardware drastically. The service takes care of any resource requirements. This is demonstrated by the processing of transactions. Normally the process that services transactions at specific times keep running, regardless, thus taking up resources. This is not beneficial when transactions only need to be processed at certain times of month such as the start of the month where the load is needed at the start of the month. The autoscale feature of OpenShift will automatically expand your service at that point. Once the monthly transactions are processed the resources are "auto-scaled" down once again. This is a very powerful feature.

What is most valuable?

The auto scalability feature, which is based on smart agendas, determined from pre-prepared rules is the most valuable feature. You can also create different routes for deployment. Deployment types can be provided with an identifier, such as an ARB deployment. This really helped in rolling out releases without disrupting services for the end-users.

Secondly, there is the ability to control at a granular level. For example, they can release two versions of the same service and control the traffic towards it to a specific percentage.  Other organizations don't seem to use this feature in the same way we did. Additional rules can be specified to determine individual versions of a service, and rules for governing users access to such services.

Marketing can also make use of OpenShift by analyzing logs to provide useable data. This is one of the features that I really like about OpenShift. It is also a secure environment, with user access configurable at a very granular level. Depending on the API and the ecosystem, it is possible to completely plug and integrate. You control how the deployment works and the testing process. 

What needs improvement?

From a networking perspective, the routing capability can be matured further. OpenShift doesn't handle restrictions on what kind of IPs are allowed, who can access them, and who cannot access them. So it is a simple matter of just using it with adequate network access, at the network level.

It should be possible to whitelist IPs so that you can allow and restrict access to the API. That would be a fantastic feature. OpenShift would then encapsulate the entire security and access. This is one improvement that I would seriously want our client to have, and for that reason, I have joined the OpenShift community, and it is a project I could probably work on myself. 

The second thing is that deployment is more of a strategy rather than a feature in OpenShift. Although you can create different routes, and it works fine, it is not an innate feature of OpenShift that it understands that you want to run specific versions of the same service as needed.

For how long have I used the solution?

I have been using OpenShift Container Platform for two years.

What do I think about the stability of the solution?

It is very stable when it's running. So far, I haven't found any issues. We went through operating system upgrades. We did need to perform some patching, so there was some vulnerability and there were many tasks we had to undertake to assist with stability. In fact, we use two clusters. One of them is used for non-production purposes. It is a developer's structure and is a very stable solution.

What do I think about the scalability of the solution?

The auto-scalability feature, which is based on smart agendas, can be determined from pre-prepared rules. You can also create different routes for deployment. Deployment types can be provided with an identifier.

This is very flexible and saves resources when you don't need them, and scales up when you do. This is a very powerful feature.

How are customer service and technical support?

We used the Redhat TAM service i.e. their exam service. They assign a technical application manager to you, and we have used that. The support is very, very responsive. They're a sponsor. They respond very quickly. What I like about them is that they have a very precise requirement. They will ask you for one single solution you require. That's it. They will come back to you and provide point pinpoint in-depth guidance into the problem that you have.
Unlike most support companies, you usually obtain a workable solution in a good time frame.

How was the initial setup?

It was very complex to setup. We had to set up Ansible, the IT automation engine. This uses playbooks. The playbooks are quite complex. It's very hard to understand and is a steep learning curve to completely understand them. 

The playbook is quite complex. If you miss out on any configuration it takes a long time to fix. This is inevitable with a huge corporation with multiple different services. You have to uninstall the whole thing, go back, fix the playbook issue, and redeploy.

The first deployment I did was with Red Hat. This took us three days to be completed. Because every time there was some configuration issue or something that was misunderstood. It's not straightforward to fix. This was in version 3.11. From 3.4 they made it easy if you are on the cloud. The installer will ask if you want OpenShift to deploy a connection to the cloud, which also creates an infrastructure for you and deploys all of it.

At the corporate level, you have security and compliance concerns to be addressed during deployment. It gets really tedious on how you're supposed to have an installer which provides guidance, asks questions, and more elaborate questions where they are needed. Then, there is the question of "labels". You have to understand what those labels actually mean, and then supply a value against that label.

There are organizations out there who are ready to go for OpenShift but are not willing to pay for that kind of service. They want the in-house capability of OpenShift deployment but that's about it. There are not many of these people in the market. They only wish to use the deployment capability but it's a bit tedious. It is however a one-off operation. You don't go about every day deploying software, so it is not worthwhile obtaining the whole solution.

What about the implementation team?

This was an in-house implementation.

What was our ROI?

Infrastructure costs reduced by 50%.

What's my experience with pricing, setup cost, and licensing?

It is a costly solution but then again, it's intended for enterprise-level business, and the license has to reflect that. We implemented the solution at a college. It is appreciated what the GPU's processing power requirements will be higher. The licensing is very flexible. The license is related to the processing power you need, and the infrastructure of any clusters which go with that. 

Which other solutions did I evaluate?

We had a comparison between OpenShift and Pivotal from VM. But OpenShift is on another level to Pivotal. 

What other advice do I have?

A common mistake is to assume that the solution can change the architecture type. e.g. some people think by using this solution they can change their application architecture into a microservices architecture. OpenShift is an orchestration architecture. These types of solutions are not intended to be run as a microservices architecture. Very often, the two become confused.

As the cost of this product is expensive it should only be considered for large enterprises. There will also be a need to hire technical people, and this may also involve a training cost. 
There has to be a cost-benefit. It can be done as a single solution, but the solution itself is huge. 

You also need to make the best use of the solution. If you are processing millions of transactions, that would describe an adequate use. You need to calculate the solution costs against the work it is designed to do, otherwise, it becomes a cost overhead. Certainly, for a single application, it would be a waste of money.

I would rate OpenShift Container Platform a nine out of ten. 

Which deployment model are you using for this solution?

On-premises
**Disclosure: I am a real user, and this review is based on my own experience and opinions.
Find out what your peers are saying about Red Hat, VMware, Nutanix and others in Container Management. Updated: January 2021.
457,459 professionals have used our research since 2012.
Add a Comment
Guest