Introduction to DevOps Culture and DevOps Tools

Today, every organization depends on software. Retail, logistics, government, scientific research, tech, education, financial services — every sector needs some sort of software to meet customer and user needs. The expectations people have of software have changed dramatically over the last decade: They expect reliable and convenient services that are regularly improved. The complexity of our computing infrastructure increases continually, as does the pressure to deliver more software, more frequently, and at higher standards of quality.

The normal way of delivering software in organizations has been failing, because team’s incentives just haven’t been aligned. One side, developers are incentivized solely to deliver new features; their responsibility ends as soon as the software is handed to the operations teams to deploy. And the other side, the Operations teams have been incentivized to keep infrastructure as stable as possible; their responsibility for software delivery starts only once they’ve been handed the software to deploy. (And of course, operations normally has plenty of responsibilities in addition to deploying software, including managing costs, user accounts and overall capacity, plus ensuring overall security.)

The incentives of these two groups are fundamentally opposed. And the problem can’t be fixed by traditional management practices, it has to be done by technical practices.

There are two main ideas that lead Operational teams to use DevOps practices:

1. Ideas of Treating Infrastructure as Software

By treating Infrastructure as software, we could take advantage of everything we’ve learned in the software engineering field over the last couple of decades — for example, the value of version control, branching strategies, and code review. Increasing prevalence of simpler and easier-to-use APIs (such as the widespread adoption of RESTful APIs) made it easier for non-developers to use them, which resulted in a wider group of people within the operations field being able to do development as opposed to scripting. This pushed more operations people into learning basic software engineering practices.

2. Agile Infrastructure

The Wider DevOps communities started generating more reusable content they could share, which naturally started exposing more and more sysadmins to current thinking around software development practices. The growing popularity of agile methodologies resulted in more releases, putting, even more, pressure on operations teams, and making it more urgent to improve how they managed infrastructure.

Do I need to acquire skills of Software Programmer to become a DevOps Engineer?

There is a common misunderstanding we see regularly. If you work in operations, “doing DevOps” and making use of these techniques doesn’t mean you need to pick up all the programming skills of a senior software developer.

We’ve always done development in operations, whether it be shell script snippets, useful shell aliases or batch files. It just wasn’t expected that we absorb the principles of software engineering and delivery, and we didn’t think about it as development.

You don’t need to become a professional full-time software developer to “do DevOps” as an operations person — you just need to understand basic software practices like version control, peer review, releases and testing, and have sufficient facility with high-level programming languages and frameworks to get the job done.

If your team following three practices, you are already doing DevOps.

1. Automation

Automation ( Service Automation / Network Automation / Configuration Automation ) and self-service infrastructure allow you to minimize cycle time, as individuals can not only rely upon predictable automated outcomes but also, with the addition of self-service, those individuals and their teams can run at their own cadence and avoid external bottlenecks. This allows for faster experimentation and more agility to handle changes in direction, as well as increased reliability and quality.

2. Measurement

As the saying goes, you can’t improve what you don’t measure, and this is, if anything, even truer when you’re talking about using DevOps to improve the whole software delivery lifecycle.

3. Sharing

Sharing between teams is a key tenet of DevOps. Tools shape people’s thinking, and so when people use very different tools, they often think very differently. A shared toolset can go a long way towards helping people understand each other more quickly, and this empathy helps across all the interactions people have with each other within a company. Eighty percent of what a sysadmin does every day is the same or similar to what other sysadmins do for 80 percent of their day, so why not share the code that automates it? Especially when the data that’s specific to each workplace has been abstracted away from the operations code.

So, what are the tools and technologies that a typical DevOps engineer regulary use in his job?

There are several popular tools in the market, and below is short list of vendors who provided various devops tools.

List of Vendors for DevOps Tools

  • Ansible – ( What is Ansible ? )
  • Clarive Software (Know about Clarive)
  • Docker ( What is Docker ? )
  • Puppet Lab ( What is puppet labs ? )
  • Inedo
  • ScriptRock
  • Amazon Web Services (AWS)
  • CoreOS
  • Chef
  • SaltStack
  • Atlassian
  • TaskTop
  • Codenvy
  • SmartBear
  • CA Technologies
  • ServiceNow
  • CF Engine
  • Cisco
  • CollabNet
  • DBmaestro
  • HP
  • Microsoft
  • Rackspace
  • Rally
  • Redhat
  • Spirent
  • Splunk
  • VersionOne
  • VMware
  • XebiaLabs
  • MidVision
  • Inaka
  • CakeSolutions
  • GitHub

We will be discussing each of these tools in our upcoming series of DevOps Knowledge Articles. If you haven’t yet subscribed our Daily Dose of DevOps Skills, you can still subscribe it here

 

Ramdev

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

You may also like...

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us

What is your Learning Goal for Next Six Months ? Talk to us