Talk Title : DevOps Not A Tool Box


This talk will bring us back to basics and explain the core build building blocks of DevOps. With so many tools in the market it sometimes becomes over whelming for any one who is headed for a digital transformation. I will explain what is the essence of DevOps and that it is much more than just some tools and platforms. It's beyond tools and techs. This talk will also help beginners to understand that just learning some tools does not make the DevOps engineers , it's about adopting the DevOps mindset.

Transcript Goes As Below

Slide 1:


Hello Everyone,

I am Kamalika . I am a Consultant and Cloudkata is my services brand.

And topic of my talk is to explain why DevOps is not a Toolbox.

Over last couple of years every time I visit a client for DevOps enablement people ask me various questions regarding DevOps and over past few years I observed a common pattern in most of them.

Slide 2:

My talk today is to answer some of the frequently asked questions that I keep hearing as I meet people during my various consulting engagements, the gist of which are : The one thing that is common is focus on tools and that is why my talk today says “DevOps is Not A Toolbox” and I will try to explain why and what is it actually. But before I go there lets revisit the history and take a quick look at where it all started.

Slide 3:

Before I answer these questions lets take a quick look at the history of where it all started. So the story goes like that:

Reference (


Belgian consultant, project manager and agile practitioner Patrick Debois took on an assignment with a Belgian government ministry to help with data center migrations. In particular, his role was in certification/readiness testing. His duties required him to straddle activities and relationships between the application development teams and the operations teams (server, database network). His experiences—and frustrations over the walls of separation and lack of cohesion between application methods and infrastructure methods—planted seeds of discontent for Debois. His desire for a better way would soon lead him to action.

In 2008, at the Agile Conference in Toronto, Andrew Schafer posted an offer to moderate an ad hoc “Birds of a Feather” meeting to discuss the topic of “Agile Infrastructure.” Only one person showed up to discuss the topic: Patrick Debois. Their discussions and sharing of ideas with others advanced the concept of “agile systems administration.” In that same year, Debois and Shafer formed an Agile Systems Administrator group on Google, with limited success


At the O’Reilly Velocity Conference, two Flickr employees—John Allspaw, senior vice president of technical operations, and Paul Hammond, director of engineering—gave a now-famous presentation titled, “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The presentation had a dramatic flair to it, as Allspaw and Hammond would role-play the contentious interplay between representatives of Development and Operations during a typical software deployment, along with all the finger-pointing/blame that goes on, such as, “It’s not my code, it’s your machines!” Their presentation made the case that the only rational way forward is for application development and operations activities to be seamless, transparent and fully integrated. Over time, this presentation has reached legendary status, and is historically viewed as the seminal moment in time for that called out to the IT industry for methods that we now know as DevOps.

Unable to attend in person, Debois watched the Allspaw/Hammond presentation by video stream. He was inspired, and—at the prompting of others through social media—formed his own conference called Devopsdays in Ghent, Belgium.

Slide 4:

And here we are soon to mark the 10th Anniversary of DevOps Day and the what is see is this. Oh yes now I get your attention. I am sure each one of you are like I have it that one and that one oh and that one too. Yes ! I am DevOps. But are we. Let's see.

Slide 5:

How many of you still have to face this. Almost all right. So what we achieved was this “Image plays in “ , Before DevOps “It works on my machine” after “It works on my tool” . So nothing really changed has it ? Why is that so ? We have so many tools now. We should have at least fixed this issue in 10 years right.

Because tools wont fix it unless you have configured it. You need configuration management , code that is modular and platform agnostic. So it does not matter whether you are in AWS or Azure or GCP you are just deploying you artifact . Next we need proper quality analysis and end to end testing. And last but not the list “last point plays in ” . This is an advice given by one of my ex colleagues, he made me realise that there are n no. of tools, code, configurations that we will develop in our journey , it will be used by others, sometimes refactored , enhanced and eventually might even get repacked. So there is no point in being protective about your code.

Slide 6:

Another important factor to make success is the “Skill-Will Matrix”. No matter how much skill you have if you do not have the right attitude the it won’t be success. (Slide Text plays in)

One of my seniors use to say “There can be 50 reasons to do it and 50000 more to not do” ). It's a Skill Will Win. It's a never ending learning path.

Slide 7:

And here come the most common and classic issue. Pre devOps it was a network issue and post DevOps its a DevOps issue.

(Text plays in)

Occasional blame game leading to teams getting divided based on tools being used. So what has happened is (Slide 8 plays in)

Slide 8

PreDevOps we were here

Slide 9:

We thought we will get there post DevOps, but

Slide 10

Reality is this.

Slide 11:

(Images plays in)

If you have a DevOps team and you think you are DevOps enabled , stop right there. We are hit by the phenomenon here. Instead of forming a team build a community. DevOps is a mindset not role. And that is why I say that it's not a toolbox.

Slide 12:

It's a Culture, the way you think , act and interact towards solving crucial engineering issues. (Image plays in)

It's about how you change your thinking , adjust to the new mind shift, and transform and transition into a better engineer.

And to simplify it more I believe its a continuous process of “Automate, Integrate, Communicate, Collaborate and Iterate"

Slide 13:

And it's a wrap. If you have any thoughts , feedback or wanna discuss about the DevOps state, it can write to be at

Thank you All.

Get Interesting News!

 Subscribe to our mailing list & get first-hand updates on our blog posts, articles & casestudies.

Copyright 2020 Cloudkata®


Incorporated By Staxa LLP  

Located at #108, 27th Main, Sector 2, HSR Layout, Bangalore - 560102, Karnataka, India

  • Facebook Social Icon
  • Twitter Social Icon
  • LinkedIn Social Icon
  • RSS Social Icon