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.

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.

· 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.

Kainos provides digital technology services and platforms for organisations across the globe.
We've been delivering award-winning IT solutions, consulting and specialised digital products for over
30 years, and employ almost 1,000 people across Europe and the USA.