DevOps is a new term that’s taking the IT world by storm. But what exactly is it, and how can South African companies take advantage of it to develop better applications quicker? Kathy Gibson found some answers
The term DevOps has been kicking around for some time, and we know that it’s the secret behind much of the success of new-age digital organisations. But, before South African companies can reap the full benefit that can be derived from DevOps, it’s important to understand what it is and how it can be employed for maximum advantage.
Wikipedia defines DevOps as: “A software development method that emphasises communication, collaboration (information sharing and Web service usage), integration, automation and measurement of co-operation between software developers and other IT professionals.
“The method acknowledges the interdependence of software development, quality assurance (QA) and IT operations, and aims to help an organisation rapidly produce software products and services and to improve operations performance.”
This many sound like existing development methodologies like Agile, but there’s a fundamental different in that DevOps promotes a set of processes and methods for thinking about cross-departmental communication and collaboration between development, QA and IT operations.
One of the main goals of DevOps is to deploy applications quickly and often, leading to faster time to market, a lower failure rate for new releases, shorter lead times between fixes and faster mean time to recovery in the event of a crash. The DevOps approach aims to maximise the predictability, efficiency, security and maintainability of operational processes, often using automation.
Justin Arbuckle, vice-president: EMEA and chief enterprise architect at Chef, explains that DevOps is tied up with the whole transformation of business.
“What we need to do is evolved out thinking on how businesses should be run,” he says. “It turns out that the core principles of DevOps are informing the changes and strategies in our organisations.”
It’s helpful for IT people to understand that there is a revolution going on in how we think about business. “It’s not actually about DevOps, or about West Coast ideas or Web-based companies,” Arbuckle says. “All business is beginning to change.
“But often when you move from the big Web to large enterprises there is a core thing that makes people not want to get started on change. Or they do an eight-week project and never get beyond that.
“But you can do it, and you must do it. Unless you approach the operating model using DevOps you are making your company unstable. If you think of your company now as compliant and safe, that’s an illusion.”
In the transformed enterprise, Arbuckle says, new products iterate quickly over a range of requirement. “They don’t try to anticipate an unknown future. The ability to iterate quickly lets it remediate risks. You should have the capacity to take a best guess, produce a minimally-viable product and quickly iterate on that.”
Velocity is a new imperative that has come out of the big Web, Arbuckle adds. “If you want to operate at higher velocity, you will make mistakes. But moving faster lets you remediate faster, and you need this ability more than you need processes that sit across the organisation.
“Let velocity be your guide.”
This all adds to the reliability of organisations which start to become anti-fragile, Arbuckle explains.
And speed is imperative: “If you can’t respond fast, you are just talking to yourselves.”
In South Africa a group of IT developers and academics has set up a DevOps Working Group, with the intention of exploring the discipline and promoting its use in the local environment.
Adam Jacob, chief technology officer of Chef, spoke at the group’s inaugural meeting about how DevOps came about, and offering some pointers to making it work.
“DevOps was created by the people doing the work, and is unique to each person,” he says. “It came from a 15-year journey of running the deep Web which become a style of working.”
He explains that the people tasked with running big Web sites came to realise that the IT disciplines they’d learnt simply didn’t work in the new environment.
“We learned over time that we had to build higher-trust relationships, automate more and be more self-reliant. When you run into problems, vendors are very happy to sell you a solution – they always have an answer to your problem. But they don’t truly understand your problem, so you are really on your own.”
With the challenges facing IT organisations difficult to define, coming up with a definition or methodology for DevOps is almost impossible, Jacob adds.
“There are some common themes and behaviours, but there are a million different definitions,” he says. “DevOps doesn’t exist as a theoretical concept but as a lived experience.”
In general, though, there are some macro trends that are common to all the people who are successful to DevOps.
Chef came up with the idea of DevOps being a bit like the martial art Kung Fu, or wushu. “There are hundreds of different wushu schools but they are all recognisably wushu,” he explains. “Clearly they are not all the same, but they all share three basic ideas.”
These three shared elements are the basics, the forms and the applications.
“These three things are shared. The way you teach the basics is the same, the forms are the same, and the way they apply them in the world are similar but unique to individuals. And that’s how you know that they are going to do wushu.
“You can think of DevOps in the same way.”
Jacob explains that DevOps is less to do with software development as with re-inventing how we run our businesses.
“Whether you like it or not it’s what we are doing now – and it turns out that we are all practicing DevOps. What’s needed it to take all the specialists and connect them so that people can all come together as a team and accomplish what they can’t do on their own.”
At its foundation, DevOps is a cultural and professional movement focused on how we build and operate high-velocity organisations; born from the experiences of its practitioners, Jacob says. He warns that the same principles applied to low-velocity organisations will result in instability.
“It’s worth remembering that the movement came from people who were web innovators. As you apply it to your own context, you need to take from it what works for you.”
DevOps practitioners all believe in – and live – a set of principles, Jacob adds, and people who don’t buy into these principles aren’t embracing DevOps.
The principles are as follows, he says:
- Design for safety, contentment, knowledge and freedom.
- People doing DevOps favour people and products over companies. “It is always about the fact that the people doing the work like it, because there is a better chance they will build better products. Happy people build happy products equals happy companies …”
- DevOps people are lean. “They eliminate non-value-added action; favour pull over push; aim for continuous improvement, disruptive change, small batches and experimenting.”
- DevOps people have a relationship with failure. “It is normal and the status quo, not a thing to be avoided; panicking means you are not fixing the problem.”
- Ubiquitous workflow automation. “Once we know how we want to work, we build workflow and have automation by default.”
- Diversity. “DevOps is diverse and a high-functioning team must be diverse – the more of that you can get the better; you want a cross-section of skills.”
The form of DevOps – what people actually do – requires the team to focus on a purpose that’s bigger than the task in hand, Jacob says. “So a job might not be about fixing the site, but about changing the country.”
The forms are DevOps are as follows, he explains:
- Believe. “What do you believe will create good outcomes in your space? Use active voice, aim for good outcomes, make them public, include the DevOps principles and mix in the things that are unique to your industry or problem.”
- Build a highly-empowered team. ‘They must have permission to act, paired with the context to make good decisions; with leaders who care about the purpose of the organisation and who share your beliefs.”
- Form diverse bonds. “Meet with people outside your speciality; ask them what they do, and understand the problems and perspective. They could be people from legal, financial or sales.”
- Use this to build consensus on important decisions. “Circulate plans, then incorporate criticism and feedback. This will help to solve problems.”
- Have strong value propositions. “People buy painkillers not vitamins. Focus on that to make things people love by focusing on needs not wants. Differentiate between one customer wanting a feature versus many customer needing a feature.”
- Build a roadmap. “Include visions and feedback. Balance innovation with needs, group them into themes, distil those into features and validate them with customers. The themes should hold, the outcomes might hold, but the features will change.”
- Always have delighters. “Included features that make customers happy when they touch it.”
- Build features iteratively. “Don’t try to paint the Mona Lisa incrementally because you would need to know what it looks like before you start. Rather start with a sketch, add a bit of colour, then finish it.”
- Manage risk. “Work in small batches with near-term hypotheses. Remember, validation must come from customers and nowhere else. Introduce near-term volatility to gain decreased long-term risk – it makes the near term roadmap less clear, but reduces the risk of something in the long-term.”
- Don’t worry about scale. “Only worry about it when you should – and this is usually way later than you think.”
- Execution. “People will come up with new theories and you need to challenge them with execution. Execution always trumps theory.”
- Demonstrate what you do every week. “And invite everyone to give you feedback.”
- Choose languages and tools that fit the job. “We are all polyglots; and new languages and tools are one of the great benefits in this industry. Developing iteratively and in small batches will protect you from risk.”
- Have a bug database. “Triage and prioritise bugs.”
- Do continuous integration. “Always integrate branches to the master in short-lived iterative branches. Testing is good but continuous integration is better so you can fix the build when it goes red.”
- Obey the four-eyed rule. “Change nothing unless at least two people have seen it. Other human beings must review your work all the time.”
- Write tests. “But write them one test at a time, as you need them.”
- Continuous delivery. “You should be able to ship your ideas whenever you like – you don’t have to but you could.”
- One path for change. “The way change moves through the organisation is fixed. If you have one pattern for consistency it is easier to reinforce principles and aid flow. It helps people to help each other, and it is flexible at the level of execution.”
- Code goes through the same workflow regardless of whether it is for applications or infrastructure.
- Focus on availability. “This includes uptime, reduced mean time to diagnose and mean time to repair. Failure is inevitable, how you react to it is what makes the difference.”
- Collect metrics. “This can be from the operating system, the network, application or process.
- Plan for capacity. “You should be going that already but probably aren’t. Identify key metrics, put them on a graph, set a limit, plot a trend line; and expand the time horizon – which is when you need to scale.”
- Only alert on what is actionable. “And then get the attention of the right people – but as few of them as possible; the people who can take action.”
- Practice incident response. “This is possible the step that matters the most. The first responder is the incident commander and they decide what to do, co-ordinate resources and communicate status. It’s not about rank, but there can only be one incident commander.”
- Incidents lead to post mortems. “Learn not to blame, but describe the incident, establish the timeline, identify contributing factors, describe customer impact, describe remediation tasks, and describe how tasks can be improved for the response process.”
- Use scalable systems design. “Autonomous actors are responsible for themselves, making progress to the goal with clear promises to other actors who are able to evaluate the quality of them.”
- Design for simplicity, extensibility and re-use.
Once it’s spelled out, DevOps sounds complex and sometimes contradictory, but Jacob says there is safety is sticking to the technique. “Remember the principle, practice the forms and use your discernment,” he advises.
“In the real world, DevOps is about taking a business problem grabbing stakeholders across the organisation and for eight weeks just try it. You can afford to invest eight weeks.”
To test the principles, Jacob advises companies to pick a vertical problem that is small enough to have a meaningful iteration in those eight weeks.
“In stage two, set out your purpose, beliefs and teams. Write down the purpose and beliefs, empower the team and be available for context.”
The next step is to do the product development. “Write down the value proposition; build a roadmap with themes, outcomes and features; include some delighters and make sure it features simplicity, extensibility and re-use.”
Next up is to iterate features. “Manage risk through small batches, choose languages and tools that do the job, and ignore scale,” says Jacob. “When theory comes up, refocus on execution. Demonstrate every week to the whole company. Use source control. Have a bug database. Use one workflow for change. Let someone else see everything. Remember to do continuous integration and one test at a time. Use scalable systems design. When you operate, focus on availability, collect metrics, plan for capacity, alert on what is actionable, run incident response and hold post mortems.”
Delivery involves holding a final demonstration and holding a retrospective.
“What’s important about DevOps is that you need to find your own way,” Jacob says.