devopsy.kinsta.cloud

Tag: devops tools

  • 28 DevOps and Continuous Delivery Reference Architectures (Vol. 2)

    28 DevOps and Continuous Delivery Reference Architectures (Vol. 2)

    People want to get going with DevOps or Continuous Delivery, but need a place to start.  Others are already on their way, but need some validation of their choices.  In April, I published the first volume of DevOps and Continuous Delivery reference architectures which has now been viewed over 37,000 times on SlideShare (it’s free to download…no registration required).  Three things helped people in the deck: (1) the reference architectures, (2) links to the sources for each architecture attached to each slide, and (3) no marketing fluff.

    [slideshare id=45996806&doc=nexusandcontinuousdelivery-150318110625-conversion-gate01]

    I am honored to have helped so many people on their DevOps and Continuous Delivery journeys.  So this month, I compiled Volume 2 of the reference architectures.  You can now view the deck on SlideShare, download it (again…no registration required), and share it with others.  Have a look and let me know what you think.

    As I did with Volume 1, if you have a reference architecture that you would like to share, I would be happy to add it into Volume 2 with full attribution to you.  Just ping me in the comments section or reach out to me @weekstweets.

    Here is Volume 2:

    [slideshare id=50972100&doc=devopscontinuousdeliveryreferencearchitecturespart2-150727141843-lva1-app6891]

  • Ten ways DevOps will benefit your IT department

    Ten ways DevOps will benefit your IT department

    When implemented properly, DevOps can transform your software engineering process and create value for both employees and customers, producing business performance and value.

    A fully working DevOps methodology will bring the following benefits:

    1. Increased service quality

    Perceived service quality and reliability depend on both the availability of a service in the absence of error (MTTF: Mean-Time-To-Failure) and the ability to restore the service to an error-free-state (MTTR: Mean-Time-To-Repair).

    Due to fast feedback loops and high release velocity, service deficiencies are removed much faster than in the past (shortened MTTR), which leads to an improvement of perceived service quality and reliability.

    1. Increased reliability of service delivery

    The perceived timeliness of delivery is an extremely important satisfaction factor for your internal or external customers Usable results are delivered early and frequently, which is critical in uncertain and changing business environments.

    With agile and DevOps, big projects are cut into small chunks, which are then continuously delivered. Both initial and successive requirements and changes are delivered with short lead times, while changes are possible at any time in the process.

    1. Increased customer value through responsiveness to change

    To stay relevant, businesses need to constantly adopt to a rapidly changing market environment, respond to competitors and stay ahead in the innovation cycle. Your business needs to act in a world of uncertainty.

    This means that at the time a new idea is brought up, most of the project details cannot be known. Even once they are defined later on, they are subject to constant change. Complex upfront specifications – a necessary deliverable in the absence of short release cycles – often become obsolete.

    1. Better usability increases customer satisfaction

    Shorter release cycles lead to shorter feedback cycles. Your customers are receiving frequent and timely updates, which gives you the ability to evaluate and test their satisfaction and response early on.

    You can even test different versions of your product at the same time with different customer groups by A/B testing. This gives you the ability to compare different new features or capabilities of your products to each other.

    1. Efficient operations

    Agile and DevOps are built on lean principles. The reduction of waste, such as unnecessary waiting times or process overhead through continuous improvement, is a core principle.

    This not only helps agility, but also has a positive impact on costs by helps to limit their growth.

    1. Reduce bottlenecks through cross-pollination of skills

    Blurring the line between dev and ops involves each side learning about the other’s trade. This enables staff to understand the whole process end-to-end and see where it can be tweaked and improved.

    If ops know the basics of coding and vice-versa, bottlenecks can be removed by not having to rely on highly specialized individuals. Automation also helps here, for instance in the way a dev can use a service catalogue within ServiceNow to spin up environments on demand, without waiting for an ops member to have free time.

    1. Holistic value creation increases employee satisfaction

    In a conventional IT organization, both dev and ops are often limited to executing specialized tasks. The value these tasks create for customers is often difficult for customers to measure, as it is one small aspect of a complex process.

    Whether internal or external customers are served, the impact created by agile dev and ops teams is far more direct and holistic and can thus be more easily observed and “felt” by employees.

    1. Collaboration improves employee attitude

    Whereas previously dev would hand code over to ops then switch to the next project, DevOps encourages collaboration throughout the team along the entire process. Not just exchanging emails, but face-to-face and through collaborative devices such as Kanban boards and Scrum meetings.

    In the past, the two teams could have been working in different offices. DevOps brings IT together, and this shift in culture is likely to spread outside the department. This reduces waste through misaligned incentives causing political behaviour and mutual blame and increases employee satisfaction.

    1. Constant learning and improvement

    DevOps promotes a culture of continuous learning and improvement through lean principles. In a fast-moving and unpredictable environment, continuous improvement is the single most important source of sustained competitive advantage and superior economic value.

    An continuous learning environment also attracts and sustains outstanding talent. It is an important ingredient to employee satisfaction. 

    1. Reinvigorate your employees

    Apart from the new technical practices DevOps brings, perhaps one of the main advantages for IT is the shake-up it gives working lives. Like a new sports coach can bring a fresh perspective and increased work-rate amongst the team, so DevOps can reinvigorate software engineering teams.

    New people to interact with, perhaps even a new office and a new way of working – DevOps can be just what IT needs to breathe life into stagnating staff who have been following the same routine for far too long.

    **************************

    In order find out how to implement DevOps in your IT department and see these benefits for yourself, I recommend attending my free webinar on Tuesday 28th July. Click to find out more.

  • What is DevOps to you? New survey by ElasticBox and devopsy.kinsta.cloud

    What is DevOps to you? New survey by ElasticBox and devopsy.kinsta.cloud

    What is DevOps to you? Now that is a loaded question. For so long DevOps has defied definition. How can then we quantify it? How do you know if it is working? What do you spend on it? What exactly do you do when you do it? What tools do you use?

    While the folks over at Puppet Labs, Gene Kim and team have done a great job with their annual surveys showing DevOps adoption and its impact on high performing IT organizations, it is time to delve a little deeper into exactly what tools are we using, what works and what doesn’t work.  Heck, even what we consider working or not is still to be defined.

    So we are partnering with our friends at ElasticBox to conduct a survey to better understand what it is that you consider DevOps, what you are paying for it and do you consider it successful.

    You can take the survey in about 10 minutes or less.  You can take the survey right here: https://www.surveymonkey.com/s/devopsdot

    Oh wait there’s more. One in 50 respondents will win a $50 Amazon gift card (you need to supply contact info to win) and one grand prize winner will win a really nice 3DR IRIS+ Drone (pic below), again you must supply contact info to win)

    IRIS_goproWe will publish the results and analysis in July. So take 10 minutes and help us help the community with this vital information.

  • The real cost of downtime

    The real cost of downtime

    Stephen Elliot and the IDC team recently released a report (registration required) sponsored by AppDynamics that examines the true cost of downtime and infrastructure failure, as well as DevOps adoption. The headline numbers are pretty eye-opening:

    • For the Fortune 1000, the average total cost of unplanned application downtime per year is $1.25 billion to $2.5 billion.
    • The average hourly cost of an infrastructure failure is $100,000 per hour.
    • The average cost of a critical application failure per hour is $500,000 to $1 million.

    Let those numbers just sink in a moment. Between $1 to $2.5 billion lost to application downtime a year!  That is a big number, but if you look at the follow on numbers you can see how you can get there. Infrastructure failure has an average hourly cost of $100k per hour, critical application failure has an average hourly cost of $500k to $1m per hour. It doesn’t take a lot of hours for those numbers to add up. You can read in the report the actual math IDC applied to reach these conclusions based on the responses to a survey they undertook.

    There was also some good insight into DevOps and DevOps tools adoption.  Remember this was aimed at the Fortune 1000 market segment, so large enterprises. About 43% of respondents were using DevOps currently, with another 40% planning on adopting DevOps soon. That 83% number is in line with another recent survey by CA that showed an 88% number.

    But all is not as rosy as that picture paints.  When looking at the biggest impediments to DevOps, the usual suspects rear their ugly heads:

    • Cultural inhibitors – 56.7%
    • Fragmented processes – 43.3%
    • Lack of executive support – 26.7%

    All three of these topics have been the fodder for stories here on devopsy.kinsta.cloud. There are specific strategies to overcome each of these, but the fact is they are still major obstacles to successful DevOps adoption despite overwhelming desire to do so.

    There was another interesting metric in the study that bears noting as well. It is about companies who try to use their existing tool sets in a DevOps setting. There is something like an 80% failure rate for companies who try to adapt their existing tools for DevOps practices.  That screams out something that many a man already knows, “you need the right tool to do the job right.”  The moral of that story is if you are going DevOps you damn better be buying some DevOps specific tools to get the job done right.

    Again in line with other surveys I have seen the biggest initiatives driving DevOps adoption are:

    • Automation 60%
    • Continuous delivery 50%
    • Continuous integration 43.3%
    • Automated testing 43.3%
    • Application monitoring/management 43.3%

    DevOps was being initiated by slightly more development teams that IT Ops teams by about a 40% to 33% margin respectively.

    You can download the full report from the link at the top of the story to get the rest of the data.  Ultimately like similar surveys there are some assumptions that you have to swallow in order to give credence to the findings. For me the biggest grains of salt to consider are:

    1. This survey was based on a relatively small amount of respondents. On average like 50 per question and some of those not from organizations in the scope of the survey. With that small a group trends could be skewed by a handful of outlier responses.
    2. While IDC is a very reputable company, the fact is this was a sponsored survey by a DevOps tool vendor. AppDynamics likewise is a reputable company (and in full disclosure a sponsor here at devopsy.kinsta.cloud), nevertheless it is something you should take into consideration.
    3. Perhaps the biggest grain is: Do you buy their math in calculating downtime? According the report’s authors here is how they arrived at their numbers:

    To examine application downtime impact per year across the Fortune 1000, we conducted the

    following analysis:

    • 1,000 companies multiplied by an average of 250 critical applications per company equals 250,000 total applications. 250,000 multiplied by an average of $500 to $1 million per hour of downtime cost equals $1.25 billion to 2.5 billion of unplanned application downtime costs per year.

    That sounds like back of napkin stuff to me. But really at the end of the day whether the number is $1b, $2b or more, suffice to say it is a big number.

    Surveys like these continue to contribute to a broader understanding of the DevOps market. It also provides cover to IT executives seeking support to kick off DevOps in their own organizations. Hopefully we are approaching a critical mass of data that will make the job of “selling” DevOps up the org chart an easier sell.

    UPDATE:

    Here’s a great upcoming webinar that will include thought leadership from Stephen Elliot, VP of analyst firm IDC on “DevOps and the Cost of Downtime” based on research of Fortune 1000 companies.  Register for it now, here.

     

  • Why DevOps is like fitness or religion

    Why DevOps is like fitness or religion

    What is DevOps?

    I noted in a blog post last summer that limiting DevOps to a single definition is challenging. The Wikipedia entry for DevOps contains a variety of possible explanations that seem to disagree in some ways:

    • It’s a “software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals.”
    • The goal of DevOps is “to maximize the predictability, efficiency, security and maintainability of operational processes. This objective is very often supported by automation.”
    • It “targets product delivery, quality testing, feature development and maintenance releases in order to improve reliability and security and faster development and deployment cycles.”
    • It “aids in software application release management for a company by standardizing development environments.”

    All of these are true, and yet none of them is necessarily THE definition of DevOps.

    A recent ZDNet post titled Why there will never be one do-it-all DevOps tool proclaims, “There is really no such thing as a specific DevOps “tool”—and don’t buy into the “DevOps” labeling many vendors are attaching to their solutions. Successful DevOps depends upon a multitude of tools and methodologies that can help organizations better align their software development and release cycles.”

    The question, “What is DevOps?” isn’t like asking, “What’s the temperature today in Phoenix, AZ?” or, “What’s the fastest land animal?” Those questions have precise answers that are based on measurable, irrefutable metrics. The answer is the answer and it isn’t really open to debate.

    “What is DevOps?” is more like asking, “What is the best fitness program?” or, “Which religious belief system should I subscribe to?” There is a vast array of answers and passionate beliefs on all sides. But, there really isn’t so much a “right answer” as a “right answer for you”.

    When it comes to fitness, there seems to be as many diet and exercise programs as there are people trying to get fit. Books, magazines, and infomercials are filled with extraordinary examples that “prove” that a given fitness program or philosophy works…at least for the subject of the story. There are some elements that are universal truths like exercise is better than being sedentary, and making healthy eating choices is better than eating an entire cheesecake for dinner. Almost everything else is subjective. There are too many variables involved that make people, and how they respond to different diet and exercise programs, different.

    DevOps is also like religion. Most people don’t choose their faith. They’re raised from birth to follow in the footsteps of their parents, and their religion is more or less predetermined. Religion is also personal. While some will insist that there is only one true faith and that theirs is the only real religion, most people recognize that religious faith is very subjective and it’s a function of finding the belief system that makes sense to you.

    DevOps is like fitness and religion in that what it means to an organization, and how it is first implemented, is influenced by the existing culture and infrastructure—the IT the company was “raised on”. DevOps is also like fitness and religion because there is no “one-size-fits-all” answer to the question “What is DevOps?”

    It isn’t a defined process—it’s more of a concept or philosophy. It isn’t a product or service that can be packaged and sold—it’s more a collection of the products and services that enable you to embrace the concept or philosophy. To some extent, DevOps is whatever works for your organization to automate routine tasks, reduce redundant effort, streamline operations, and remove unnecessary obstacles so people can get things done as efficiently as possible.

  • 3 Tips to Shape Human Behaviors and Achieve Your DevOps Goals

    3 Tips to Shape Human Behaviors and Achieve Your DevOps Goals

    DevOps raises many questions around processes and technologies, but it is important to remember that people are the essential piece that makes DevOps work. Since my post on Generalists vs. Specialists here on devopsy.kinsta.cloud, I have had many questions about shaping human behaviors, like this one:

    Q. How can I help my team build up the attitudes and behaviors we need for our DevOps team?

    In an industry often dominated by technical advancements, flashy applications and an ever-changing “next big thing,” it’s probably not surprising that the human aspects behind them usually fly under the radar. That is changing with DevOps, but there is a need for prescriptive advice on how to encourage a ‘DevOps attitude.’

    This question then is typical of many looking for specific steps to help shape the human element of DevOps. So here are three approaches to help you encourage DevOps behaviors to be successful.

    1. Connect Individual Job Duties to Higher-level Business Processes and Goals

    In traditional environments, staff are often only concerned with their silo, not the overall process. They may fulfil their duties within their silos – writing code, testing release, maintaining stability – without ensuring the whole process contributes to the ultimate business goal, which is really the whole point.

    By contrast, DevOps treats the SDLC as a value chain in which discrete activities (designing, coding, testing, etc.) occur in a complementary fashion to add value to the final deliverable – a production application. Traditional value chains have taught us that optimizing at the individual activity level can only get you so far – true evolution happens when you optimize at a higher, end-to-end process level.

    I have posted before about encouraging a ‘big picture’ view of enterprise DevOps, but sometimes this is not enough. To take this a step further, you should directly connect the job duties of each team and each individual to the business goals, and hold them accountable to hit these goals.

    2. Update Compensation Plans so They Align with Your DevOps Strategy

    Speaking of accountability, one of the best ways to shape staff behaviors is to align rewards with desired end-to-end goals. Tying compensation to the entire team’s ability to accelerate delivery of high quality services, each individual will bear responsibility for all aspects of the SDLC. Not only does this provide ample incentive to embrace change, but it also gives staff a clear direction and specific goals.

    This contrasts with a silo-based approach with, for example, a developer rewarded only for release speed, so they pump out code as fast as they can, regardless of defects; or an operations silo rewarded solely for stability, which encourages them to delay release in case new code breaks something.

    Of course, pay is not the only compensation that motivates great dev and ops teams. So don’t forget other rewards, like training, conference tickets, new projects, team activities, or new responsibilities.

    3. Technologies and Tools Will Help DevOps Staff Excel

    When trying to model behaviors, it is important to remember that technology can help. For example, if your goal in adopting DevOps is to compress software delivery to meet a shorter timeline, you can’t just expect people to work harder, faster, and/or longer; you’ll need to help them with shared technologies that let your people work together better and smarter, not just harder.

    For example, service virtualization relieves the need to build up physical test environments for every new code release, so dev and QA can build better code, test more, and improve quality. Release automation relieves of the need to manually release new code into production, so development and operations can focus on improving code quality and architecting for scale. Plus, both teams end up going faster, with fewer errors cause by human intervention.

    Beyond specific tool selection, make sure your entire DevOps team is trained on their use, so they can all contribute by working smarter and better to achieve the company’s goals across their silos. This cross-skilling and shared responsibility helps to ensure the collaboration, communication, and integration of people that is an essential part of a DevOps approach.

  • DevOps with Purpose: It’s about your tools!

    DevOps with Purpose: It’s about your tools!

    This is Part Three in a four-part series. In Part One, I focused on the critical first step of defining DevOps with a purpose by thinking about DevOps in the context of your organization’s applications. In Part Two, I provided four tips to fostering a DevOps culture in your organization.

    By now you’ve hopefully noticed the emphasis on “your” in this series, because, at the end of the day adopting DevOps is about your business, your applications, and your culture. In this third part of the series, I’m going to discuss your tools.

    In IT, we’re indundated with tools. Developers have their favorite tools and sys admins do too, so do the project office, the service support group, and the QA team. There are IT tools purchased by our organization years ago that we are using and others we aren’t, tools we’ve recently started using, and others we are considering at any given point in time. There are also general-purpose tools the company wants us to use for things like document sharing, instant messaging, and so on. It’s got to the point where a lot of IT organizations say, “we have two of everything like Noah’s ark”, yet they still want more tools.

    Part of the reason is that, as IT practitioners, we like gadgets and tools. We like the fact that they can help us do things and can amplify our own abilities, but we also know they can fragment information and can blindside us when someone uses a tool to do something that others weren’t aware of.

    Do we really need more tools to do DevOps?

    DevOps has a close association with the Agile Software Development movement, and one of the core tenets of the Agile Manifesto is to value “Individuals and Interactions over processes and tools”. Nevertheless, it’s hard to find a DevOps talk or article that doesn’t discuss the need for tools like git, docker, jenkins,  puppet, chef, and so on. The reason for this is actually pretty straight-forward: continuous integration and continuous delivery are best done through automation so we can follow a repeatable method and roll things back quickly if there are issues.

    At a more basic level, however, we need to acknowledge that there are really two types of tools:

    • Tools that help us amplify our abilities as individuals (e.g. I can drive a nail into a board with a hammer much more effectively than with my hand or a rock because of the strength of the hammer’s material and the principle of leverage)
    • Tools that help us coordinate work across many humans, thereby, amplifying our individual abilities (e.g. I can build a house much faster and with better quality by leveraging different experts’ skills and using a shared set of blueprints for building construction, plumbing, electrical, heating/cooling, and so on)

    The same distinction holds true for software development, deployment, and operations. One individual can theoretically gather requirements, build the software, test the software, deploy the software, and support the software  while simultaneously project manage their personal time. Most computer science students have done this in fact at one time or another, but when we are talking about enterprise applications that support core business functions it clearly doesn’t make sense because of the amount of effort required at each step and the specialized skills necessary for a high level of competency in each area.

    What this means is that we absolutely need tools that amplify our abilities, or that of our individual teams, i.e. the hammers; but we also need to invest in tools that help us coordinate work across teams, i.e the shared sets of blueprints.

    Tools That Amplify Individual / Team Abilities

    A lot of the tools attention in the DevOps community has been focused on: source code management systems like git or bitbucket; requirements planning tools like jira or rally; build tools like Jenkins; automation tools like puppet, chef, and ansible; and project management tools like MS project or AtTask. These tools help us amplify work in each of these respective areas just like hammers, saws, drills, and screwdrivers perform specific functions when building a house and often follow a natural sequence (first you hammer boards in place to create a wall, then hammer on the sheet rock, then saw or drill holes in the sheetrock, screw in electrical outlets and fixtures, and so on.)

    Just like building a house has a natural sequence, so does the sequence of tools from code to deployment and it’s often referred to as the DevOps “tool chain”. This brief article isn’t intended to cover each area of the typical DevOps tool chain (I could have also added bug tracking, automated testing, and other categories too), the point is you need to take time to define what the DevOps tool chain should be for your organization and to do so intentionally with a purpose, taking into account the tool investments your organization already has, the needs and skillsets of your organization, and your own practical budget realities.

    Do you have experience in using and self-supporting open source tools or do you have a preference for commercially provided tools?, Are you comfortable having multiple requirements tools in different teams or business units, or do you want a single standard? Only you can answer these questions for your organization. There is no prescriptive formula for these types of DevOps tools, although I’ve mentioned a number of commonly used ones.

    Tools that Amplify Work Across Teams

    The second area you should focus on are tools to help coordinate work and amplify our abilities across teams, i.e. bridging the inherent gaps in the DevOps tool chain, a subject that has received less attention in the DevOps community to-date. This makes sense because it’s human nature to think first about our own function and team. However, this silo thinking is one of the core problems DevOps was developed to address; the long-time focus on tools for specific IT “work stations” has actually entrenched the cultural silos of development, QA, operations, and project office in IT. For example, most IT organizations have two totally separate systems for tracking issues – in operations, it’s the service desk application and for code issues in development it’s the bug tracking application – and there is little or no relationship between them. In fact,  you are lucky if an incident in the service desk can be tied to a bug tracking number.

    If we are adopting DevOps in order to optimize the flow of new software releases to support business agility, then we need to look at how we will coordinate work and avoid information distortion and loss when different teams are using different, disconnected tools. In addition to your tool strategy for optimizing individual DevOps workstations, therefore, you also need to have a strategy for the tools that are going to help you effectively manage flow across those workstations.

    Most DevOps transformation efforts start small with a core team of perhaps a dozen or so members, and their often located in one physical location. In this scenario, you might be able to make do with regular face-to-face meetings and general-purpose communication tools like email, instant messaging, and a SharePoint site or Wiki with MS Office documents. The scope of your cross-team collaboration tools aligns with the scope of your DevOps effort and you might be able to rely on people interactions to unify the tool chain.

    But as you scale your DevOps efforts to larger, distributed teams across time zones and multiple business units and applications, your cross-team tools approach should scale as well. The point-to-point nature of instant messaging, ignored reply-all emails, and SharePoint ‘document dumps’ aren’t effective in coordinating the efforts of dozens or hundreds of developers, testers, admins, and project managers.  Information gets lost, information gets overlooked, and the gaps in your tool chain expand. A feature misses a commit and doesn’t get into the build and isn’t deployed. An operational requirement is missed so the test environment isn’t configured properly and the release gets pushed. Three weeks are spent solving a performance issue through code when it could have been addressed faster via hardware. A legacy application dependency in production is overlooked and the new mobile app doesn’t work in production as it did in test.

    There is an emerging class of purpose-built IT collaboration tools, such as ITinvolve, that enable the creation of cross-team workspaces where information is proactively shared as IT teams and tools get work done. This helps large, distributed cross-functional teams collaborate more effectively with each other in-context to raise questions, provide answers, and incorporate what’s happening up and down the DevOps tool chain in their individual work.

    For example, the developer will have better visibility into when the next build is going to occur and can ensure the feature is committed in time or can reach out to the build engineer in the workspace to request a delay in order to ensure the feature makes it in. The operations engineer can have earlier and better visibility into operational requirements so he can ensure the test environment is configured properly and avoid unnecessary delays. The legacy application dependency in production can be reproduced in test to ensure the application works properly once moved to production. And so on. By eliminating the handoff gaps and information loss across the DevOps tool chain, you can reduce risk of communication issues, solve problems more holistically rather than individually, and better achieve the goal of improving business agility.

    In the final part of this series, I will bring together the themes of the first three articles to demonstrate how you can chart a DevOps plan based on your Applications, your Culture, and your Tools to A.C.T. with greater agility.

    About the Author

    matthew Matthew Selheimer is Chief Technical Evangelist and SVP of Marketing at Houston-based ITinvolve. Reach him at matthew@itinvolve.com

     

  • DevOps’ Chicken Or Egg Origins

    DevOps’ Chicken Or Egg Origins

    When acolytes explain the DevOps movement to the uninitiated, they usually run into a chicken and egg line of questioning. What is DevOps, really? Is it a culture? Is it a pattern of processes? Or is it a technology? What comes first?

    The ratios of the perceived importance of each of those elements may shift depending on who you talk to in the DevOps community. But the inevitable answer to these questions is usually that DevOps depends on at least a little of all of them, but probably on culture above all else.

    “I think it’s first and foremost cultural. The development team is a tribe. So is operations.  They have norms.  They have things they value.  They have things that they reward and admonish,” says Josh Corman, chief technology officer for Sonatype, a component lifecycle management firm. “Developers are incentivized to cause change.  And ops people are incentivized to prevent change, to promote stability.  So they were natural enemies.  And when they work it out and align to each other’s tools and incentives, they’re able to go faster.”

    Therein lie the historical roots of DevOps, agrees Andrew Storms, senior director of DevOps at cloud security firm CloudPassage, who explains that it is an answer to the blame game that inevitably occurs in the old model.

    “I think that existing corporations or companies or groups are probably doing DevOps in response to existing pain,” he says, explaining that in previous non-DevOps shops he worked at, it was inevitable that development would write a piece of code, throw it over the fence and let ops catch the heat when trouble brewed. “The question is, why is the person at the end of the train always feeling the pain for something that originated at the beginning of the train? To me, DevOps says, ‘There is no train.’ There’s no more division of who’s in trouble for anything. Everybody is on the same darned team.”

    It’s for this very reason that Jez Humble, a principal for the consultancy ThoughtWorks and co-author of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, says that the fundamental ingredient to successful DevOps is trust.

    “You need to trust each other. Developers can’t just assume the ops people are all dumb and don’t know anything about code or are just command line monkeys. And the ops people can’t assume the developers don’t know anything about how systems work in real life,” he says. “These assumptions make it all a big finger-pointing exercise.”

    A lack of trust is the underlying roadblock to better teamwork between dev and ops, but it can be difficult to achieve within enterprises.

    “In small organizations people trust each other because they can see each other and work with each other and must learn to trust to get anything done,” he says. “But as organizations scale you lose that human contact.”

    It’s replaced instead with brittle and bureaucratic processes that only feed into those distinct walls between each tribe. However, as organizations feel the pain that’s inflicted by those bureaucracies that have evolved so far in IT and by the walls thrown up as a result, they face a choice. Engender that trust and a culture that allows  dev and ops to simplify processes and tear down the walls, or face further roadblocks that will hurt the business.

    From there, it is a matter of establishing behavioral and process patterns that are a hallmark of DevOps cooperation.

    “I think ‘patterns’ is the right word for it. People get hung up on this textbook or technical definition of DevOps.  And while there are certain common processes and things like Kanban boards and Scrums, and sometimes it’s a hybrid of Agile, sometimes not that ,” Corman says, “what matters the most is an attitude to fail fast and iterate, to continuously look for ways to increase flow, to automate, instrument and find and root out weakness. And to be responsive to new ideas of the business, or new ideas of your install base, or new market pressure.”

    According to Corman, the beauty of DevOps is that it’s a ‘jump ball’ for IT, so there are no set processes that make or break whether a shop is DevOps or not.

    “It’s in a state of flux, and the cement hasn’t dried.  It’s a singular opportunity to redefine the way we engage with the business and drive value, the likes of which we will not see again for 30 years,” he says. “It’s very, very rare.”

    And while few within the DevOps community would say it is defined by technology, it certainly is enabled by it.

    “To me it is more a cultural shift than a tool shift, but that tools shift presents a huge change in the way IT runs,” Storms says, explaining that instrumentation and orchestration tools like Puppet and Chef makes it possible to achieve continuous improvement and fast iterations. “So does it come about through the cultural change or the technical change? I think, actually, neither. I think it happens at the same time. That’s the force multiplier, that two plus two equals five kind of thing.”

    But like tectonic shifts, changes in IT happen sometimes all of a sudden, but mostly in increments.

    “One part of it is focusing on what we can do every day to make things a little better for everybody. You have to proceed incrementally and accept that it’s going to take time,” Humble says. “You can’t say, ‘Well, we’re going to adopt Agile now across the whole organization—go!’ There has to be enthusiasm from the people on the ground to do this stuff and then you have to work together though a process of experimentation and trial and error to work out how to make it work in practice, probably with a small group of people initially.”

    Even with that force multiplier, Storms says, you’ll still see positive steps forward by establishing an element of DevOps one at a time.

    “Even if you’re in a difficult situation where you can’t have the force multiplier of culture and technology changes at the same time, just one or the other is still going to be a big win,” he says. “Let’s say you just took the one piece of ‘Let’s move our dev and ops teams together and make them be friends,’ you don’t necessarily have to orchestrate and instrument like crazy to win. But you can also do the opposite and just picked the orchestration piece and say, ‘Hey, ops people, stop doing things by hand.’ You send them to Chef conferences and make them learn Ruby and guess what? Their skill sets just went through the roof.”