Pass the dutchie pon the left hand side

6 | Written on Thu 18 June 2020. Posted in Posts | Richard Walker

It's incredible how much extra time I've had on my hands during 2020 due to the global pandemic and being grounded at home. It would be a little shameful not to use some of it to write the odd blog post. I read an article recently that the Kubernetes Project, the foundation of which OpenShift is based, celebrated its 6th anniversary. I have socks older than that!

I recognised the potential of such container platforms back-in-the-day. Now, into my third year working as an OpenShift consultant, I still feel there is so much more to learn. OpenShift is a considerable product with many facets. There are deployment, operational, support and development perspectives all with there own plethora of required know-how.

That's fine though, working in the Information Technology sector for prolonged periods, you learn that you need to re-learn and evolve with the technology to remain current. So with my previous long term experience, this had me asking, what problem was Kubernetes trying to solve? Who is it for, exactly? Why is it in such high demand today? And does it make our world a better place?

Here is my view on the answers to these questions.

The first question of what problem Kubernetes aims to solve ultimately boils down to business demands. The picture was a common one where the business would demand features, changes and requirements with deadlines. Such changes were and still are notoriously challenging to develop and release with a quick turnaround. Typically, due to governance and compliance enforcing strict change controls. That, coupled with often a significant dependency on an operational team to perform releases the whole process takes days, weeks or longer. So in simple terms, the Kubernetes project aims to provide a platform that facilitates the deployment of software in a safe, controlled manner, with ease and speed. Moreover, it enables this at scale.

Musical Youth

The second question, Who is it for, exactly? I believe, is a misunderstood one. I recently came to realise something quite significant, though. Working with containers, in general, passes a large percentage of deployment control and configuration to the developer. It would seem the drive and motivation for Kubernetes are developer-driven. This approach might help to explain why it felt somewhat challenging to get to grips with the technology coming from a system administration background? It's what reminded me of the song Pass the Dutchie by Musical Youth. I had the image of an engineering release team singing it, passing over the responsibility and putting their feet up, folding their arms. "Just push your container image to the repository and magic will happen now.". On the other hand, a developer wondering if they ever asked for a Dutchie in the first place and not even sure what one was.

Why is it in so much demand? I believe the first two questions partly answer this one. In a typical business environment, its the business screaming at the developers. Therefore, its the developers who feel the pressure and frustration of not being able to deploy their code quickly. However, I have to throw caution to the wind here and laugh a little. Remember, technology changes quickly, but people don't. Sometimes sales by technology vendors have been made on golf courses by executives. Vendors promise their solution will solve all your problems. The TV show Silicon Vally highlights all of that entirely in the form of the company Hooli, "Hooli isn't just changing Silicon Valley we're changing the world." The hype can become, so exaggerated, and vendors can start believing in it themselves. "The Box Three, Gavin Belson Signature Edition." The serious point I want to make here is that new solutions never solve all your problems. Even if they solve a high percentage, I can guarantee new technology introduces its own set of unique issues and overheads. It's why ten years ago I was working with Red Hat Enterprise Linux (RHEL) 6 and JBoss, five years ago RHEL 7 and Puppet and today, RHEL 8, Ansible and OpenShift. Still busy, just spending most my time with different technology.

Musical Youth

So why is Kubernetes in such high demand? Well, maybe, in the case of deploying software at scale, Kubernetes does deliver a lot of value. Companies are observing success stories from their competitors and afraid that if they don't jump on the bandwagon, they might be left behind.

Considering all of this, does Kubernetes make our world a better place? I guess it could, but not necessarily. Container adoption and migrating to a Kubernetes platform is one thing, skilling up teams and fundamentally changing the way development and deployment of code get done within an organisation is another. Choosing this path is for visionaries who can see the long term benefits. These benefits will come where development operations happen, business as usual.

Why OpenShift? OpenShift is a product based on Kubernetes by Red Hat with support subscriptions and includes additional tooling and features that enterprises find essential. Organisations who are today looking for digital transformation and adopt Kubernetes look to Red Hat for the expertise, help and support with a more enterprise-ready solution that comes with assurances.

What about the value? There has been another common trend in the industry for cloud adoption. It's also prevalent for OpenShift customers to host it on one of the big three cloud providers. Running infrastructure this way moves capital expenditure (CapEx) to operation expenditure (OpEx). You have to be cautious here because OpEx can ramp up very quickly when deploying resource-hungry software. However, any business savvy person will be quite aware that if the revenues gained through faster time to market outweigh the implementation and OpEx of OpenShift in the cloud, it has to be worth it. A key point here is don't think that moving everything to the cloud is a cheaper alternative to in-house data centres because it isn't. It's when the ability to change, flex and automate things at speed translates to extra revenue, not previously possible does it become desirable and viable. There is a balance to be weighed up.

Eena Mozhvilo Unsplash

It does look like Kubernetes, and Red Hat's OpenShift is the container platforms of our foreseeable future. With some thought and evaluation, sure there are huge benefits to gain. However, it would be dangerous to believe that a quick install and hey presto, all your problems solved. It is critical to understand that roles and responsibilities get handed over not eradicated and that OpEx is not necessarily cheaper, if at all than CapEx. Moreover, introducing new ways of working and technologies introduces new overheads in their own right. I'm yet to see a solution that enables me to put my feet up. On the contrary, I feel busy than ever. Finally, even though the Kubernetes project appears to be developer-driven, not all developers know it or necessarily believe they need it. It might, to some fell like extra burdens. In an ideal world, OpenShift adoption should be from the bottom up, but in the real world, it's often mandated top-down. The good news is, I believe in the case of OpenShift, it's a solution that will ultimately pay dividends in more ways than one. Developers will learn to love it, operational teams will appreciate it, and the business will benefit. A win, win, win?