DevOps Explained

DevOps is a movement, a state of mind, way of thinking. It will solve some problems and it can even save you money, but DevOps will not be the one change that fixes everything.

What is DevOps

Before we can understand some of the DevOps concepts and implementations we should first identify some key motivations for why we are interested in the subject, what it could mean for us and our work.

• Rapid service delivery through automation and simplicity.
• Better communication and cooperation.
• Reduced failure rate and faster recovery.
• Less time troubleshooting, more time innovating or learning.
• Clear proven processes.

In your study of DevOps there will be many explanations as to how, where, and why Automation, Testing, CI and CD make up various parts of a DevOps implementation.

The success of DevOps adoption into any business will be greatly increased if the right culture is set and people are motivated to work in cooperation to achieve succinct DevOps.

Culture and people are more important than process for DevOps success

DevOps has been highly debated and for all the benefits it can yield there are many themes and techniques to consider. In almost all cases of DevOps implementations there 6 main focus points consistent with the
main methodology of the movement.

1. Collaboration, and Communication.
2. Automation, as well as autonomous developers.
3. Continuous integration.
4. Continuous testing.
5. Continuous delivery.
6. Continuous monitoring.

History

DevOps, the combination of the 2 words Development and Operations, can be traced back to debates in a Google Group called “Agile Systems Administrators”. The group was created by Patrick Debois and Andrew Clay Shafer in 2008 after their meeting at a meetup for Agile Infrastructure for which Shafer had organised and Debois was the sole attendee.

Amazing what passionate and driven people can accomplish. Shafer; a self-proclaimed hacker, and a modest freelancer Debois, were brought together by their vision and went on to start a movement we know as DevOps.

One of the earliest events celebrating the name DevOps was in 2009 when John Allspaw (Yahoo, Flickr) presented “ 10 deploys per day” at the Velocity conference, and also at velocity Paul Hammond (formerly of Flickr) talked about scaling Typekit.

Between the time of Velocity and what we now refer to as “The perfect storm” of late 2010, there were several talks around the world, and software released all in the name of DevOps. What started to become common where the myths about DevOps, for which many debates arose. One certainty was that DevOps is not a job, a skill, or spec - but rather a set of values and methodologies to achieve success.

Today we can look at Amazon founder Jeff Bezos, whom many believe as the greatest example of a tech influencer of narrow-minded sheer determination to deliver services and products in such a way that the process for which it is achieved is without exception pure DevOps.

The People

As a team leader, manager, or team member within a business adopting DevOps, there are some key
personal developments to consider for each and every person involved.

• For successful adoption the right culture is required.
• All employees and implementers alike are required to be motivated for change.
• Individual teams are expected, and absolutely required to cooperate and communicate well. This is core.
• There should be one single minded goal; Succinct rapid service delivery.

Some things to expect when a business migrates to, or restructures towards DevOps methodologies;

• Developers understand the full impact of their code hitting production and are accountable.
• Operations are comfortable and prepared for the developer’s need to deploy rapidly.
• Infrastructure and development processes will change to remove all central points of failure.
• Work that is considered “on the tools” will be reduced for all team members and replaced with process.
• Everyone will have his/her own approach or solution, plan to have a clear decision making process in advance.

Business Motivations

Whether you’re planning to move hardware offsite, to the cloud, or use existing infrastructure there will need to
be business considerations in terms of security, IP, data, regulatory, and costs.

When planning for DevOps adoption;

Investigate similar business case studies or published materials outlining their experiences.
These will identify any caveats that may apply and give incentives that may be argued for.

Quantify your current risk by comparing current process to DevOps methodologies. Any of your KPIs may help here, as they were defined with deliverables that may be disrupted.

All single points of failure are a risk. Persistent data, replication, backup, networking, ect. Devise the components of your software, service, and products so that they are modular. Decouple data and expose it openly through external APIs.

Developers write code to consume APIs, never allow business logic to directly access data or services.
Design all environments, deployments, ect to be terminated as an expectation, nothing lost is ever lost.

No asset or configuration should exist in source code, question everything! Few exceptions exist.

question everything

Do all you can to enable you to move as many if not all of the components to cloud services. Cloud services are designed and priced for specific processes. They are configurable and modular, allowing new services/projects to slot in with little more than a config. Complexity is reduced though reliability, scalability, and compatibility are all improved for you.

Choose monitoring tools that will identify risks in real-time. If you use services such as Pingdom already you can use them for much more than just identifying availability, you can use services like this for testing APIs at no extra cost.

Cover all identified risks and anything that will affect KPIs. Test all automated services, not just the expected outcomes of their purpose.

DevOps encourages quality code to be checked in to VCS, the developer will be able to immediately identify any faults with their new code which ensures that these faults are eliminated with a fresh understanding and rapid turn around. In waterfall these faults could have been left unknown for a time as the integrations and deployments would have previously been done by operations usually days or weeks later. That process left the operations with accountability and the developers were ignorant to their own accountability.

Operations now need to open the infrastructure to developers via APIs or configurations so that the perspective is that no hardware or networking exists and it is all just represented in “code”. Open monitoring, and open communication channels allows these teams to work autonomously with the business and each other but also without the need of conflict/crisis management.

Further reading

An interesting visualisation of DevOps tools;
https://xebialabs.com/periodic-table-of-devops-tools

Alternatively they are all listed here;
https://xebialabs.com/the-ultimate-devops-tool-chest/

A deep and detailed glossary of DevOps;
https://xebialabs.com/glossary/

Other Case studies;
http://aws.amazon.com/solutions/case-studies/artsy/
http://newrelic.com/resources/case-studies

Notable people in DevOps

@allspaw
John Allspaw
SVP Tech Operations at Etsy

@jezhumble
Jez Humble
Principal at Thoughtworks

@patrickdebois
Patrick Debois
Founder of DevOps, amongst other achievements

@xamat
Xavier Amatriain
Director at Netflix

Enjoyed this?

If you made it here I would love to hear what you thought of the article.

Tweet to @chrisdlangton