Docker Swarm or Kubernetes?

 Lately I have had 2 leader's come to me with this question "Docker Swarm or Kubernetes?". Their teams were divided on what to use and I was being asked what is your preference and why?

Firstly: Its good to know that Docker Swarm is finally getting mindshare.

Second: Competition is always good.

Short Answer : Kubernetes

Long Answer : Use what fits well. 

There is no doubt that Docker Swarm is super easy to setup and use and for a small team that just knows Docker and that wants to do a quick cluster of Docker instances. Also there are great Web UI's like Swarmpit and Portainer available that assist with the same.

But "Out of the box" Kubernetes gives you the above and some more but with has some complexity to it.

Eventually Kubernetes is used mostly with Docker containers so some might say that a comparison of Docker Swarm and Kubernetes is not really ideal. And I agree to some extent, when I look at those as products but when I look at an end to end solution they can be compared this way.

But from my perspective the single biggest factor for me to choose Kubernetes over Docker swarm is not a difference in capabilities , its more to do with trained personnel available to manage them as you will find a lot more engineers who know Kubernetes than Docker swarm.

But the lines are blurring between the capabilities of the two with time and I see that may be soon enough we will see them as strong competitor's to each other.

Practical Leadership: Take calculated risks

"Risk hai to Ishq hai"

How often do you see Manager's who are extremely risk averse.  I have had the chance to encounter many such Managers who were such risk averse that things would stay in status quo for years even though it would impact them and their teams every day.

But risk averse behavior is not just a behavior that is exhibited by individual's, I have seen entire organization's being risk averse. 

The culture of the organization is usually to blame. The reasons almost always were

1) If you get retaliated on for the risk you took that resulted in a failure.

2) Processes and Rules discourage any risk taking capability.

So what is the solution?

What you should do is to inculcate a culture of taking calculated risks and train / hire leader's who can not only take calculated risks but also get their reportees to take such risks.

Taking Risks is not bad till the time every possible problem it can bring in accounted for. Always have a plan in case things don't work out. 

Calculating Risk and taking them is not very difficult to work with if you follow these  simple steps

1) Research well on what you plan to do

2) Identify Stakeholder's and how it will impact them

3) Anticipate Mistakes 

4) Set Checkpoints and Goals to measure your changes the risk brings.

5) Be ready to course correct OR jump to an alternate Plan

6) Don't be afraid to cut your losses and revert from the Change

7) Learn from your successes and your failures

8) Repeat

and

Something that is not given its due importance but should be which is to "Learn from other people's mistakes"

and least I forget

Enjoy the benefits of the Risks you took when things go as planned.

FIN

Practical Leadership - ESI before CSI

ESI = Employee Satisfaction Index = How satisfied your employee is

CSI = Customer Satisfaction Index = How satisfied a customer is with your service / product

I had had the unique chance of working with Engineering as well as Support teams where CSI was fairly low as in the mid 20's or lower 30's. There were real issues that needed to be dealt with like

1) Processes too inefficient or too dependent on a single person / single team.

2) Lack of Product knowledge

3) Lack of support from Account Teams

4) Incorrectly set Customer expectations

5) Too little resources resulting in too much work

etc

but one area that would almost always get overlooked was how satisfied the Employee was.

The aspects that got invariably missed out were

Right fitment of the Role

Availability of the right resources

Right Mentors

Acting on Feedback from the team.

Conflict Management

Basic concerns about compensation and allowances

Quality of work (reducing monotonous work)

Good Leaders

Vision of the product

There were instances where despite a lot of changes teams would not go beyond 40% on the CSI score's consistently till the ESI aspects were taken care of. > 70% CSI was very much achievable in most cases after taking care of the ESI concerns.

Hence low CSI could very well be a symptom but the Root Cause could very well be low ESI. 

Moral of the Story: Fix the right problems to get the right results.

There is a 8086 processor in every modern x86/x64 processor

 Quick: Identify what this assembly language code does in a 'com' file on MS DOS

dec ax;

push ax;

push bx;

iret;

It restarts the machine!! But why?

A com file on dos is loaded with the AX, BX, CX and DX registers set to 0000h.

dec ax; --> Decrements AX register by 1, hence turning 0000h to FFFFh

push ax; --> Pushes AX register on to the stack which is FFFFh

push bx; --> Pushes BX register on to the stack which is 0000h

iret; --> Fire interrupt return which will grab FFFF:0000 off the stack and load it up in Program Counter

So what lies at FFFF:0000, a simple google search gives us this

" The reset vector is a pointer or address, where the CPU should always begin as soon as it is able to execute instructions."

Basically the CPU starts running code from the BIOS / UEFI , effectively restarting the computer.

BTW...this is not equivalent to int 19 which claims to restart the computer. Int 19 will most likely in some instances restart your boot loader than restart the x86/x64 machine.

This code was the basis of a shutdown/restart program I once wrote to enable dos based virus scanning.

and

This code works right since the 8086 processor.

Coming Soon...

The Impossible Release

ESI before CSI

There is a 8086 processor in every modern x86/x64 processor

How to Delegate work

Practical Leadership - Care for your reportees

 I still remember once when my Leader called me up as I was driving down to office to tell me that there is a huge crowd of people below the office protesting (my office was next to the Slum Rehabilitation Office) a change in some bylaws; he told me drive down to a different parking spot away from this chaos.

He did not have to do this, he could have simply ignored to let me know and it was not much but it showed my Leader cared. This got deeply imprinted in my mind and today still serves as a reminder as to why I take care of my reportees.

Simple things matter; showing you care matters. 

Today if one of my reportees falls ill, I call up OR drop a message and ask how he/she is doing. If someone's close family member is not in the best of health I ask my reportee to take some time off to tend to their near and dear ones. Fancy gifts, an award from the Office front etc are important, and will act as a short term feel good factor for your reportee  but those will be forgotten. 

What you will be remembered for will be that you genuinely cared, showed them you are human and eventually that's all that matters.