An Opinionated view of RedHat's OpenShift

The picture above illustrates the need for a stable platform when deploying your containerized applications in production, RedHat have a solution for us and it is called OpenShift.

This article is not meant to be a tutorial on OpenShift nor Kubernetes, rather a collection of scattered thoughts and observations that I wanted to share here.

I recently attended an OpenShift talk sponsored by Redhat, I went to the conference with my developer hat eager to learn how this product will make life easy for my team and I.

Having deployed applications using AWS ECS/K8s for the past 18 months in an E2E CI/CD, I had something to compare OpenShift to which I could contextualise and draw conclusions from.

OpenShift is presented as PaaS and comes in four flavours:

Openshift Origin (open source, the focus of this post) Openshift Container Platform (Previously Enterprise) Openshift Dedicated Openshift online.

Getting OpenShift Origin up and running

This was barely a five minutes task, there are two components to the installation: the server and the command line client tool called OC. The server can be installed in a variety of ways using docker, vagrant and bare metal.

Once both components are installed, getting started is as simple as heading to HOST 844 or use OC, you then need to create a Project, which is an all-encompassing wrapper around K8s namespaces. The AAA is handled by Openshift and is based on users and groups, this allows for multi tenancy and granular segmentation of different teams and apps.

After that I spent sometime getting familiarised with the UI and the OC command line tool, the rest is plain k8s with some fairy dust on top.

A K8s high level refresher concept is summarised in this diagram:

Using the OC command line, your pod behaviour and configuration yaml file can be extracted as you would expect and is similar to kubectl in many ways, your deployments and replication controllers do the same thing in k8s and your services provides the same level of abstraction.

The Openshift routing layers uses HAProxy internally that allows external users/apps to access your application.

You can examine logs from within the web console, you can also re-route these to your favorite logging service.

External applications can use the RBAC built into openshift, this allows for granular permission for a specic user e.g. an application can be given the permission to only query a certain API.

I still don't get it, why OpenShift?

The real USP of Openshift is the stuff that is added on top of Docker and Kubernetes that makes it a true PaaS:

� A rich web-based console that allows for collaboration between dev and ops, real deployment, scaling etc.

� Multitenancy & Vendor neutrality

� Integrated logging & health monitoring for full visibility of application state

� OC commandline , everything you need can be done with this tool

� S2i (Source to image)

� API integration with various CI/CD tools

A note about S2i

Having implemented an in-house version of this in my previous job which accomplishes pretty much what RedHat are advocating, the biggest challenge one will find is not so much on the technical side but in the discipline required to have a standardised way of building maven/node/CPP etc? projects , it can be very much opinionated. Not an unsurmountable task by any means but can become exponentially harder with multiple global dev teams. enforce those best practices now!

What about AWS?

It can be argued that amazon AWS ECS is equally easy to use and more appropriate for smaller teams, which is all true, but ECS only comes alive because of the different services you can interact with such as Lambda, CloudFront, EC2 etc.

That's why RedHat decided to do a tight integration in the form of an exclusive deal with AWS, a boon for every enterprise. That old adage of 'one throat to choke' still rings true.

What about small teams, is Openshift an overkill?

At first, one can visualise it this way:

As the picture illustrates most poignantly, with any big investment your ROI needs to be assessed, getting to grips with OpenShift is a breeze if you have an existing team with Microservices concepts/Orchestration/Containers skills and the capacity to install and maintain an entire system that might not deliver real benefits until an application reaches a certain size/popularity.

Conclusion

Aside from having arguably the best orchestration tool in the market (Kubernetes) as a base, personally I would like to see us use openshift as it facilitates collaboration between Dev and Ops and improves visibility of the development lifecycle, deployment and monitoring, integration with third parties is becoming more apparent so your skills are more valuable.

The learning curve is not as steep if you have the fundamentals nailed down, but it might require some investment in training.

From a strategic point of view, it is vendor neutral, integrates with other platforms such as OpenStack, on prem and AWS so can absorb and operate alongside existing infrastructure/applications, minimizing disruptions.

What's not to like?