devopsy.kinsta.cloud

Category: Features

  • DOES 15 videos – Adrian Cockcroft

    DOES 15 videos – Adrian Cockcroft

    At this years DevOps Enterprise Summit we were very happy to partner with Gene Kim’s IT Revolution and Electric Cloud to conduct on site interviews with just about all of the speakers from this years conference, as well as many other attendees. All in all devopsy.kinsta.cloud conducted something like 86 video interviews over the 3 days of the Summit.

    Over the coming weeks we will be highlighting some of the best of the best here for you. We will present them in different formats.Some will have commentary around their sessions, others will feature background info on the topic and speaker and finally we will have updated info for some of the others.

    In that vein I wanted to lead off the series with this interview of none other than Adrian Cockcroft of Battery Ventures and formerly Netflix. My conversation with Adrian touches on really just three questions:

    1. What was his presentation about: Systems integration or systems thinking. It offered an inside look at the Netflix culture and talent density.
    2. what did he think of DOES 2015 – Adrian is on the program committee though by his own admission he was a bit pre-occupied on other business this year to help too much. But like many who attended Adrian is was really impressed at how deep the penetration into different verticals were.
    3. What does he see in the next 3-5 years for DevOps? Adrian says that companies that don’t adopt DevOps ways run the risk of disappearing.

    if the short 7 minute interview above wasn’t enough, here is Adrian’s complete session at DOES 15 (warning it is 31 minutes long)

     

  • PuppetConf 2015 attendees solve problems, change lives with DevOps, automation

    A thriving community of more than 7,000 IT professionals gathered online and in-person for Puppet Labs’ annual PuppetConf 2015 event recently to learn how leading global enterprises such as Uber, Walmart and Wells Fargo develop strong organizational cultures and leverage DevOps, automation and other modern IT tools and practices to solve problems and build high-performance data centers serve millions of customers and “change lives.”

    pic1

    The art of life-changing problem solving through automation isn’t lost on Puppet Labs’ customer Walmart. Senior Technical Expert Martin Jackson quoted a colleague who foresaw the benefits Puppet Labs would deliver when it first started using the company’s IT automation software, “‘We’re going to change lives with this,’” a prophecy he said has been fulfilled.

    In tangible terms, the life-changing results he spoke about to the capacity audience were measurable. With Puppet Labs automation software, Walmart went from having relatively few nodes managed through automation to a whopping 48,000 in a short period.

    pic2

    Walmart Senior Technical Expert Martin Jackson presenting at PuppetConf 2015

    With this level of automation, Jackson said his organization has been better able to support Walmart in achieving its goal to serve millions of customers at the lowest possible price.

    Most consumers, or even business end users for that matter, don’t think much about what goes into processing something as a simple as a banking transaction from a mobile device or computer. But PuppetConf attendees know there is a complex spider web of tech behind making an app as common as one used for online banking work.

    Wells Fargo, the world’s largest bank by market capitalization, is a Puppet Labs customer leveraging automation technology for application orchestration, automation of node configuration and application deployment.

    Using “Back to the Future” as his metaphor, Wells Fargo DevOps Manager Nate Loomis talked about the need to be on the cutting edge of IT, while also keeping services to customers reliable and dependable. When Wells Fargo IT shifted from a node-centric view to an application-centric one, its provisioning started moving much faster — from months to the time it takes to get a cup of coffee.

    With Puppet Labs, Wells Fargo manages 120,000 nodes and 55,000 network devices to process more than 1 billion transactions daily, hosts more than 2,300 applications in production with more than 40 percent of its operations fully automated.

    pic3

    Wells Fargo DevOps Manager Nate Loomis presenting at PuppetConf 2015

    Culture Matters

    DevOps is more than just tools. While addressing the crowd at the Portland Convention Center, Uber’s Head of Business Intelligence Komal Mangtani emphasized that its IT culture pushes engineers to experiment in the name of progress and to constantly be on the lookout for new ways to solve problems.

    pic4

    Uber Head of Business Intelligence Komal Mangtan presenting during PuppetConf 2015

    With a picture of The Martian leading man Matt Damon on the jumbo screen, Mangtani borrowed a line from the film when she told attendees, “If you solve enough of the right problems, you get to go home,” a humorous reference to wide-spread use of Uber by patrons to get rides home that wasn’t lost on the crowd. She emphasized that while most people think of Uber as an app, ride and car, there is much more to it than just that — pointing out that that within its IT culture is a dedicated team of “fierce yet humble” engineers that are helping the company to deliver more than 1 million rides, daily.

    Summing Things Up

    pic5

    Although he opened the conference, Puppet Labs founder and CEO Luke Kanies summed up the whole point of IT automation and DevOps during his keynote which included a live demo of Puppet Application Orchestration. While addressing the conference, he told the crowd, “We at Puppet Labs are here to help you get there. As a company, we are all about reducing the timeline from the moment you get new technology to the moment it’s in the hands of your users delivering real value. You are going to see us as a company evolve over time to get better and better at aligning the tools we provide and the work we do enable with helping you more directly, more consistently and more repeatedly delivering customer value.”

    For a more in depth look at PuppetConf 2015, visit the blog: https://puppetlabs.com/blog/puppetconf-2015-day-1-back-to-the-future-with-application-orchestration

    Watch the keynote: https://puppetlabs.com/presentations/puppetconf-2015-lukes-keynote-address

  • DevOps and ITIL: It’s Not Your Mother’s ITSM!

    DevOps and ITIL: It’s Not Your Mother’s ITSM!

    I recently had the privilege of attending the DevOps Enterprise Summit hosted by IT Revolution and Electric Cloud. There was much to learn about emerging enterprise DevOps practices, some of which I will cover in future articles.   For now, I would like to share one of the biggest epiphanies about the relationship between DevOps and ITIL/ ITSM.

    Since DevOps came on the enterprise radar, there have been numerous articles, webcasts and whitepapers trying to create a bridge between ITIL and DevOps. Some suggest that ITIL has passed its prime – its an out dated framework that was designed for waterfall service lifecycles. Others claim that you can’t do DevOps without underpinning control and release processes. While there is some truth in all of that, several of the presenters at DOES15 did reference ITSM processes and confirmed that service management is alive and well in DevOps. However, what became equally clear is that this is not your mother’s ITSM!

    The modern IT environment expects processes that support transformational initiatives and enable rapid development and deployment. So while a process like Change Management was mentioned in several sessions, there was little focus on a Change Advisory Board or requirements for requesting a change. In fact, when one presenter proudly displayed their “change record”, it looked nothing like the ITSM database record of yore. The modern change record may resemble more of a running date stamped commentary that a collection of fields. This does not imply that you should no longer have a CAB. It implies that it is more important than ever to build change models based on risk and need that encourage more standard changes. Similarly, while there is much talk in DevOps about configuration management, it now occurs throughout the entire delivery pipeline and uses automation and mechanisms for managing configurations in real-time instead of through discovery methods. Configuration management tool integration is critical between Dev and Ops.

    Processes like incident management and problem management are benefitting from the increased use of monitoring and the emerging DevOps practice of ChatOps.    Dynamic chat rooms not only encourage stronger collaboration between Dev and Ops, they modernize the ability to quickly detect, investigate, diagnose and resolve incidents and problems.   As one presenter pointed out, ChatOps tools allow the collaborators to bring the environment into the discussion. They can not only chat, they can see. The modern service desk may also find that ChatOps creates almost instant escalations at the point of detection instead of the point of customer contact.   That’s cool.

    Finally, a practitioner presentation did a fantastic job of demonstrating how they were able to marry their ITIL processes to Agile practices. There is no doubt that service management must evolve into Agile Service Management in order to be of value to continuous delivery pipelines. Putting an operational person on a Scrum team could be a good first step.

    So what does all of this mean? Do you now need to throw away the ITIL books, replace your ITSM tools and start rebuilding processes? No.  Many of the DevOps automation providers have built APIs between tools and into service management products such as ServiceNow or Remedy. Frameworks such as ITIL already do a good job of describing the key processes that have to underpin the service lifecyle, including the continuous delivery pipeline. However, the very nature of a static publication library makes it difficult for enterprises to look to the ITIL books to keep current..

    So the time has come to heed the age old ITIL advice to “adopt and adapt”. To learn more about DevOps enterprise practices, to scale and integrate with the guidance from ITIL, Agile, Lean and other frameworks. To enable a delivery pipeline that meets changing business requirements and removes constraints across the IT spectrum. And to realize that next-gen ITSM is here!

  • Chef rolls out some tasty new dishes

    Chef rolls out some tasty new dishes

    Chef has announced some major additions to their lineup today. We will look at each of these but in total here is the news from Chef today:

    Screen Shot 2015-11-03 at 12.25.29 AM

     

    First of all the previously announced Chef Delivery is now in GA for everyone. Chef Delivery defines and manages the entire DevOps workflow. The diagram below is a good illustration of this:

    Screen Shot 2015-11-03 at 12.27.28 AM

    According to Chef, Delivery, “provides a prescriptive process to automate changes to infrastructure, applications and containers in a single prescribed pipeline.”

    Beyond the general availability of the previously announced Delivery, Chef also announced that they are moving into services in a big way. They are spinning up a new DevOps transformation practice to help enterprises adopt DevOps and transform their models. Justin Arbuckle, chief enterprise architect at Chef is heading up this new practice.  I would assume they will compete with professional service organizations like IBM, HP, PWC and others in helping large enterprises transform and adopt DevOps practices. It is a natural move for Chef as it continues to mature along with the DevOps market in general.

    Finally, Chef is going to roll out compliance as code, part of something Justin Arbuckle has spoken to me before of compliance at velocity. In order to bring this capability to market Chef has bought a smaller German security provider called VulcanoSec.  VulcanoSec has done a good job of developing a shift-left security product that allows for continuous compliance. I am sure we will see the Chef team expand this as they seek to bring more and more security into the DevOps process and they see opportunity for improving the entire development/deployment environment to make it more secure. They will also have to integrate and work with existing enterprise security solutions.

    All in all this is quite a series of announcements from Chef, which were made at the European Chef Community Summit in London.  Chef has been a leader of the DevOps movement from the very start and they continue to show that they will continue to lead and innovate in bringing DevOps and everything as code to enterprises everywhere.

  • Avik Partner’s Grok APM Uses Machine Learning to Find Anomalies Early On

    Avik Partner’s Grok APM Uses Machine Learning to Find Anomalies Early On

    Machine Intelligence-Driven Anomaly Detection

    Machine learning—the science of getting computers to take thoughtful action without explicit programming—is the basis of Machine Intelligence-Driven Anomaly Detection, which is the core capability in Avik Partner’s Grok APM product, according to Casey Kindiger, veteran enterprise software solutions provider, IT automation expert, and founder of Avik Partners.

    “Thoughtful action means using the type of faculties that a human being would use to make a decision and to take an action,” says Kindiger, who has more than a decade of experience in designing and developing process automation solutions for companies such as JP Morgan Chase, T-Mobile, and Allstate Insurance. Grok learns from your dev and ops environments and takes thoughtful action to detect anomalies, all in the service of Application Performance Management.

    Grok works by analyzing real-time performance data from apps and infrastructure, looking for behavioral bumps in an otherwise smoothly-paved DevOps highway of deployed services and underlying infrastructure.

    Grok’s Pre-Event Inferences

    “Grok uses common statistical techniques to learn a pattern over a selected period of time in order to build a dynamic threshold of the continuously changing underlying patterns,” says Kindiger. In this way, Grok can establish a sort of dynamic baseline from very noisy patterns, which is something that would typically take a number of person hours of involved statistical and predictive analytics to accomplish.

    Grok’s machine intelligence leverages the ability to make inferences based on this dynamic baseline information like a human being would in order to reason out a logical conclusion. Grok does this to detect the slightest of anomalies based on the difference between what reasonably should have happened and what actually did happen. Using this approach, Grok detects subtle patterns of significance in streaming data despite the fact that the data has patterns that are continuously in flux.

    But rather than detect when something has gone wrong at a point in time, which is not scalable or sustainable, Grok looks for minute patterns that appear well in advance of any issue that you would normally consider looking at with traditional APM mechanisms, explains Kindiger. Rather than send alerts based on threshold-based exceptions, Grok makes a prediction on what the next data point or the next series of data points will be and then looks at deviations from those predictions, considering whether to flag those as anomalies, according to Kindiger.

    Currently, Grok is particularly tuned to analyze streaming data and is, according to Kindiger, data-point agnostic. “We don’t need to teach the system what the context of a particular data point is. The system learns the context of the data over time and the subtle nuances of the pattern that produces over time, and creates the model based on that,” says Kindiger.

    Watch Out for That Initial Two Week Delay

    If Grok does everything that Avik Partners’ Kindiger hypes that it will, DevOps teams will soon be able to catch and act on infrastructure issues before they grow big enough for end-users to notice.

    But Grok does have one wrinkle in its APM armor: it takes time for it to really learn a new customer system and get good at detection. Let’s assume that Grok’s machine learning causes it to get better at detecting anomalies in a given set of infrastructure over time. That means that there’s a point, at the beginning, given a brand new customer when Grok only starts to learn. At that point, Grok isn’t very good at knowing what’s anomalous compared to what’s normal for that infrastructure because Grok has no foundation for that particular system.

    “Grok will take some time to learn the nuances of when to escalate an issue. We’ve learned from experimentation that it gets pretty good after ingesting two weeks’ worth of data,” says Kindiger. Because Avik Partners initially targeted AWS, it has taken two weeks of CloudWatch data and fed that to Grok to provide it with some backdrop so that when Grok goes live, it won’t be learning this environment entirely anew.

  • Continuous Delivery versus Continuous Deploy

    Continuous Delivery versus Continuous Deploy

    Getting a solid grasp on the meaning of DevOps requires a clear understanding of the terms used to describe it. Over the last several years, we have seen a paradigm shift in the way software is developed, moving away from a waterfall approach, with monolithic releases, to an agile approach with incremental releases.   This shift has changed the way in which the Application Lifecycle (ALM) is managed. Focus around what we normally would refer to as ALM is now more accurately described as Continuous Delivery. Continuous Delivery is not a set of tools, it is an emphasis on people (culture), tools and processes. The change from ALM to Continuous Delivery includes three very basic principles:

    • The software is always deployable which means you prioritize keeping the software deployable over adding new features. To do this requires smaller, less risky changes released overtime instead of all at once.
    • A feedback loop of the build, test and deploy steps expose the readiness of the software allowing anyone from development, test or production to determine that an immediate release of the software to any environment can be approved.
    • Automation of the build, test and deploy process is critical in order for the process to be repeatable and to support a higher frequency of builds, deploys and test cycles.

    So like ALM, there is an awareness of a lifecycle (Dev, Test, Prod). But unlike ALM the lifecycle should not be seen as linear. With Continuous Delivery, a software update may move from Development directly to Production without having entered the Test phase. Because Continuous Delivery principles support keeping the software in a deployable state, with a visible feedback loop to determine the readiness of the software, software can be confidently moved into any environment at any time.

    This change between a linear, waterfall approach, to an non-linear agile approach is far more realistic in the way organizations manage their software. Over the course of my 20+ years’ experience working with both large complex enterprises and small software teams, the need to be able to perform a release, into any environment at the ‘drop of a hat’ has been consistent and problematic. The principles behind Continuous Delivery defines a more realistic approach to software development.

    Moving from a linear application lifecycle approach to Continuous Delivery includes making changes at many levels. First, developers must begin embracing Agile practices, managing smaller, incremental releases. Because Agile increases the frequency of builds, testing and deployments, DevOps tools must be in place to support the automation of these tasks. In the waterfall approach, teams had the luxury of time to get build scripts to work, execute test manually, and write a deploy script for every environment. Continuous Delivery does not offer that luxury therefore automation of these tasks becomes critical. This is why Continuous Build, Continuous Deploy and Continuous Test tools are implemented. Continuous Build addresses the frequent building of code changes, updating binaries upon a check-into version control, and reporting on what artifacts were impacted providing feedback into the readiness of the build.

    Continuous Deployment automates the movement of those binaries to any endpoint in any environment and supports server configuration management, all performed on an incremental basis with feedback showing the inventory and the changes. Continuous Test automates testing so developers and/or testers can run through critical functional test, and code analysis to provide feedback on the readiness of those binaries.

    To maximize on automation, these steps are chained together using the workflow engine of the Continuous Integration Server. The workflow can be triggered upon a source code check-in, kicking off a compile/link (build), running code analysis, deploying to an endpoint and running test. In Continuous Delivery, each environment may have their own Continuous Integration workflow that performs the steps needed. For example, a Production CI workflow may just perform activities related to moving the code to hundreds or thousands of endpoints, with database updated, but not execute a build or test.

    Not all is perfect in the Continuous Delivery approach. Automation continues to be a bottleneck. As with most paradigm shifts, changes in behavior and adoption is a major hurdle. In most companies, the use of manual scripts to perform builds, deployments, test automation and manage infrastructure are still called under the covers of the Continuous Integration workflow. These are the same scripts that were used in the waterfall approach, except now there is not the luxury of time to fix the scripts or update them to adjust to software changes. To support Continuous Delivery, the build, deploy, test activities must be elastic, automatically adjusting to code changes, database updates and server configurations.

    To create a more dynamic Continuous Delivery process, DevOps tools are moving away from the need for coding one-off scripts and instead moving to a model driven approach with Playbooks and Plug-ins. Many developers still hold on to these scripts with the argument that they do not want to be at the mercy of a ‘vendor’ or ‘tool’ to manage these low level tasks. As Continuous Delivery pushes the frequency of releases, this final paradigm shift, moving away from the old approach to one-off scripting, will need to move into full automation. Continuous Build will be supported by Build Automation, Continuous Deploy will be supported by Application Release Automation and Continuous Test will be supported by Testing Automation and Virtualization. The automation tool chain will be orchestrated via a Continuous Integration Server and the entire process will become a reliable and fast Continuous Delivery process.

    About the Author/Tracy Ragan

    tracy-clr-128x124pixelsMs. Ragan has had extensive experience in the development and implementation of DevOps for large organizations. She began her consulting career in 1989 on Wall Street specializing in build, testing and release management for the distributed platform. It was during her consulting experiences that Ms. Ragan recognized the lack of standardized development procedures on open systems that was common on the mainframe. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She has been published on numerous occasions and regularly speaks at conferences including CA World where she presented for 15 consecutive years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.

  • APM Prepares Prep Sportswear for Promising Growth

    APM Prepares Prep Sportswear for Promising Growth

    Prep Sportswear kicked off in 2003 and appeared either in the Inc. 500 or Inc. 5000 list of fastest-growing private U.S. companies six years in a row, from 2009- 2014, according to online data from Inc. Magazine. The custom sportswear vendor has achieved 130-percent growth over the past three years, says Mike Jones, Director of Technology, Prep Sportswear.

    Prep Sportswear clothes more than 200K US schools including most middle schools and high schools with custom-printed sportswear for their school sports teams. Prep Sportswear maintains a catalog of each school’s logos so that teams can create their own shirt or jersey representing that institution and team using its colors and logo or mascot. “So you can create a jersey and for me it would be for the class of 1986, Lake Washington High School, and you would see that Kangaroo on the back or on the front,” says Jones.

    The custom-printed sportswear firm serves local teams not affiliated with schools as well as golf courses, colleges, and religious groups. Each customer gets its own store, and Prep Sportswear now maintains more than 2M stores.

    Prep Sportswear: Small Team, Big Technology Play

    Prep Sportswear produces its own sports goods and maintains manufacturing and attendant technologies while also serving ties to firms such as Active Network and others that use its API.

    “We support retail customers, consumers, and our own plants and equipment. On the technology side, we do that with a very small team of ten people. They cover the e-commerce site, our API, and manufacturing needs,” says Jones.

    Prep Sportswear programs its codebase and platform using C# and .NET. It also provides for manufacturing components such as ink and vinyl printers and embroidery hardware. Prep Sportswear manages its supply-chain and its related processes and mechanics. “We do it all in-house despite the fact that it is such a large system with a number of components,” says Jones.

    How Prep Propped Up DevOps

    When Michael Jones arrived at the company, the CTO was deploying releases directly to production from his laptop. “We didn’t have a DevOps team really until Richard came on board,” says Jones, speaking of his colleague Richard Dominguez, Developer in Operations, Prep Sportswear; “before that we were running in start-up mode, just kind of out of a garage until recently.” Richard describes the technical setting when he came on board.

    “A lot of the automation they had was not really automation but little scripts that they ran individually,” says Richard Dominguez, Developer in Operations, Prep Sportswear; “when we released something, we had no idea whether it would break.” At the time, there were few tests on software and there were no external tests at all.

    The Arrival of Change

    With Richard at hand, Prep Sportswear ultimately adopted TeamCity for CI for deploying to its test and production development stages.

    The company also added the Selenium browser-based test suite, coded in Java to run the user-based interactions to determine what the user experience is like. “It checks to see that the page and elements load properly when a user clicks a link,” explains Dominguez.

    Richard found Dynatrace installed when he arrived but not in use. He revived it as the main APM for front-end monitoring. “We also use another tool a lot for our internal monitoring of infrastructure on the back-end and that tool is PRTG,” says Dominguez.

    DevOps Done Right Brings Cheers from the Sidelines

    The combined revenue from all channels last year was about $23M, says Jones. “Since Richard came on, we’ve seen a decrease in time to resolution of more than 50-percent just by having the APM and other tools,” says Jones, with reference to Richard’s revival of Dynatrace and addition of the other aforementioned tools.

    Up times have improved by .50-percent as well. “That stems from simply being able to find an issue and resolve it faster. For an e-commerce site where we don’t have any sales people, it’s just the website, that additional up time is very important to us,” says Jones.

  • The DevOps Dozen

    The DevOps Dozen

    After over 2500 votes cast in the final round and almost 5000 votes in total we are very proud to present the winners of the inaugural DevOps Dozen awards. These companies were voted by you our readers as the top companies in the DevOps market. They are not companies that are necessarily using Devops internally (though many of them are and have had their own DevOps journeys).  They are the companies/organizations who are producing the tools and services that are helping make DevOps the force for change that it is.

    Also a quick word about all of the companies that we nominated for these awards. There were originally something like 100 companies to choose from. We then narrowed it down to the final 32.  Any one of the final 32 were worthy of being in this list. of the DevOps Dozen  At some point yes it is a popularity contest. Some companies are better at turning out their voters then others (just like in real elections).  But on the other hand there were some companies that didn’t campaign at all.  They are here because by consensus they belong here.  With so many votes cast, you have to believe that  the companies that made the final 12 do belong here.

    Congrats to the 12 companies/organizations listed below!

    (Please note that you can download

    [seoslides embed_id=”0e545f934454″ script_src=”https://devopsy.kinsta.cloud/embed-script/dd-finalists-final/10755/” overview_src=”https://devopsy.kinsta.cloud/slides/dd-finalists-final/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”DD Finalists Final” /]

    In the coming months we will hold additional DevOps Dozen awards for companies that are leveraging DevOps most successfully and for those individuals who are the current leaders of the DevOps movement. Stay tuned for those after the first of the year.

  • 7 Sets Of DevOps Success Metrics From DOES ‘15

    7 Sets Of DevOps Success Metrics From DOES ‘15

    Beyond the moral support, the executive management coaching and the tips on how to build DevOps momentum in the enterprise environment, last week’s DevOps Enterprise Summit 2015 offered a boatload of excellent fodder for those seeking to prove the value of DevOps patterns once they got back home.

    DOES wasn’t just about cheerleading—alongside lessons on the soft, squishy elements of transforming IT, nearly every speaker offered up stone cold numbers to back up why those transformations make business sense. The performance metrics shared by speakers were impressive and could go a long way toward swaying skeptical stakeholders. Here are some of the highlights.

    Ticketmaster

    Ticketmaster CTO Jody Mulkey offered a ton of excellent examples of how an organization-wide commitment to DevOps has fueled innovation and stability at his company. For example, he described how what Ticketmaster calls the ‘Boom Team’ has used a completely integrated team of devs, operations, QA and other staff of about 20 to shift its Ticketmaster.com property—which accounts for 40 percent of the company’s revenue—from a duct-tape and bubblegum affair with 2000 ModPerl at its base into a modernized system continuously delivered by that team. Similarly, its technical operations team has embraced the DevOps ethos in order to deliver what it calls ‘support at the edge’ for WebOps incidents. The success of this approach has resulted in:

    • 90 percent reduction in mean time to repair (MTTR)
    • MTTR from 47 minutes down to 3.8 minutes

    “This was a phenomenal change,” Mulkey says. “The business went crazy over this. These are measurable outcomes that have really helped demonstrate that we are making progress.”

    Target

    Target brought forward speakers to discuss the retailer’s innovation in a number of key areas. Heather Mickman, director at Target, talked about how her API team worked hard to not only easily expose product and store information via its APIs, but to also challenge itself in the way it was delivering its work.

    “We wanted to deliver new capabilities in days and not months,” she explains, saying the team needed to be sure that it could scale its APIs because it new that they would be highly reused—both internally and by partners. Target has:

    • more than 90 APIs
    • monthly volume of calls to these APIs have grown in one year from 1.5 billion to 17 billion
    • deploy 80x per week across stage and production enviornments
    • all that, with fewer than 10 incidents per month
    • this volume helped support in 2014 a 42 percent increase in guest traffic and 280,000 orders fulfilled on Black Friday alone

    HP

    HP CIO Ralph Loura says HP didn’t go for the big bang approach, but through careful pilots and the use of communication afforded by ChatOps infrastructure, his team has been able to drag HP IT slowly into the DevOps fray. That’s a good thing, considering the massive scale of the organization:

    • 7,000 developer and operations staff
    • handling over 20,000 change requests per year
    • supporting 1,400 apps
    • and 1000s of builds per day

    CapitalOne

    After four years of hard work to move toward DevOps and continuous delivery, CapitalOne Product Manager Tapabrata Pal had a number of impressive statistics to share on its its progress:

    • Code commits have moved from random occurrence to hundreds per day for any given product team
    • Integration has moved from 1 per day to every 15 minutes
    • QA performance has shifted from monthly to four times per day
    • Production releases have moved from quarterly to one per sprint
    • Defects have been reduced by approximately 60 percent
    • Feature delivery rate has increased by approximately 50 percent

    CSC

    Paula Thrasher, application delivery lead with CSC, stepped up in front of the DOES audience to show them how it is possible to battle bureaucracy at any organization—coming from the government sector, she has first hand knowledge of what it takes. In one example she shared, her organization helped a client move its cyclew time from automating deployments to staging:

    • from 12 hours down to just 12 minutes and 30 seconds.

    IBM

    IBM’s Angel Diaz, VP of cloud architecture and technology, talked about how enterprises can still innovate at the pace of startups while delivering at scale. The thing with IBM is that it puts its money where its mouth is when it comes to DevOps—the company has doubled down to not only offer a number of products viable for the continuous delivery pipeline but to also completely transform its own business through DevOps practices. Some of the results it has seen by shifting its 2,000-plus developers and 100-plus squads in the Cloud Services division to DevOps:

    • 300 percent increase in “pure coding time” for its Cloud Services developers
    • reduction of deployment time from 32 hours down at first to 6 hours and now to minutes
    • an increase of release frequency from months to every three weeks.

    Disney

    Disney’s Jason Cox, director of systems engineering, got the crowd pumped up with a slick mash-up video of Star devWars and DevOps themes (not to mention a private showing of the most recent Star Wars trailer at the end of his talk!). But he didn’t favor style over substance. In his talk he described how much success Disney has grabbed up through DevOps, including:

    • 75 percent reduction manual steps
    • reduction in deployment time for large online/digital experience systems from 3 hours to 20 minutes
    • ability to provision 300-700 srvers within 15 to 30 minutes
  • Devops Days Silicon Valley, you don’t want to miss it

    Devops Days Silicon Valley, you don’t want to miss it

    DevOps Days have become a global phenomenon. These are unique, community-organized events that bring together development and operations practitioners for two days of scheduled presentations, open spaces (more about that later), and networking.

    How instrumental to the DevOps movement are DevOps Days? “DevOps” actually got its name from the discussions that happened at the first DevOps Days organized by Patrick Debois in 2009 in Ghent, Belgium.

    The 6th annual DevOps Days Silicon Valley is happening on November 6th and 7th at the world-famous Computer History Museum. Silicon Valley is the oldest of the US events and was originally the third DevOps Days ever. Starting as a low-key event hosted on the campus of Linked-in in 2010, DevOps Days Silicon Valley has grown into a major event.

    True to past reputation, this year’s speaker lineup blends industry favorites, like John Willis, with a unique mix of soon to be well-known speakers who have been selected by the community. The 2015 line-up includes:

    • State of the DevOps Union by John Willis
    • Anomaly Detection 101 by Elizabeth A. Nichols
    • Not Everybody is Kelsey Hightower by Gregory Poirier
    • Securing the Heart of Automated Infrastructure by Jamesha Fisher
    • Caching Versioned MetaData with Git by Kirsten Hunter
    • Flaming Poo and the Human Response by Jason Hand
    • DevOps Army of One – How to Survive When You’re the SPoF by Jonathan Disher
    • Single Point of Failure… Expert by Sasha Rosenbaum

    But that’s not all! Unlike most conferences where the scheduled speakers are the main event, at DevOps Days, facilitating the interaction between attendees is the main event. Both afternoons are dedicated to Open Space, where the agenda is dedicated to small-group participant-lead discussion and the discussion topics are chosen on the fly each day. This is the chance to dive into specific topics, ask for help, discuss what you’ve done, find like-minds, or just be a fly on the wall and take it all in.

    The DevOps Days experience is one that is unique among technology events — from the local community driven organizing (each one is totally run by local volunteer organizers) to the 50% of time dedicated to Open Space discussions. The whole point behind DevOps Days is to push those with fresh knowledge and insights, no matter how small, into direct contact with those who can benefit from or add to it.

    Of course there is a good bit of fun involved as well. Evening events, ignite talks, and the seemingly cult-like status of the locally designed t-shirts all add to the unique flavor of a DevOps Days event. Austin 2015 was famous for their dueling social themes of Star Wars (May 4th / “May the Force” day) and Cinco de Mayo (complete with large Mariachi band).

    If you are in the San Francisco Bay / Silicon Valley area, get your tickets for the November 6th and 7th DevOps Days Silicon Valley ($150) before they sellout. If you live elsewhere, be sure to keep an eye on the main DevOps Days site for upcoming events. You can also watch presentations from past events on the DevOps Days video site.

    About the Author/Damon Edwards

    41368124db43a27257c31df174a61357_400x400Damon Edwards is the co-founder and managing partner of the DTO Solutions, a DevOps and automation engineering consultancy whose clients include leading SaaS, e-commerce, gaming, and financial services companies. Damon Edwards is also the co-founder and vice president of SimplifyOps, a provider of support and services for the users of the Rundeck open source project. Damon has spent over 14 years working on both the technology and business ends of IT operations. Damon is also a frequent conference speaker and writer who focuses on DevOps and operations improvement topics. Damon is active in the international DevOps community, including co-organizing the DevOps Days conference series, co-hosting the DevOps Cafe podcast, and a co-author of the upcoming DevOps Cookbook from IT Revolution Press.