Click here to load reader

DevOps Success Factors of - · PDF file DevOps Embrace DevOps to better serve your clients Key ... automation defines DevOps, it’s the ultimate goal, the final stop, ... configuration

  • View
    1

  • Download
    0

Embed Size (px)

Text of DevOps Success Factors of - · PDF file DevOps Embrace DevOps to better serve your clients Key...

  • by

    5

    DevOps Embrace 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 DevOps is. 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 and coordination 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 them to 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’t remember from last time they had to build a new environment»

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

    This is explained by the fact that new ideas, approaches, connection and tools have emerged to enable us taking on the problems we all encounter at some 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 on board.

    ​You talk about DevOps ?

  • “DevOps is a whole new way of thinking about cooperation and coordination between the people who make 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 a DevOps model to enhance the nature and quality of interactions between development and operations 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 DevOps different ?

    "DevOps is a whole new way of thinking about cooperation and coordination between the people who make 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 DevOps model 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, even though 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 or broken. 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’s certainly already a goal for you. But collaboration is not as good as it could be. It all boils down to business = people = different agendas = politics = failure to collaborate. To move faster and deliver quality software, collaboration is essential and should be promoted across all business 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 or later, they’ll miss a step. That and a healthy dose of laziness equals to scripting repetitive tasks and sequencing 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. And every team you talk to, at some point or another points to John Doe. Soon, it becomes clear that, if this John Doe is not in the shop, we’d better have no problems in the “machine room” or this ship is going to be a sitting duck. The scripts have not been versioned, they live on his workstation, he’s the only one with access and knowledge, a few colleagues vaguely know about them but no one wants to mess around with them... This is not what we want.

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

    Automation is about people and processes, not so much about tools. If you look at configuration 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 your automation 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. Once you have an idea of the correct process, the required technical components, configuration... and the steps to automate it, you can start with automation.

    You will need to work incrementally and several functions will have to collaborate: Dev, QA, OPS. Expect trials & 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 are relying solely on documentation (usually out of date) and/or the recollections of your coworkers, you will face hard times.

    Another important point is that your sysadmin staff will need software development skills. Maybe they’ll need to learn Ruby or understand the YAML/JSON syntax, they’ll need to version the code they produce and collaborate, 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 on your 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 fat results in bottlenecks in the delivery pipeline, over-production and rework. Eliminating these bottlenecks to 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, is not a tools niche. There are other simple, yet profound techniques, that have a huge impact on workflow and 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! Think automotive assembly lines. The same principles can be applied to the IT industry. Working in small batches 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 decoupled architectures, 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 the system. With Kanban, bottlenecks become evident. Dependencies between teams or with third-parties emerge 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 contin

Search related