The story of Lord Shiva and Bhasmasura - what can we learn from it..

Storytelling is an innate human quality! We often do it to teach , influence and inspire...

Indian Mythology is one of the richest elements of Indian Culture. Through time, different stories in Indian mythology have been passed from generation to generation either by word of mouth or through carefully stored scriptures. It is a very fascinating world , it sparks human thinking , fuels creativity , and has high entertainment values.

One of the stories of Lord Shiva and Bhasmasura ( Asura / Daemon ) goes like this:

               PC: various vedic sites from internet. Not distorted , used just for depiction.

Bhasmasura :

Bhasmasura was a very strong daemon but he used to act before thinking. He wanted to become the most powerful Asura in their community. He knew Lord Shiva was very generous and could be easily pleased and was capable of giving any boon of his choice , so he decided to perform severe penance to win the heart of Lord Shiva.. Every day, during his prayers, he used to cut a part of his body and offer it to Lord Shiva to please him. He repeated this for many days. 

Lord Shiva :

Out of 10 qualities of Lord Shiva -  one of the qualities which made him very different from everyone else,  was that he was a 'benevolent deity'.  He was a kind hearted lord ,  "The Bholenath" , and has an ocean-like forgiveness quality. 

And hence ,  Lord Shiva was pleased with Bhasmasura's prayers and came forward to grant him whatever boon he wished for. 

The wish of Bhasmasura :

Bhasmasura wanted to be  immortal , so he said, "Lord, please grant me the wish that whichever person, place or thing I place my right hand on, is reduced to ashes".  Lord Shiva granted him the boon and Bhasmasura was very happy.

Wicked Bhasmasura :

Bhasmasura, being the wicked demon ..as he was .. wanted to try his boon on Lord Shiva himself and tried to touch his head. A panicked Lord Shiva had to run away from Bhasmasura and approached Lord Vishnu to help him.

Lord Shiva himself was immortal , hence, it was a now a severe contradiction which he landed into by granting this boon.

The saviour - Lord Vishnu takes the ‘Mohini Avatar’:

Lord Vishnu changed himself into a beautiful young girl Mohini. Bhasmasura stopped as he had not seen such a beautiful girl earlier.. She was so beautiful and so graceful that for a minute Bhasmasura even forgot who he was. She talked in a way that she caught him in her beauty. He fell in love with Mohini and asked her to marry him.

Mohini continued, 'I am a dancer Bhasmasura. When I was younger I made a promise that I would only marry a man who can dance as good as mine’ .  Bhasmasura readily agreed to learn to dance for his new found  ꒒০⌵୧ ♡ !!

Bhasmasura Vadh:

( How Bhasmasura was killed )

Mohini started teaching two different dance moves to Bhasmasura. Bhasmasura was fully concentrating and was getting better and better in his moves.

Mohini soon won in her trick and kept her hand on her own head. Without thinking Bhasmasura did the same!

Lord Shiva's  boon worked 😇 and he was burned into a pile of bhasma (ashes). Mohini was looking at Bhasmasura's ashes as Lord Shiva appeared before Mohini. Lord Shiva went back to Kailash, thanking Lord Vishnu.

What can we learn from this story :

• Beware of friends & followers , not everyone might be a real friend or a follower. 

• Be generous , but not too much. Understand and anticipate potential implications of any act.  Think before you act!

• Everyone makes mistakes , even the most powerful and brilliant people. 

• You must cultivate friends , if Lord Vishnu did not come for Shiva's rescue…

I leave this great indian mythological story for your further interpretation , as that's what indian mythologies do -  i.e. spark our imaginations and derive a learning out of it !!  :)

Until next time .. •ᴗ• !!

PLOT – Story for successful Change

Let me start with a small disclaimer -  In this post I am not going to lecture around what is
change and incident management. Rather one of the effective ways  to plan for a change.
There exists many such tools and flows to effectively carry out a change , however - this is
just one amongst those.

Well , we all know that change is common, natural and inevitable for an organization to grow,

both from a technology standpoint and org structure.  Here, I will try to cover various aspects

of the technological / IT production changes and not the latter. 

According to a report from McKinsey,  70% percent of change programs fail to achieve their
goals.

But why? Its is said that , the reason for such failures is due to employee resistance and lack of management support.

I would say - it is primarily because - “Changing human behaviour is hard”

Successful change management requires frequent and clear communication between an
organization and its people, and most importantly - convincing ourselves and others that the
change candidate is compelling, motivational and realistic!  i.e. every change initiative needs
a convincing narrative. 

American systems scientist  Peter Senge says:  “People don’t resist change, they resist
being changed”. 

I think we all agree that -  any / all change initiatives must be backed by a process,
so as to ensure it is well organised , and repeatable. 

Mnemonics

A bit off-topic , but I think we all would agree that - to remember anything , mnemonics helps us in a great way.  

Remember BODMAS -  The order of mathematical operations? :D

OR - the phrase "My Very Excellent Mother Just Served Us Nine Pizzas" - to remember the planets, sadly Pluto is gone though.. but anyway!

Here comes another one -    PLOT.

What is PLOT ?

Ain't plot is such a familiar word when it comes to movies .. exposition , climax , action etc. etc.

In this case , PLOT is an abbreviation in the areas of effective change management , and it stands for Plan, Lead , Operate and Track.

Fine , how is it helpful?

While there exists numerous processes and flow charts to effectively carry out a change ,
one of them is  PLOT - a method designed and documented by Bain & Company -
one of the most prestigious and global management consulting companies headquartered
in the US. 

This PLOT flow helps us to convince and align ourselves to an end-to-end change
management process , keeping transparency, compliance , various guiding principles ,
communications points and many such things which is very instrumental to execute a
change effectively.

Below is my adaptation with some small tweaks , however if you google it , you can easily
get their original document with more elaboration. 

Step 1: Plan it well.

Step 2: Lead the change

Step 3 : Operate ( Execution phase)

Step 4 : Track it well.

Every organization has its own change management flow , but I am sure this PLOT can be a good chip in that flow for sure.

For. ex. 

During the execution phase many things may go wrong depending on how deep or broad
the change is. It is very important to understand that - “when on principle:  It’s understandable,
memorable, and repeatable , and eventually drives empathy!”

Closing thoughts ..

No matter where you are in the system life cycle, the system will change!
The desire to change will persist throughout the life cycle.
But,  the underlying services should be always stable, reliable, and predictable.

Above images are screenshots from one of my previous presentation, which I know,
is of not the best quality , hence attaching the original PPT herewith.

Download PPT Link

Please dont hesitate to share your thoughts in the comments section..

Happy holiday season and Happy new year 2020!

Until next time ..

Debajit Kataki

The time you spend with yourself!

That walk from your boss’s cabin to your desk … same distance which is sometimes very short, with a relieved and refreshing mind,  and sometimes very long, rattled and engrossed.

Not all conversations go well and often we find it very hard to tackle.  The conversation you just had with your boss or anybody for that matter, could either be exposing your limitations and surface opportunity areas or  sometimes it can also be very re-energising or trigger a sense of renewal.

What we go through in situations like these are – ‘reflections’ and depending on how we take it, these moments could produce varied sentiments.

“We do NOT learn from experience, we learn from reflecting on experience.” — John Dewey

Reflections are nothing but, looking into a mirror and describing what you see. It is a way of assessing yourself, your ways of working which helps you to develop your skills and review their effectiveness!

Self-reflection is a very powerful free tool which gives us perspective and helps us to understand ourselves better.

Trust me – it’s not easy to start at this 😃, as it does not come naturally to majority of us, and in-fact even I am still trying to be regular at this and hence the post -  where I am trying to share my own experience.

I have found it very productive that - when we create some lonely time for ourselves and do some regular self-introspection, it’s actually a game changer!

But how and where to start:

Most of our perennial learning comes NOT from doing, BUT from thinking about what we do, and why we do.

Often, we go through our day-to-day life without spending too much time “processing” our experiences. This processing is very important and fuels creativity.

Questioning in a positive way, what you do and why you do it and then subsequently pondering over ,  whether there is a better, or more efficient way of doing it in the future.

The Real Question:

Just think about this - can I sit quietly for about 5-10 mins daily and reflect on - “If I were to re-live today again, what 3 things would I change to make today better?” Yes! That’s where we need to  start. And as I said – it’s not easy!

When we participate in new experiences, experiences that are outside of our comfort zone or outside of our routine, there is often a lot of learning that can take place.

If we really wish to be a person of indomitable spirit, we must cultivate ‘habits’, good habits of-course! 😃

One of them is certainly creating ‘time-alone’ for yourself.  It’s a time of solitude, where you spend time with yourself.

Our brain is constantly processing and unravelling. Most of the time it’s about our ‘delivery responsibility’ in this busy and competitive world. A cup of tea alone, a walk in the park, writing daily diaries or blogs, or even a quiet five minutes at the end of the day could make all the difference where we may ask Q’s to ourselves, like -

·  Did I use my time wisely today?

·  Could I be a person other can respect?

·  Did I make a positive impact today?

·  Did I respect myself and valued my strengths today? ….

Such introspective Q’s can be really helpful and can potentially provoke us to think - whether I am progressing steadily in the line of my end vision, or just ‘being busy’.

Peter Drucker says:  

“Follow effective action with quiet reflection. From the quiet reflection, will come even more effective action.”  

In my personal experience, I have found that -

·  Solitude allows you to reboot your brain and unwind!

·  It’s always healthy to disconnect, unplug discover yourself, and find your own voice!

·  You will have better ways of solving problems and may get unexpected flashes of creative insight.

So, I urge, go ahead and schedule some ‘time alone’ for you, where its only your and with you.

And please do comment, if you have ever experienced the effectiveness of doing such self-reflection, and if my own reflections about ‘self-reflection’ is reflecting right :)?

Happy Reading! 

-Deba ... ( Debajit Kataki)

Database CICD

DevOps is all about inclusiveness.  In one of my earlier posts,  I shared why this is important!

I don’t think many organisations or application teams practices CICD or even version their SQL codes as a best practice while dealing with Database changes. 

As we go to AWS or any other cloud platform, the code deployments will be completely CICD driven, i.e. code releases will be at the developer's will. Hence, the complementing DB changes should be part of the pipeline / release candidate itself, and we should NOT look at the DB changes and code changes as two separate entities -  to get the full benefit of CICD in our quest for  'Speed-As-Habit'.

The database SQL's, unlike other software components is not often versioned. Thus, Continuous Integration (CI)  & Delivery ( CD )  for databases has taken a back seat to automated deployments, leaving database automation  play a catch up game.

If you have a full-fledged release program mgt. team managing and co-ordinating these changes manually, I think you really need to anticipate the world ahead. 

Consider these AWS or any other cloud scenarios:

•       AWS application deployments will be completely CICD driven.  

•       AWS way of doing deployments expects everything in an automated fashion Code/ IaC etc. 

•       Manual /synchronisation between DB and App teams will be very painstaking as - CI for code will be at the developers will and hence the releases (mostly!)

•       Hence, the SQL queries should also be part of the release / deployment automation. 

Introducing Versioning of SQL:

Version or source-controlling database changes is the first step in introducing databases to the DevOps / CICD  process. If your database changes and application code are in source control ( e.g. GitHub ), you can have a working build anytime, because you will always have a version to roll back to, and you will also have audit trail. 

There are many branching strategies you may adopt to suit your development process while introducing a new SQL repo,  which is part of your same development  stream.

This is the foundation to bring a transparent audit / approval / feedback mechanism in a true DevOps culture.

Proposing a new process:

A process somewhat similar to the below can ensure that - the database changes which is versioned in GitHub,  will get reviewed by the DBA’s even before the branch merge. The depicted automation ensures that the CI gets triggered only when the merge happens.  This not only helps in early review but also brings the real skin of our DBA’s in the game and ensures that the accountability and ownership get fairly distributed across the right stake-holders. 

As a best practice you can create a pool of 2 engineers each from DBA's and Developers to facilitate  the code review and subsequent PR approvals. 

Introducing CICD:

Below could be a ‘Big-Picture’ ,  binding all the components together.

Introducing Flyway DB:

FlywayDB is an Apache v2 licensed open-source tool that makes database migrations easy. You can think of Flyway as version control for your database.It integrates wonderfully with Maven.  It supports a very wide range of databases.  In the above diagram you can see that Spinnaker triggers triggers the FlywayDB instance to manage the changes. 

I highly recommend you read more about this tool in the below link –

https://flywaydb.org/getstarted/how

  

Now when subsequent changes comes , this is how FlywayDB ensures that the changes are safe.

The only overhead is that - FlywayDB maintains a small Schema version table with each of your databases. 

This may be a quick small approach towards integrating database changes as part of your DevOps process, which can accelerate the delivery of database changes and promote agility across the entire code-release cycle. I am sure based on the tools and your own IT landscape,  this might vary slightly. 

Happy to get your thoughts around this and discuss further. 

However one thing is for sure  - failure to include database changes as part of the DevOps /CICD practice will certainly slow down your release cycle!

DevOps Vs SRE

Let’s start with very crisp definitions...

What is DevOps?

DevOps is a software engineering culture and practice, that aims at unifying software development and software operation.

What is SRE?

Site reliability engineering ( SRE )  seeks to improve the reliability of currently operating software, while minimising the work involved in its upkeep through various automations. 

** 'Traditional Ops' were more focussed on how effectively ( and efficiently! ) execute the day to day tasks. 

How are they different  (Or)  Do they have any common ground ? 

Google states that SRE and DevOps are not so different from one another: “They’re not two competing methods of software development and operations, but rather close friends designed to break down organisational silos.

Both these schools highly advocates automation and collaboration - thats what in common! 

Then how are they different ?

While DevOps is all about “What” needs to be done ( e.g. Cultural change , Need of Automation, Need of Measurement, need of Sharing i.e. CAMS )  ;  SRE talks about “How” this can be done. It’s about expanding the theoretical part to an efficient workflow, with right work methods, tools and so on.

DevOps engineers are responsible for executing the 'Development Automation' or 'Developers Productivity'  vision from the very beginning of the SDLC  via Agile and CICD practices. DevOps  also preaches infrastructure as code ( IaC ) automation. 

Hence , It is expected that a DevOps engineer understands the full SDLC and also has the hands-on skills  to implement changes, or has the ability to administer it end-to-end. There are many DevOps specific tools which focusses on this segment of 'Developers productivity'. 

On the other hand, SRE's  main job is to ensure that the site (i.e. “platform/service”) is always operational,  and reliable with the right tool, process and metrics.

SRE engineers are very  focused on writing codes to automate processes and eliminate toil. Now this can only happen when you help envision or raise a very fundamental question  -  'what does your developers think should change,  if they were to do the Ops'.  

 The following analogies might be able to bring more clarity and insight!

While SRE implementation may vary from organisation to organisation, there is a DevOps Checklist portal in the internet - which you may find very useful : The DevOps Checklist

Hope this article was helpful :)

Thanks ,

-Deba