OpenShift Pros and Cons

Security is also an important part of this solution. By default, things are running with limited privileges and securely confined to their own resources. This way, different users and projects can all use the same infrastructure.

Self-provisioning support saves a lot of time and unnecessary work from the system administrator who can use this time to run and monitor the infrastructure. For the developer, this means less time waiting for the provisioning and excellent flexibility for development, testing, and production. Also, in such systems it is easy for developers to monitor applications even after deployment.

Excellent GUI support, so one does not need to use the command line client for almost any tasks. Great support for building images directly from Git repositories with hooks.

Great integration with Jenkins for constant integration and development. Supports all the major languages and environments - PHP, Java, Node.js, Ruby, etc.

I love to automate everything and OpenShift was been born for that. It takes care of the network layer itself and I don't need to dive into it; I can work on a top level. Our project has numerous services designed to run in Docker containers, and we have run almost all pieces in OpenShift.

Scaling and uptime of the applications are positives.

The virtualization of my APIs means I no longer have to pay VMware large amounts of money to only run in-house solutions.

We are able to operate client’s platform without downtime during security patch management each month and provide a good SLA (as scalability for applications is processed during heavy client website load, automatically).

Valuable features include auto-recreate of pod if pod fails; fast rollback, with one click, to previous version.

Key features are WildFly, because it standardizes infrastructure and the git repository and docker. Git is essential for source code and Docker for infrastructure.

The area for improvement is mostly in support for legacy applications.

I think that OpenShift has too many commands for running services from the CLI, and the configuration files are a little complicated.

Needs work on volume handling (although this is already better with GlusterFS). Security (SSSD) would also be an improvement.

There have been some issues with security, in particular, that we had to address. At times they make it “clunky." I am quite confident these parameters will appear in the next releases. They have been reported as bugs and are actually in process.

It could use auto-scaling based on criteria such as transaction volume, queue backlog, etc. Currently, it is limited to CPU and memory.

Credential not hidden, so people on the same group can view it.

It would be great if it supported Bitbucket repositories too.