Using DevOps Tools in Reality

Roman Pavlyuk is a Solution Service Product Manager, Enterprise Technology, at SoftServe Inc., and a regular blogger on the SoftServe United blog. Roman has over 10 years of experience implementing operations practices for major IT deployments. He has profound experience in integration of ITIL practices, open source, Agile, and SaaS operations automation, system design and analysis, as well as all aspects of operationalizing SLAs for SaaS providers. 

Let’s get an answer to the question Why are we doing DevOps? before we start talking about tools. By now, we should all understand the main goal of getting DevOps in place is to establish better collaboration between development and operation organizations. And again, the question is: why do we need that collaboration so much? The answer is simple and obvious – we are looking for better Operational Efficiency that results in making shorter product deployment times, significant decreases in manual overhead, centralized environment management and orchestration and extended self-service capabilities for development teams. The last one is very important since it brings value to DevOps by itself: developers finally get convenient mechanisms to get and use computing resources to be used during product engineering. So request like “Hey, Mr. Ops, please prepare an X-type environment so I can test my new features!” is being replaced with “Where is that button that creates environment X…”

Now, knowing our goals let’s talk about the tools. What tools and techniques would I use? If my primary goal is to establish continuous and fast delivery process then I’m going to focus on the toolset that provides repeatable execution of predefined automation scenarios. For example, Puppet by PuppetLabs is good for that as well as Chef by OpsCode. If the ultimate goal is to significantly decrease manual overhead then any automation tool will work fine here. It can be either open source (Puppet, Ansible, Chef, cfEngine) or commercial (for example, BMC’s Bladelogic product family). It is your choice which one to use and there’s no single page manual to how to make it.

Generally, please note the following whenever you are going to deploy DevOps tools:

• DevOps is not about using some tool, let’s say Puppet. DevOps is about setting up an effective service operation process and most likely you’ll require some tools for that.
• There’s enormous amount of options available right now on a market. All of them are feature reach so once you’ve found the features you need (let’s say the tools perfectly works with Azure resources) then you’re good to go.
• The things I would recommend to focus on are:
  • How fast will you be able to learn the tool and place it in production?
  • Does it have a functional community edition(s) so you can try it instead of buying it right-away?
  • Do you have engineers that are familiar with the technology the tool is built on so you can write additional plugins and modules once you need them?

So, the direction of the DevOps tool and its functionality depends on the main goals of business, technology or even management to make it fully-beneficial for your “reality”.