Tags

, , , , , , ,

As a middleware (to use a fading term) or technical architect, I preferred not to get too involved in the detailed OS layer considerations when it can be helped (my Infrastructure Architect colleagues will always know more about NICs, port bonding, kernel versions etc etc than I ever will) and why I prefer to work with PaaS over IaaS.

But there is an undeniable trend where having a greater understanding of the OS is necessary, this is because we’re seeing PaaS expanding to cover code abstracted solutions such as Oracle’s Integration Cloud, Mulesoft, Dell’s Boomi etc. down to every things as code in the form of Terraform, Kubernetes, Docker and of course  microservices.

So what does this have to do with OpenShift?  Well to apply those heady aspirations we’ve had with middleware of “I can build my solution and run it on my platform anywhere” means in the world of microservices I need to find a common denominator on which I can be portable.  This comes in the form of Kubernetes and Docker and we’ll probably see service meshs in due course (Istio, Linkerd etc). Docker obviously brings the need to understand the OS albeit not at the level of bonding network connections, but still a good level of OS knowledge to do things properly. Over the last couple of years there has been a fair bit of work to achieve this with the inertia of Cloud Native Computing Foundation (CNCF), Open Container Initiative (OCI).

What is clear is that Docker + Kubernetes is the way to go with CNCF certifying compliance (see the certified list here). To the point we’ve seen a bit of an ‘arms race’ of who can get their Kubernetes cloud offering into General Availability first …

The interesting thing is the absence of RedHat who (at least in my world view) have been traditionally the leading proponent of offering hardened  versions of Open source Solutions (RHEL, JBoss, Fuse …) as conspicuous by their absence. Now OpenShift does includes Kubernetes (and I’m consciously avoiding getting drawn into the debate of whether or not it represents a code fork or not), but also adds other layers that wrap and mask Kubernetes and in effect prevent you from using Kubernetes in a vanilla manner. This is compounded by the fact that RedHat are removing the Docker and Kubernetes RPMs from repositories for RHEL 7.5 onward as described here. When you look at this, you can see why RedHat haven’t sought to get certification from CNCF.  But is it the right thing to do?

This approach of pushing people towards OpenShift (devs can get a single Node OpenShift now – (see here)) this could well be a flawed decision. At least it appears to be going against the general trend. My issue with OpenShift is that it is something of an ‘opinionated platform’ in the same way that SpringBoot is opinionated.  It gives you something that will run and takes away the complexity of setup; but if you need to work a little differently then you need to revert back pure Spring. But the analogy does fail, as unlike SpringBoot I can’t drop down to the underlying elements. For example I want to use Nginx rather than the HAProxy as the Ingress reverse proxy element it can’t be done.

There is an argument that says if you can run OpenShift on any cloud then I have portability and also benefit from the greater levels of abstraction (Java compared to C++). To that end OpenShift is available on Azure (more here) and RedHat managed (on AWS and Google as the Dedicated service – more info here) along with a number Service Provide Deals (Atos, DXC). However it doesn’t escape the opinionated position.

So why is having an opinionated framework a problem? Unless you’re fortunate to be working with a clean slate the processes of building and deploying software and associated containers is going to have a level of pre-existing infrastructure, processes and of course infrastructure. Ningx as a proxy, External Nexus repo which is wrapped with checks and balances such as role based authentication and so on.  If  tools such as Wercker are in your existing ecosystem bringing them to work with OpenShift is going to force change on you.

It also removes flexibility in the way things are done, and we’ve seen how imposing specific ways of doing things have eventually led to people choosing or creating different solutions. From simple examples such as people not liking how Java did somethings, so new JVM languages have sprung up such as Scala (read the interview with Martin Odersky here) and Kotlin (see here).

I would have hoped, that RedHat had followed some of the ideas of Docker Enterprise Edition. Which provides more of a platform and features, but it allows you to use Kubernetes or Swarm for the container orchestration for example.