by

5

DevOpsEmbrace DevOps to better serve

your clients

Key Success Factors of

You’ve heard about it, you’ve read about it. In fact, you’ve read 10 different definitions of what DevOpsis. But let’s not limit it too much and let’s concentrate on the big picture about DevOps :

“[DevOps is] A framework of ideas and principles designed to foster cooperation, learning andcoordination between development, QA and operational groups. In a DevOps environment, developers,QA and sysadmins build relationships, processes, and tools collaboratively in order to that allow themto better interact and ultimately better service the customer” - James Turnbull

Are you in this situation ?«When new code is released it needs a little "transformation» to fit in the production environment»

«Operations team feel like the developers have just tossed their work over the wall to them»

«The team to walk the corridors and ring each other to gather information on what they didn’tremember from last time they had to build a new environment»

Why now?The DevOps movement has become stronger since the first DevOps Days in2009. It has resonated with developers, ops, and more recently IT managers.

This is explained by the fact that new ideas, approaches, connection andtools have emerged to enable us taking on the problems we all encounter atsome point, whatever the size of the organization is.

The IT industry has already widely started adopting the DevOps approach,and most of those who haven’t are very seriously considering getting onboard.

You talk about DevOps ?

“DevOps is a whole new way of thinking about cooperation and coordination between the people whomake the software and the people who run it. Areas like automation, monitoring, capacity planning &performance, backup & recovery, security, networking and provisioning can all benefit from using aDevOps model to enhance the nature and quality of interactions between development andoperations teams” - James Turnbul

We all bring different experiences and focuses to the problem space but it’s important to keep CALMS(the acronym was introduced by Damon Edwards and then refined by Jez Humble).

CALMS: 5 Keys Success Factors Culture Automation Lean Metrics Sharing

How is DevOpsdifferent ?

"DevOps is a whole new way of thinking about cooperation and coordination between the people whomake the software and the people who run it. Areas like automation, monitoring, capacity planning &performance, backup & recovery, networking and provisioning can all benefit from using a DevOpsmodel to enhance the nature and quality of interaction between development and operation teams" - James Turnbul

1. Culture

Today’s IT organization consists of developer analysts, Web developer, testing teams, storage teams...or maybe just a few people within the company identified in one or more roles.

Often, there is a cultural split between developers, QA and operations and no bridge between them, eventhough none of them can or would have a purpose without the other.

They don’t really interact with each other. Occasionally, they talk together when something is wrong orbroken. In rare cases the relations between “factions” get toxic to the point that it hurts the business. A“not my problem” attitude is then openly advertised.

Shift from a silo organisation to a collaborative model. This isn’t something new. As a matter of fact, it’scertainly already a goal for you. But collaboration is not as good as it could be. It all boils down tobusiness = people = different agendas = politics = failure to collaborate. To move faster and deliver quality software, collaboration is essential and should be promoted across allbusiness functions.

Own the change to drive collaboration and communication

2. Automation

We know people are not reliable. In the sense that repeating manual tasks is error prone and sooner orlater, they’ll miss a step. That and a healthy dose of laziness equals to scripting repetitive tasks andsequencing manual operations with checks.

Sometimes the answer to automation you get is something along the lines.

«Oh, yes, we have hundreds of scripts that automate things already. We’re pretty good on that front.Developers and Operations use our in house customisations every day.»

If you dig a little deeper on that positive note, you might discover that «John Doe» is the goto guy. Andevery team you talk to, at some point or another points to John Doe. Soon, it becomes clear that, if thisJohn Doe is not in the shop, we’d better have no problems in the “machine room” or this ship is going tobe a sitting duck. The scripts have not been versioned, they live on his workstation, he’s the only one withaccess and knowledge, a few colleagues vaguely know about them but no one wants to mess aroundwith them... This is not what we want.

For some, automation defines DevOps, it’s the ultimate goal, the final stop, the promise of restful nightsduring on-call assignments. It’s a simplistic and reductive view.

Automation is about people and processes, not so much about tools. If you look atconfiguration management, you can achieve equivalent results with Saltstack, Puppet, Chef or Ansible.Tools have each their up and downsides, but if you should remember two quotes to guide you in yourautomation transition, these are the ones.

Take manual steps out of your value chain

next

2. Automation

Don’t automate what you don’t understand or cannot validate. A bad process automated, is still a bad process.

Sounds trivial, but it isn’t. If you want to automate something, you should really automate inside out. Onceyou have an idea of the correct process, the required technical components, configuration... and the stepsto automate it, you can start with automation.

You will need to work incrementally and several functions will have to collaborate: Dev, QA, OPS. Expecttrials & errors before you’ve ironed the whole process out.

With legacy infrastructure in play, what will matter most is getting visibility of current state. If you arerelying solely on documentation (usually out of date) and/or the recollections of your coworkers, you willface hard times.

Another important point is that your sysadmin staff will need software development skills. Maybe they’llneed to learn Ruby or understand the YAML/JSON syntax, they’ll need to version the code they produce andcollaborate, they’ll need to understand delivery, QA and deployment pipelines.

Plan for the learning curve. You will not transform into Netflix overnight and go all Chaos Monkey onyour infrastructure, but in the right hands, automation tools can work wonders.

3. Lean

«Once you have teams cooperating and working together, they can work towards the ultimate goal of Lean– becoming ‘lean’ by shedding the ‘fat’ that is causing inefficiencies and reducing productivity. This fatresults in bottlenecks in the delivery pipeline, over-production and rework. Eliminating these bottlenecksto enhance productivity are the key goals of Lean, and ultimately, of DevOps» - Sanjeev Sharma

For companies working to reduce costs while enhancing performance, the Lean approach is a natural fit.Lean tells you to optimise the end- to-end process, from the initial idea to money in the bank.

Passionate and heated discussions on tools are common in DevOps circles. Improving the flow, though, isnot a tools niche. There are other simple, yet profound techniques, that have a huge impact on workflowand its management.

King of the hill? Work in small batches.

It seems trivial, but it does make a big difference. History has already proven it, it’s a fact! Thinkautomotive assembly lines. The same principles can be applied to the IT industry. Working in smallbatches reduces cycle times.

This means you’ll get feedback quicker, which , in turn, helps you to reduce risks and act on errors faster.What you gain from it is efficiency, overview and visibility: in a word, control. It encourages decoupledarchitectures, thereby avoiding dependency issues.

Those implementing a DevOps value chain use a lean flow approach to product development.

Lean flow methods can use Kanban to provide a visible connection between all the work states in thesystem. With Kanban, bottlenecks become evident. Dependencies between teams or with third-partiesemerge as indisputable.

Use lean principles to enable higher cycle frequency

4. Metrics

Your goal is to understand, protect and improve the wheels of your business. You know the say :

“You can’t manage what you can’t measure”. Metrics basically fall into three categories. People :People-oriented metrics typically measure turnover, capability, and response time.

Process : the continual deployment / operations / support cycle is an ongoing suite of interwovenprocesses. Process metrics can measure speed (where are the bottlenecks?), effectiveness (does it getthe job done?) and/or efficiency (are all steps done in an optimum sequence).

Technology: Technology metrics play a crucial role (availability, health, capacity, ...) and they can giveyou an insight of what drives your business and where to focus your efforts. Only one thing toconcentrate on here: red is “good”, green is worthless.

Metrics can span over these categories. Let’s take an example that speaks to everyone: Mean Time ToRecovery/Repair (MTTR). This is the time from a failure to recovery from that failure.

It’s generally a good measure of team capabilities, and it should showan overall decrease over time (including the one-offs and the hardproblems faced for the first time and needing longer investigationsbefore resolution).

MTTR can also be affected by such things as code (or platform)complexity, the number of new features added to an application, andoperational changes (OS or software upgrades, migrating to a newcloud server). If you want to go the DevOps route, you need metrics,and preferably good and reliable ones.

Without metrics, you won’t be able to tell if your DevOpsimplementation is going in the right direction or if you need toconcentrate on identified issues.

Measure everything and use data to refine cycles

5. Sharing

The chain is as strong as the weakest link. Reinforce the weakest link!

Your staff needs to share the view on reality:Idea Project Product "Ka-Ching is" nothing else than Business Dev Ops Users.

Here are a few pointers of what to share :• Goals: improve reliability and speed• The problem space: deployment, delivery• Priorities: what get’s improved first?• Location: minimise communication efforts, make it personal• Communication: with a wiki, a company chat, a mailing list• Code base: app code and infra code• Toolset: git, vagrant, ...• Responsibilities: fix the build, fix the deployment• Process: attend standups, releases• Knowledge: ticketing system, knowledge base, CMDB• Success and failure: common experience, history• Feedback: monitoring, dashboards•...

Here’s an example. Failure! Who is responsible? How many times have you heard that question orsomething alike? Failure is one area where improvement can be achieved rapidly: shift the way you seefailures and the way you treat them.

Share experiences, successful or not, to enable others to learn

A failure is just another way to learn what can be improved. It might not be the most pleasant way, but ifyou act on it, you won’t have to suffer from it again, or at least, less often. Shouting, finger pointing anddemanding the culprit’s head is not going to help in any possible way. Transition to a blamelessapproach, identify issues and corrective measures.

Share the responsibility of failure and success across teams and/or organisations. Change the waysuccess and failure is measured: it’s everyone’s responsibility to contribute towards success.

In a nutshell

“The DevOps movement is characterised by people with a multidisciplinary skill set - people who arecomfortable with infrastructure and configuration, but also happy to roll up their sleeves, write codeto control infrastructure, debug, and ship features” (Stephen Nelson-Smith).

A key success factor here is knowledge sharing between operations and developers. Those peopleare already around you: look closer.

Different companies have different goals, different problems: theyface different challenges. Big shops have more money than time,they might focus their interest on out of the box solutions thatpromise the DevOps nirvana.

Small shops have more time than money and can focus on opensource tools, bending them to fit their needs, thereby significantlyreducing upfront costs.

After all is said and done, what we really want is «businessagility», not just «software agility» and «IT alignment” - the wholeof IT focusing on key business priorities and strategies.

In many ways, DevOps brings simplicity. Keep It Simple, Stupid (K.I.S.S.): “design simple, repeatable,and reusable solutions. Sim- plicity saves documentation, training, and support time.

Simplicity increases the speed of communication, avoids confusion, and helps reduces the risk ofdevelopment and operational errors” (James Turnbull). The drawback: to achieve simplicity, a lot ofhard work is required. “There ain’t no such thing as a free lunch”!

Where to start ?

DevOps is not a destination, but a journey of continuous improvement and innovation.To head in the right direction we recommend to adopt a simple yet structuredapproach.

Step 1 - Assess your strengths & weaknessesThe first step should consist in assessing your situation. We recommend to conduct a series ofgroup interviews, gathering a good mix of stakeholders involved in the complete software lifecycle,including client-facing staff, business people, developers, QA guys, sysadmins, infrastructurepeople... with field staff and middle managers.

It usually takes only a few sessions to understand your main issues and risks, that you will need totackle, but also your key strengths, that you can build upon to reinforce and improve further.

Step 2 - Define goals and align everyone Business and IT managers will have to work hand in hand and define the prime objectives of theDevOps initiative. What do you want to achieve in the next 12-24 months ?

As DevOps is essentially about people collaboration, it is critical to effectively communicate thereasons for impulsing this change (so it makes sense for everyone), why it’s important and what arethe success metrics.

Management’s voice is important but the participation of various stakeholders will also help ensuringthe necessary corporate align- ment.

Where to start ?

Step 3 - Make plansIt’s not one plan that is needed but rather a series of plans at different levels of details and fordifferent time horizons. Usually the following levels are a good start: roadmap (key milestones over a18-24 months period), mid-term plan (objectives and key activities to be achieved within 3 to 6months), actionable plan (detailed activities and concrete deliverables to be produced within a fewweeks).

Of course those plans should be built and revised periodically by focusing on top-priority objectivesand the corresponding experiments to be conducted in the following term.

Where to start ?

Step 4 - Experiment incrementallyA pragmatic DevOps approach is based on experiments designed to validate that the proposedchanges will bring the expected results. Areas of action for DevOps typically fall into one of the fol-lowing categories:

• Software design & architecture to easily deploy high-quality applications in small batches, they needto be designed in a modular and loosely coupled fashion, for easy testability, maintainability andconfigurability.

• Application Lifecycle Management (ALM) To guaranty a solid code base, ready for frequentpackaging & deployment, key practices such as continuous integration, continuous inspection andtest automation must be implemented. • Release Management : The objective is to make software releases as often as needed and turn theminto “non-events”. This requires extensive automation, based on clear processes and solidgovernance.

• Infrastructure : Reliable infrastructure management, provisionning, being able to up/down or in/outscale on demand or simply get visibility and control can be enhanced by cloud services and/orconfiguration management tools (infrastructure as code).

• Collaboration to drive more efficient collaboration between various stakeholders it is important todevelop trust, share knowledge and make work visible. Different team organisations can also beconsidered to pro- mote cross-functional collaboration.

• Business user monitoring to help functional managers deciding which features and services to focuson or maximising business value, monitoring capabilities can be leveraged to create business-oriented metrics and understand actual users behavior.

next

Where to start ?

Those experiments should be conducted incrementally and the action plan adapted according to theactual results and learnings. It’s not one plan that is needed but rather a series of plans at differentlevels of details and for different time horizons. Usually the following levels are a good start :roadmap (key milestones over a 18-24 months period), mid-term plan (objectives and key activitiesto be achieved within 3 to 6 months), actionable plan (detailed activities and concrete deliverablesto be produced within a few weeks).

Of course those plans should be built and revised periodically by focusing on top-priority objectivesand the corresponding experiments to be conducted in the following term.

Agile Partner is a dynamic software company that creates custom applications and provides consultingservices. We are convinced that, in a constantly changing market, only an agile approach can providetruly valuable results. We constantly want to innovate in our way of helping businesses grow thanks to aflexible and robust IT. That’s why we have come to develop an expertise in Lean/Agile and DevOps.

You are convinced that DevOps is for your organisation? But you wonder how to improve thecollaboration within your teams, how to improve your software quality, how to automate your softwaredeployment, how to release as often as required by your business needs... in other words, how to be moreagile? Contact us now to start your DevOps journey and achieve your goals faster! Send an email todevops@agilepartner.net or call us: (+352) 263.700.30

Referenceshttp://www.jedi.be/ - Patrick Deboishttp://www.grahamlea.com/2013/02/what-is-devops-bullet-points-quotes- tweets/https://www.scriptrock.com/automation-enterprise-devops-doing-it-wrong, Alan Sharp-Paulhttp://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.htmlhttp://kartar.net/ - James Turnbullhttp://devops.com/http://leanchange.org/

More information on our Websitehttp://devops.agilepartner.net

@devops_lu

About us

Contact us!

Address:Agile Partner S.A.20A rue du Puits Romain,ZAI BourmichtL-8070 Bertrange

by Agile Partner