In recent years DevOps has moved from an innovative idea to a mainstream approach. But despite how often it is talked about, advocated, and celebrated, the basic question: ‘What is DevOps?’ is common – either out loud by the innocent or internally by those who feel they should know the answer but aren’t quite sure.
Actually, it’s OK to be not quite sure, because there is no single agreed DevOps definition.
At heart, DevOps is the need for a set of consistent practices that help organizations build, deliver, and maintain software and IT services better, quicker, and make them more reliable.
As the name suggests, one of the key ways DevOps does this is by taking Development (taking ideas and requested changes and building them) and Operations (making them work and keeping them working) and putting them together, so they work as one.
So, what is dev ops? Dev and ops together become DevOps, and silos with different goals become one team with a shared goal – better services, quicker.
What Does DevOps Stand For?
For many organizations, DevOps is about speed of deployment: getting the right thing out there quickly.
Ultimately it isn’t about how they achieve that, but the DevOps philosophy has demonstrated mechanisms that have delivered that increase in speed and accuracy, and this collection of techniques, culture, and technology is what DevOps has come to stand for.
Although there isn’t a single definition to precisely answer the ‘What is DevOps?’ question, there are accepted elements that set out what DevOps means:
- A reliance on technology, particularly automated testing to support rapid – and often automated – deployment and release. DevOps certainly isn’t just about technology, but it will not work without it.
- Human factors – bringing together wide-ranging teams and trusting those teams to make decisions about the products they are responsible for, and then for implementing those decisions. Trust and ownership are as essential as the technology. Breaking down organizational silos is a key requirement for success.
- Measurement – by measuring performance, focus on relevant improvements can be made more easily.
- Use of appropriate tools, techniques, and best practice. DevOps does not seek to invent new practices but to make the best use of existing ones, such as Agile, ITIL, Lean, and more.
- Collaboration and communication – helping people work together and not duplicate efforts, through relevant (brief) meetings, sharing information via wikis and message boards, and more.
- And – most importantly – customer focus. Doing the right things over doing things right.
DevOps is about both technology and culture: getting the best from both means thinking about them together. It needs the right technology, and staff who can use it well, and are empowered to use it.
History
According to the Wiki, the term DevOps is attributed to Patrick Debois, a Belgian IT professional. He coined the term around 2009.
Debois and Andrew Schafer, following discussions at a Toronto conference, formed ideas and then a virtual group on ‘Agile Systems Administration,’ which can be seen as the birth of DevOps philosophies.
The original term ‘DevOps Days’ was given to events to discuss this wider application of Agile, the ‘days’ term being dropped to give us the simpler ‘DevOps’ name we have today.
The conferences discussing the concept grew – in size, frequency, and geographical scope to deliver an ever-expanding worldwide community of support for the ideas behind DevOps.
A significant mechanism in the spread of DevOps history has been the novel “The Phoenix Project” by Gene Kim, Kevin Behr, and George Spafford.
Widely seen as a good starting point for those wanting to understand the principles behind DevOps and the culture required to facilitate it.
It was published in 2013 and remains an excellent entry for those wishing to get a feel for the culture behind DevOps. It suits anyone wishing a gentler introduction than a typical management book.
In recent years DevOps has seen considerable acceptance, so much that it is no longer seen as an innovation in many sectors, but the accepted approach, with take-up across many sectors and in all parts of the world.
Principles, Methodology and Infrastructure
DevOps Principles
“Principles” can be defined as ‘fundamental propositions that serve as the foundation for a system of behavior or for a chain of reasoning.’ If we see DevOps as a system of behavior, then typical principles would include:
- Learning and collaboration – staff should share knowledge and experience as widely as possible and always seek to learn from others.
- Support for innovation, experimentation, and the agile methodology.
- Automation – where tasks can be automated, they should be.
- Feedback – feedback loops should be short as possible, and feedback should be from a broad, organization-wide base. And feedback should be acted upon.
- Holistic, whole system focus. DevOps staff engage early and often with customers. Development, test, and deployment are either dealt with by a single team, or teams collaborate to deliver shared goals, targets, and measures.
These behaviors might be expressed in different terms but are fundamental to a DevOps approach.
DevOps Concepts
Philosophies and frameworks require discussion and debate to progress.
Meaningful conversations depend on sufficient shared vocabulary and a shared understanding of the key concepts.
This is certainly true for DevOps, and those key concepts include existing approaches that contribute to DevOps.
Following the rule of ‘don’t invent what’s already there and working,’ many key DevOps concepts have been imported.
Widely used concepts within DevOps include:
Agile – based on the agile manifesto, most DevOps organizations use the Agile methodology to some degree
Continuous Integration (CI) – a software technique whereby new code is incorporated into a central repository (at least) daily – so a single master exists, reducing compatibility issues and conflicts. And CI should give very rapid feedback to developers on the acceptability/integration of their work. (Supporting the rapid feedback principle)
Continuous Delivery/Continuous Deployment. These are steps in the automation of releases of updated software. Continuous Delivery means that software is always in a state where it could be deployed. Continuous deployment, logically enough, takes it one step further and deploys the updated software to the production environment. Be aware though; you will find variations on these definitions, which reflects the fact that DevOps is not – nor is it meant to be – an exact, precise set of rules and definitions.
Shift Left. Simply put, this involves dealing with all aspects of a system as early in its life as possible. It is always easier, quicker, and cheaper to fix something at the design stage than after you have built it. This applies to software, services, boats, planes, and most everything else – even interactions and relationships! It matters in DevOps because shift left helps delivers speed as well as financial savings.
The Three Ways. These three maxims appeared in the Phoenix Project and have been incorporated as the basis for many interpretations of DevOps. They appear initially in the book as a somewhat Zen element and reinforce that DevOps is, at heart, a philosophy – not a set of rules. However, the three ways are based on sound engineering practice going back thousands of years, and they can be succinctly expressed as:
- First Way: Systems thinking – identify and maximize the flow of work.
- The Second Way: Amplify feedback loops – ask, involve, and listen to others.
- The Third Way: Continual Experimentation and Learning – incremental progress via iterative working.
IT Service Management. Since ITSM addresses operations and operations is the ‘ops’ part of DevOps, much of the guidance and approach in the best-known ITSM frameworks, such as ITIL and COBIT, are fundamental to good DevOps practice.
DevOps Models
As mentioned, DevOps is not a single defined concept, and so various models have emerged. In fact, there is an almost infinite variety of models possible that all build upon the basic DevOps principles.
Three points along the spectrum might help to illustrate and clarify the range of models.
Integrated Team (pure DevOps)
A single team owns a service or application and is responsible for designing, building, and operating it. The team will have – or have access to – all the skills and knowledge needed.
And are empowered, within limits, to take decisions and implement changes. This has been analogized to the best football (or soccer) teams—pure DevOps in that it really does combine dev and ops.
Embedding Operations
Each team owning an application has assigned operations people sat alongside them. They will share the goals of the team, but there will be more separation of roles within the team than the ‘pure DevOps.’
Separate Operations Team
here, applications teams are responsible for design and build and use operations as an internal service provider to run the infrastructure.
This doesn’t sound like DevOps (it isn’t really dev + ops), but it can be if the service relationship is established and maintained properly.
If development and operations staff see how they rely on each other for success, then the principle is delivered.
DevOps Methodology and DevOps Frameworks
Given that a methodology is ‘a system of methods used in a particular area’ since there is no single agreed definition for DevOps, there can’t be a single set out methodology.
Rather each application of DevOps takes in frameworks and methods that suit their situation to build their appropriate flavor of DevOps. The key thing is to ‘answer your question’ not ‘adopt other people’s answers.’
We’ve addressed many of the methodologies typically incorporated into DevOps: ITSM, Agile, automation, etc.
The key technique needed for successful DevOps implementation is changing culture – from ‘us and them’ to ‘us.’
One commonly used model that can be seen as a framework for DevOps is the cycle of design, build release, etc. – often displayed as an infinity symbol showing the never-ending nature of application design and support.
Again, in true DevOps fashion, there is no single set of stages around the loop, but typically they might be:
- plan
- create
- build
- test
- release
- operate
- monitor
- … plan and round again, we go.
This is the kind of cycle that has been around since long before DevOps. It is all the more relevant and useful for that history – reflecting how the 3-ways grounds DevOps in engineering tradition.
DevOps infrastructure
DevOps is a child of the 21st Century and is built upon the IT infrastructure of recent years.
It requires significant levels of automation and benefits from cloud-based infrastructure approaches that relieve organizations of specialist infrastructure skills.
This greatly facilitates integrated teams that can own applications and implement changes rapidly.
Modern DevOps relies on its toolset – often referred to as the DevOps toolchain, where relevant tools are selected and connected to provide end-to-end automation.
Interestingly it has taken the traditional applications approach of finding the best of breed products and making them work together.
Operations had traditionally preferred a single integrated toolset to ensure consistency and seamless operation.
Among the tools commonly seen within the DevOps toolchains are products that deliver automated code integration, testing, version control, configuration, integration, deployment, release, monitoring, incident handling, and much more.
Benefits of DevOps
So, eventually, why do all this? Ultimately the end goal must be better organizational performance – faster, better, cheaper, etc.
DevOps can help deliver this by offering organizations:
- Faster delivery – less elapsed time between ‘I want’ and ‘We have.’
- More collaboration – between business teams and IT teams. This maximizes the chance that when things are delivered, they are the right things, things that actually help the company deliver.
- Finding faults quickly – the sooner an issue is found, the sooner it can be remedied and the less damage it will cause. The speed and openness of culture that DevOps offers can deliver real financial and reputational benefits to an organization.
- Continuous deployment and release – linked to speed obviously, but many smaller frequent releases minimize disruption while maximizing benefits through lost opportunities – compared to traditional major packaged releases.
- Better mindset – often presented as greater customer experience, which is certainly important. But also, the IT staff experience. People who enjoy their work, perform better, and stay longer in the job. Staff turnover and low production are amongst the highest hidden costs for an organization. DevOps has been shown to generate happier working environments – and that means corporate benefit.
