Why it is critical to find a good kubernetes resource

I may have seen it all -

A team trying to adopt the next best shinny tool and believe that would be the holy grail of all.

A Team adopted the latest & greatest and cursing each other for the decision they have made over a few spirited CTO calls.

1. Why is it so talked about technology?
2. How can it be so popular, off the chart still a fearsome technology?
3. What should you look for in a candidate?

Why is it so talked about technology

So is God , God particle and Mask or no mask rallies.

Basically if you do not understand something you pay more attention and sometimes it creates almost a mystic avatar of oneself.

That creates problems on two fronts: knowledge gaps and differences in expectations.

Your boss is sold over containers and kubernetes and figured that’s the next place to land after the moon to find water.

I am not here to bring in all the wraith of the dragon by specifying what k8s can do for you or not (a google will find you lots of links). But it’s proven it has done some good right?

Otherwise why google along with a large open source community lined around it. Along with it came other big new names (out of FOMO fear of missing out) IBM. Microsoft, AWS etc.

So it has some credibility, let’s bank on that and shift focus to-

How can it be so popular, off the chart still a fearsome technology?

You have to rely on me, if you are just part of one big fat enterprise.

I worked as a consultant and fortunately my mode of work allows me to work with different enterprises and I see the pattern.

For one individual, it might be a very unique problem, but for us it’s a pattern.

Kelsey Hightower (a famous advocate of kubernetes), once said (I’m pulling it out of my memory and sorry if I am wrong)

“You might think your application is very unique, but to me, it’s all the same an end point over a protocol to serve something”.

Do you see the pattern? ABC address, binding and contract.

Each enterprise has its own set of complexity, and in some cases it is unique, but it doesn’t need to be that way, rather aiming for an unique solution to the so-called unique problem you have, you can standardize your problem and choose your solution a normal well shaped industry standard solution.

It may sound harsh, but look at it radically: who would have thought (a few years back) that a bank, a postal service and a coffee shop chain would have the same set of problems, finding a good 100% original reliable kubernetes resource :-).

Normalizing the problem or challenges you face day to day should be one of the priority, before you hang onto an unique solution.

Now that brings us to the question why it is so challenging, that after two decades of exponential growth of IT technologies, industry is still going through a major tech refresh?

Remember when an AI learns 5% more, it has a 5% more chance to roll up a 5 % better version of the same release, in IT a tech cycle is hardly more than 6 months, when a new shiny tool outperforms an older one.

Then in two decades 20 years of timeframe, with all that we have achieved, came short to give the stability we need.

And that’s the problem google and other major companies work on data (facebook, Uber etc..) tried to solve. Two things you can notice about all of them

1. Extreme obsessiveness toward microservice based architecture
2. Eliminating the lines between operation and development

I won’t ponder on microservice, because that is the goal and we have all the right tools at our disposal and plenty of articles one google ahead, it’s our pick to choose.

What about the second one? That is like the elder brother who everyone depends on, but no one pays much attention.

What could be the best reason you can think of to adopt kubernetes? If I stop you to use orchestration, container, CI/CD all these good words? Please comment below.

Let me tell you my take on this

How to neutralize a threat / a problem or challenge?

You bring in your fighter jets to get strategic support from air, your ground team get you all the tiny details, visibility and mark down places to aim all the missiles from above and finally your navy strategically put in places to bring in support on demand.

Now think about the coordination it requires, different teams acting in different control planes.

Think about the real production nightmares, (one of the reasons behind major terrorist attacks are lack of information coordination among various departments of states).

In most of the cases I have found 4 major teams / groups have more than 95% stake in all of these.

1. Security
2. Operation & Maintenance
3. Infra
4. DevOps/Individual application team

And all of them work on a different control panes with a completely different mindset (unfortunately).

Security has major impact, but with less control, they know about the security controls should be/could be instrumented in places, but they do not control how, because it depends on the vigilante of the rest of the groups to make it happen and that makes auditing hard (why? because, control plane of operation is different).

Operations & Maintenance has legal and moral responsibility to the security controls, it’s mostly their heads under the bus, and I hardly found an emotional attachment for a specific application and how that might have impacted on the slightest changes they do.

Infra folks try to keep a balance between workload and operation (& maintenance), but with the current set of tooling’s (terraform etc..) , it is too rigid to be flexible, transparent, secure and then to remain fair, at the same time to the never ending change cycle of the actual workload!!

And Yes Kubernetes provides that control plane where each of these teams can play along together. It’s a perfect non sticky glue which does its job.

Now that is the most notorious and challenging of all and derails kubernetes adoption goal or ambition for most of the enterprises, as I said at the beginning, the knowledge gap of expectations and understanding of the underlying architecture do’s and doesn’t.

Inter departmental confrontations, letting go of ownership, letting in new concepts and understanding and lots of frustrations.

And if you can’t address these partly human and partly process related issues your k8s adoption story mostly ends in a failure or not as effective you have expected it should be.

And that’s bring us to the final question, What should you look for in a candidate?

So one of the easiest way is to find out a moderator who may not have perfect organizational knowledge of all the subject matters of all the parties involved, but can answer, confirms, assure any questions or doubt about the whole orchestration concept , k8s adoption and bring everyone else in the table to the same page, where everyone else is ready to listen.

So when you are looking for your next best kubernetes resource, you basically should look for a good moderator and teacher or a preacher.

A product (kubernetes) has been sold, without any assurance of after sale support, You need someone who can provide that as well as reminds you about the real reason for the adoptions, whenever doubts arises.

Happy Hunting!