devopsy.kinsta.cloud

Tag: devops foundation

  • DevOps: Using Games to Make it Practical

    DevOps: Using Games to Make it Practical

    This blog stems from my experience of being one of the earliest DevOps Foundation trainers of DOI and successfully completing 19 batches of DOI Foundation course in the last year.

    In retrospect of the year starting when TaUB Solutions signed up as a registered education partner (REP) of DOI, my opinion is this has been the best service portfolio offering for our customers and partners.

    There are few things that appeal best when it comes to DOI Foundation course and I can summarize them with the collective feedback I’ve received so far:

    “Challenges the preconceived myths and practices around DevOps with practitioner stories.”

    “Gives a holistic overview of philosophy behind DevOps. Philosophy should precede science and science should precede engineering.”

    “This course maintains the discipline to be truly advisory in nature by illustrating tool chain without recommending vendor-specific tools.”

    “The group exercises during the class and the facilitator practical insights helped us to put the aspects in to our organizational context of delivering products and services.”

    “We have never seen a course such beautifully designed that could be the first basic building block to know ‘Do’s’ and ‘Don’t’s’ of DevOps across application developers, infrastructure operations, project managers, infosec professionals and business leaders.”

    To enhance the overall learning curve of the audience, we put them in to the third day of experiential learning using the Phoenix Project Business simulation. The simulation was divided into four rounds and played with maximum of 12 people per batch. The Team was entrusted to achieve a target of $300,000 within four rounds and take the share value from $21 to $45.

    While the target milestones were clearly laid down at the beginning of game it was difficult for the teams to get hold of the situation due to various unknown parameters. It took them quite sometime to understand the different moving parts of flow, dependencies, business impact of projects, issues and features that came up in every round and make  appropriate choices and decisions.

    The teams experienced significant learning, sharing and collaboration over the four rounds and had loads of fun. One common feedback from the teams was for the game to be mandatory after every two-day DevOps Foundation course.

    The consolidated feedback after playing the DevOps business simulation after the two-day course:

    “It demonstrated that it is not easy to build collaboration, communication and integration. It takes time and there is a lot of patience and team work needed to make this a reality. The DevOps culture had to be nurtured through self-organizing teams with mutual respect, sense of pride and collective ownership to work toward a common goal.”

    “It gave a working knowledge on how ITSM and DevOps are complementing each other [Ex. Change Management and Improved Flow].”

    “The Principles of DevOps, namely the First Way (Improve Flow from left to Right), Second Way (Shorten Feedback Loops) and Third Way (Repetition through Mastery) was visibly evident over the course of four rounds.”

    “The speed of execution improved over the rounds using short feedback loops, continual improvement and applying lessons learned from previous rounds.”

    “It gave a good understanding of how different roles and responsibilities in the organization contribute to the overall success of the project.”

    Finally, the teams made over and above the required target of revenue and stock price. The winning moment was enhanced by the significant learning opportunity and ability to bond with diversified cross functional teams.

    The experience of playing the business simulation reinforced practical understanding of DevOps and also transferred skills that they could implement immediately at their workplace.

    About the Author / Suresh GP

    sureshSuresh GP is the Managing Director of TaUB solutions and Regional leader of BRMI (APAC). He has more than 15 years of experience in IT Service Management, IT Governance, Program Management and Organizational Change Management. He is regular blogger and International speaker at itSMF UK, itSMF Australia, itSMF USA, itSMF Finland and itSMF Norway. He is a Certified DevOps, Agile Service Manager, Business Relationship Management Professional, PMP, CGEIT, ITIL V2 Service Manager, ITIL V3 Expert,  ISO 20000 practitioner. He was awarded the ITSM contributor of the year by itSMF Singapore in 2013.

  • Why I became DevOps Certified

    Why I became DevOps Certified

    I usually do not care too much about diplomas or certifications. To me, one’s value isn’t reflected by a piece of paper but rather by his or her actions, dedication, motivation and efficiency. And yet, I decided to become DevOps certified and furthermore, become a teacher for that very same certification. Have I gone insane or did I make a choice based on reasons that could appeal to you? Read further to find out.

    Set up a standard.

    I have been advocating DevOps for years now, reading everything I could about it when it was just a fun word created by Debois and recently writing quite a lot and giving conferences about it too. One thing that always strike me is that, no matter the context, no matter the experience of the people I’m speaking to, there is always one person asking me: “but can you tell me what exactly is DevOps?”.

    DevOps strength is also its weakness. By not defining a manifesto, a chart of good conduct or even a clear definition, DevOps leaves room for improvement over time but also creates what it tries to break down: silos. By being so undefined, you end with people “in the know” and the others who are desperately trying to get a grasp of an idea that’s clear to many.

    A certification, while arguable, brings exactly that level of standardisation we needed. By enabling me to have a clear definition of what DevOps is, it gives me the opportunity to spread it further but not only that, I also finally talk about the same thing as others around the globe. Gone are the days where you would see a new definition a minute, now that we all know – and agree on – what we are talking about, we can finally start to actually do it.

    I could have stopped here, taking the certification, being all knowledgeable about that topic but it would have been a bit against DevOps’ philosophy. Sharing is caring and if I get people to understand at least the basics of I what I preach, then we understand each other better and I make others better at their job (hopefully). And that’s exactly why I became a teacher: to spread the word and get people who don’t know to finally know. People over everything else, right?

    The DevOps Institute.

    Ok this part will sound a bit like a commercial but I’m just going to explain the reasoning behind my decision to go with that one.

    There are many certifications about the topic popping up these days so it was not necessarily an easy decision to make. After all, since we are still discussing whether or not to have a certification on that specific field, nobody was more legitimate than another. And then I read this article by our dear Alan Shimel: here.

    The fact that his name was associated with a certification intrigued me and I went to check it out. Then I realized that names I was already familiar with were also a part the institute (Lisa Schwartz and Jayne Groll) which made me think I was actually facing serious people.

    I read a bit more about them and discovered that both Gene Kim and Sanjeev Sharma, two persons I highly respect and read a lot from, were part of the institute’s board.

    That was it! It all went super-fast after I took contact with the institute. I filled up the usual forms and in no time, I was in the program, training myself to become the trainer, reading even more about DevOps, learning some new things and exchanging with brilliant minds before taking the final exam.

    What it all means

    While it won’t change your life, those of you who wanted to become unicorns still have to buy a costume for that, becoming a certification trainer gives you the opportunity to meet and help people who want to know more. Whether or not they take the actual test does not really matter. What matters is that you hold the same speech as others around the world and that people who come to you with questions might leave with a bit better understanding of what it is that you talk about.

    Before comments rain down on me, telling me that this is heresy and that I should be condemned to watch Nyan cats for 48 hours non-stop, I just want to precise that I do not have any interest in anything other than my job. I am just advocating for a certification and explaining why I took this one more than another.

     

  • An Introduction to DevOps

    An Introduction to DevOps

    What is DevOps

    You can ask 10 people for a definition of DevOps and likely get 10 different answers.

    If you want to find a definition of your own, your research will probably begin by asking Google, “what is DevOps”. Naturally, Wikipedia is one of the first result so that is where we will begin. The first sentence on Wikipedia defines DevOps as “a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals.” Well, that’s a fairly dense definition, yet still pretty vague. I think DevOps can be explained simply as operations working together with engineers to get things done faster in an automated and repeatable way.

    So let’s delve into how DevOps works and can better adjoin two traditionally opposing departments.

    Growing pains

    When you are responsible for large distributed applications the operations complexity grows quickly.

    • How do you provision virtual machines?

    • How do you configure network devices and servers?

    • How do you deploy applications?

    • How do you collect and aggregate logs?

    • How do you monitor services?

    • How do you monitor network performance?

    • How do you monitor application performance?

    • How do you alert and remediate when there are problems?

    Combining the power of developers and operations

    The focus on the developer/operations collaboration enables a new approach to managing the complexity of real world operations. I believe the operations complexity breaks down into a few main categories: infrastructure automation, configuration management, deployment automation, log management, performance management, and monitoring. Below are some tools I have used to help solve these tasks.

    Infrastructure Automation

    You no longer have to build a server from scratch, buy power and connectivity in a data center, and manually plug a machine into the network. After wearing the operations hat for a few years I have learned many operations tasks are mundane, manual, and often have to be done at two in the morning once something has gone wrong. DevOps is predicated on the idea that all elements of technology infrastructure can be controlled through code. With the rise of the cloud it can all be done in real-time via a web service. Infrastructure automation solves the problem of having to be physically present in a data center to provision hardware and make network changes. The benefits of using cloud services is that costs scale linearly with demand and you can provision automatically as needed without having to pay for hardware up front.

    Configuration Management

    Configuration management solves the problem of having to manually install and configure packages once the hardware is in place. The benefit of using configuration automation solutions is that servers are deployed exactly the same way every time. If you need to make a change across ten thousand servers you only need to make the change in one place.

    There are other vendor-specific DevOps tools as well:

    In the operations environments I have worked in there were always strict controls on who could access production environments, who could make changes, when changes could be made, who could physically touch hardware, and who could access what data centers. In these highly regulated and process oriented enterprises the thought of blurring the lines between development and operations seems like a non-starter. There is so much process and tradition standing in the way of using a DevOps approach that it seems nearly impossible. From an operational perspective, my first instinct is to understand the application architecture so I can start thinking about the proper deployment model for the infrastructure components. From a development perspective, my first milestone is to make sure the ops team fully understands the application and what it takes to deploy it to a pre-production environment.

    DevOps isn’t just a set of tools, but a philosophical shift that needs that requires buy-in from all folks involved to truly succeed. It’s only through a high-level of collaboration that things will change for the better.