Tag: survey

  • Challenges in DevOps Standardization

    Challenges in DevOps Standardization

    Many organizations still face challenges in their Devops adoption journey enterprise-wide, especially when there is no standardization in tools, non-repeatable processes and adhoc practices and culture barriers. Here are some of the challenges in standardization and possible solutions to achieve standardization in DevOps as part of DevOps transformation journey.

    Business Case

    A survey conducted within multiple customer teams revealed they face challenges in standardization of tools and streamlining the process gaps due to lack of end-to-end orchestration, manual intervention, legacy practices, inconsistent environments, longer provisioning time and several other factors. Taken together, they necessitate standardization in DevOps across the enterprise to make it repeatable, predictable and consistent.

    Challenges in Standardization of DevOps

    Tools Challenges

    1. Multiple tools to evaluate with one or more overlapping features in the tools, learning curve involved to evaluate/do proof of concept and choosing the tools with short-term goals instead of long-term perspective.
    2. Limited knowledge of tools, used from the perspective of automation in their specific area, resulting in siloed automation and using manual, ad hoc process.
    3. Lack of out-of-box integration with most tools used in the CD pipeline and teams investing time to build custom integrations.

    Process Challenges

    1. There is no central DevOps team who can evaluate and recommend the right set of tools to be used, with individual project teams/groups try to set up their desired tools and serve their teams (Dev/QA/Ops), with no clarity on availability of infrastructure that can be shared across groups.
    2. There is no defined process framework detailing the different tenets in DevOps, including what activities and approach are needed to move to desired state, leaving teams to achieve their desired state of automation without a structured approach.
    3. There is a lack of knowledge on defining right KPI for each DevOps capability and how to measure the metrics to determine efficiency of the DevOps automation process and identify scope of optimization.
    4. There is a lack of SME knowledge on the application, application stack and environment management flowing between Dev and Ops teams to arrive at a standardized process.
    5. Multiple vendors are managing the different stages of an application and each following their own defined process for development life cycle.

    Cultural Challenges

    1. Standardization on metrics, process, practices, governance and organization-level control over DevOps implementation is challenging without a central authority (a central DevOps team) driving these practices across the enterprise.
    2. Teams operate in silos and follow their own DevOps practices and think in silos without having a holistic view, resulting in broken processes that are inconsistent.
    3. Teams still lack training in DevOps on the tools, practices to be followed in CI, continuous testing, continuous deployment and operations. Lack of DevOps skilled resources/expertise brings challenges in implementing end-to-end automation.
    4. DevOps is considered a concept, with every DevOps implementation unique for every organization and no standard approach for adoption of DevOps, causing confusion where to start and how to start. In addition, there is a conflict of interest and power of influence from multiple stakeholders while standardizing on tools.

    Proposed Solution(s)

    DevOps Adoption Framework (DAF)

    DevOps adoption framework (DAF) is a comprehensive framework for due-diligence, tools support and solution accelerators to create systematic and well planned-out transition road map and implement a continuous delivery toolchain and overcome the common challenges in DevOps implementation.

    Choosing the Right Set of Tools and Stack

    Tools selection should be based on the requirements and what best suits the need, decided based on various factors discussed in the attached whitepaper, and using one of the methodologies such as points given for out of box features and different factors/constraints.

    DevOps Automation Platform with Template-Based Infrastructure and Toolchain Orchestration

    DAAS (DevOps as a service) is an automation platform, which serves as a central platform to drive standardization across tool use, provisioning infrastructure, toolchain, managing the life cycle of VMs, bringing in central authority and governance, defining the KPI, monitoring and measuring the metrics, monitoring end-to-end pipeline giving real time analytics, providing self-service capabilities across multiple teams, bringing in audit and compliance, continuous improvement and drive consolidation and standardization.

    Future Direction

    • Increased focus on standardization of DevOps metrics with analytics and monitoring to identify the bottlenecks early and big data used for predictive analytics through the delivery pipeline.
    • Rapid DevOps adoption across the enterprise, with standardization and consolidation critical factors for scale, compliance and utilization with self-service DevOps automation platform enabling end-to-end pipelines.

    Conclusion

    The critical success factors for enabling DevOps adoption across enterprise needs focus on central DevOps team driving DevOps adoption with governance enabled with DevOps adoption framework and consolidation of the processes, standardization on metrics and tools, enabled with a DevOps automation platform.

    For a deeper look at the survey, download the white paper here.

    About the Author / Lavanya Subbarayalu

    Lavanya Subbarayalu is Senior Architect working with Technology Office in HCL Technologies. She has expertise in Azure, DevOps consulting & Microsoft technologies. She is associated with DevOps COE, working on design and Development of DevOps solutions and consulting tools. Connect with her on LinkedIn.

  • Where Does the Database Fit into Continuous Delivery?

    Where Does the Database Fit into Continuous Delivery?

    Continuous delivery (CD) is increasingly becoming the norm in software development, with companies releasing updates more and more frequently. Those that aren’t are exploring how they can catch up. But in all of this push to DevOps and CD, it’s vital not to forget the database. Changes to applications or web services often require changes to the database, which means companies need an end-to-end process that spans both application and database development if they want to successfully embrace CD.

    However, many companies still work in silos, with applications and databases developed separately. So while the ability to deploy application changes across environments is relatively common, supporting databases in a truly elastic environment remains a major challenge for organizations.

    To find out the current state of database DevOps, and how it can be included in CD, Redgate surveyed 1,000 SQL Server professionals across the world. While we found companies were keen on implementing DevOps, with 80 percent saying they will have adopted it within the next two years, only 20 percent are currently applying DevOps practices such as version control, continuous integration or automated deployment to their databases.

    The Need for Change

    This isn’t because companies don’t recognize the need for database DevOps—37 percent said they are deploying database changes either more than once a week or daily, demonstrating a requirement for automation. Indeed, the main driver for adopting DevOps in this area is to increase the speed of database changes (cited by 26 percent of respondents), followed by freeing up developers for more added value work (17 percent).

    Companies also recognize the drawbacks of continuing traditional, siloed database development practices—26 percent said it increased the risk of failed deployments or downtime when introducing changes. This was followed by slow development and deployment cycles and an inability to respond quickly to changing business requirements (both 18 percent). Sixteen percent also cited poor visibility of the change management process as another issue. This shows the vital importance of fast, successful database changes and deployments to business today.

    For companies with 5,001-10,000 employees, slow development and release cycles were seen to be more of a drawback than application downtime, while for organizations with more than 10,000 employees, the inability to respond quickly to changing business requirements was deemed to be a slightly more significant downside.

    Moving to DevOps for the Database

    As well as understanding the business need, the survey showed that organizations are now better structured to enable continuous delivery for database changes. The old picture of companies made up of silos of developers and database administrators that don’t work together, for example, is far from the truth. Seventy-five percent of companies had teams that included developers who were working across databases and applications, with just 25 percent having dedicated database developers. In 60 percent of companies, developers were responsible for building database deployment scripts. Fifty-eight percent of companies said the integration between the two was either good (38 percent) or great (20 percent), meaning teams work together on a planned or ad hoc basis. Just 12 percent classed integration as poor, with DBAs working in silos.

    However, the research highlights two challenges to overcome:

    Different processes and tools—Despite the levels of integration within organizations, there is still a gap between how companies operate and automate when it comes to applications and databases. For example, while 81 percent of respondents use version control for their applications, just 58 percent apply it to database development. Thirty-nine percent use continuous integration for applications, yet only 20 percent apply the same practice to their database. Clearly, there is still more that can be done to bring the two together through common practices and the use of third party tools.

    The skills gap—The greatest obstacle to moving to an overall DevOps way of working was a perceived lack of appropriate skills (cited by 21 percent of respondents), ahead of a lack of alignment between the development and operations teams (20 percent). Only 9 percent said that their executive leadership didn’t support the shift.

    When it came to integrating database changes into the DevOps process, consistency was top of the list of obstacles, with 32 percent believing that synchronizing application and database changes would be the biggest challenge, followed by overcoming different approaches to application and database development (25 percent). Perhaps unsurprisingly, 19 percent also mentioned preserving and protecting business critical data as the largest obstacle to overcome.

    It’s Happening Sooner Than You Think

    The good news is that many companies are confident they can quickly overcome the process and skills challenges. When asked how long they estimated it would take their organization to move from traditional database development practices to a fully automated process for deploying database changes, more than half (51 percent) said it could be done within a year, with 20 percent believing it could be achieved in six months.

    Digging down into the data, those that have already adopted DevOps in other processes are much more confident the switch can be achieved quickly. Sixty-eight percent of this group cite 0 to 12 months as the time it would take to move to a fully automated database development process, compared to 28 percent of those who had no plans to adopt DevOps practices. In fact, 43 percent of this latter group cited more than two years as their estimate.

    Our research shows that organizations recognize the potential of applying DevOps to the database to gain all of the advantages CD brings. They see that it speeds up software development, frees developers to do more value-added work and increases the rate at which database changes are delivered.

    At a time when organizations need to operate in a faster, more seamless manner to thrive in ever more competitive markets, introducing DevOps and CD to the database can transform their development process. To read more about the research and the “State of Database DevOps,” download the full management report.

    About the Author  / Matt Hilbert

    Matt Hilbert is a technology writer at Redgate Software with 20 years’ experience working for lots of the world’s biggest tech companies – and many of the smallest. He has a particular fascination for emerging technologies and is on a continuing mission to decompile, untangle, and explain techspeak to a wider audience, and excite people about the endless possibilities technology offers.

  • Chef Report: DevOps Feeds the Need for Speed

    Chef Report: DevOps Feeds the Need for Speed

    “I feel the need … the need for speed!” ~ Maverick

    According to a recent report from Chef, one of the driving motivations for companies is based on this Maverick quote from the movie “Top Gun”: The need for speed. Getting better products to market faster is a competitive advantage that gives companies an edge over rivals—and DevOps, microservices and containers provide the fuel to speed things up.

    Chef conducted a survey to gain a better understanding of trends and technology adoption within the Chef customer community. A Chef blog post explains, “In the first few weeks of January we received over 1,500 responses. While that’s a small slice of our user base, we received responses from around the world, across all industry verticals. This varied sample pool allows us to get a pulse on the challenges most directly impacting the Chef community.”

    In a nutshell, the Chef survey found that DevOps is having a fundamental impact on the shape and practices of IT organizations. Companies are embracing DevOps, cloud infrastructure, virtualization, microservices and containers—all in an effort to streamline development and deploy faster.

    Here are a few of the highlights from the Chef report:

    • The majority of teams surveyed are releasing changes to production not monthly, weekly or even daily, but on demand. Likewise, teams overwhelmingly report reducing the time it takes between an initial software commit and running code in production to mere hours from weeks and days.
    • Cross-functional teams are 17 percent more likely than application teams to release changes to production on a continuous, on-demand basis. Further, cross-functional teams are 23 percent and 24 percent more likely than infrastructure and security teams, respectively, to release changes to production on demand.
    • When a failure occurs in production, the majority of respondents (55 percent) are able to recover in one hour, the shortest possible recovery time in the survey. One-third of respondents (33 percent) are able to recover in the next window of four hours.
    • The overwhelming majority (86 percent) of respondents have completed or are in progress of managing a project to migrate infrastructure from physical to virtual.
    • Three quarters of all respondents are running cloud-based apps in a public or hybrid cloud and only 25 percent are running them purely in a private cloud.
    • More than two-thirds of respondents (67 percent) are already running or plan to run containers in their infrastructure.

    Chef sums up with an analysis of the survey results. The report states that building and maintaining a continuous enterprise requires teams to embrace emerging technologies to increase velocity.

    Virtualization and automation drive speed. Chef also suggests, however, that teams should embrace the preferred services and tools of developers, and adopt those across other teams. The report also stresses that organizations should strive to integrate security and compliance earlier in the production cycle.

    These tidbits only scratch the surface of the report. I recommend that you download the report and read it in full. The bottom line, basically, is that speed provides a competitive edge, and that technologies and practices such as DevOps, virtualization, microservices and containers enable organizations to produce better products faster.

    — Tony Bradley

  • Help Us Understand CI/CD, DevOps & Job Scheduling

    Help Us Understand CI/CD, DevOps & Job Scheduling

    While plenty of vendors tell us what they think is happening in the market, the only way to really learn is from you, our readers. So we are asking you to take a few minutes to take this important survey on the adoption of CI/CD, DevOps and job scheduling.

    We will be giving a $50 Amazon gift card to one out of every 50 respondents. More importantly we will be publishing the results here on devopsy.kinsta.cloud to share with everyone. The survey is sponsored by BMC and co-produced with devopsy.kinsta.cloud.

    You can take the survey right here:
    Create your own user feedback survey
    Thanks for taking the time and helping us help us all.

    — Alan Shimel

  • Ransomware will Double in 2017. Are you Prepared?

    Ransomware will Double in 2017. Are you Prepared?

    A recent report found that ransomware attacks quadrupled in 2016, and are likely to double in 2017. Not surprisingly, a research survey showed that 48 percent of organizations had been hit by ransomware in the past year. And as we highlighted in a recent blog post, next generation cloud applications and databases are quickly becoming an attractive target for criminals.

    Attackers are targeting critical data or operations now, not just files. A few examples from the past two weeks highlight this trend:

    Attackers are getting much more clever and picking valuable targets within a business. It’s only a matter of time before ransomware hits cloud-based applications that run on these platforms. What can you do? Be prepared.

    A layered “onion strategy” means using a set of security tools to spot and isolate malware and ransomware, but that alone isn’t enough. The Department of Homeland Security issued an alert last year highlighting the key role backup plays in defending against ransomware:

    Employ a data backup and recovery plan for all critical information. Perform and test regular backups to limit the impact of data or system loss and to expedite the recovery process. Note that network-connected backups can also be affected by ransomware; critical backups should be isolated from the network for optimum protection.

    As the Texas police department example shows, recovering from a backup won’t work if the backup itself gets infected. A versioned backup of business data and files is essential to recovery. That’s where most backup solutions fall short, especially for next-generation applications and databases that cannot be quiesced to make a consistent backup copy across the database cluster due to their distributed nature. More importantly, given the large amount of data that is processed by these applications, it is critical that there is no bottleneck to data movement in and out of the cluster for an application consistent backup.

    — Jeannie Liou

  • The Elusive Definition of DevOps

    The Elusive Definition of DevOps

    How do you define DevOps? If you went out and asked IT professionals at other organizations, could you guarantee their answer would be the same?

    In most cases, the answer to this question is no. DevOps, despite its growing popularity, still lacks a widely agreed-upon definition. There are a few fundamental principles that appear consistently in most explanations of DevOps, such as efficiency, collaboration and improved communication. However, when it comes to the details and how exactly DevOps can be implemented in the software delivery process, differences abound.

    Recently, Clutch, a B2B research firm, conducted a survey of IT professionals to gauge knowledge of and opinions on DevOps. The data backs up the notion that a broad definition of DevOps remains elusive—but that fact shouldn’t hold organizations back when it comes to implementing DevOps.

    Clutch gave respondents four distinct definitions from separate organizations and asked them to pick the one they think best defines DevOps.

    Wikipedia’s definition, recorded in November 2016 and since altered, won the largest percentage at 35 percent. It read, “DevOps … is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other [IT] professionals while automating the process of software delivery and infrastructure changes.”

    The definitions by Rackspace, Hewlett Packard Enterprise and Amazon Web Services each garnered significant support as well, at 24 percent, 21 percent and 20 percent, respectively. Their definitions emphasized different points or excluded elements of Wikipedia’s definition and you can read them in Clutch’s report here.

    The organizations’ names were left out of the survey and the definitions’ presentation order was randomized to discourage bias.

    No definition won a majority and Wikipedia’s definition leads by only 11 percent. We believe that if there was a “correct” DevOps definition out of these four, then it would’ve gathered more support.

    Why Is a Definition So Tough?

    The abstract nature of DevOps’ definition may be rooted in the movement’s history.

    The idea of combining development and operations teams stems from principles in the Agile software movement, which emphasizes greater communication and collaboration within development teams. By breaking down silos on the operations side, DevOps further streamlined the delivery of product to user.

    If the beginning of the DevOps movement could be pinpointed to a specific moment, it would most likely be a talk Flickr employees John Allspaw and Paul Hammond gave at the 2009 O’Reilly Velocity Conference in San Jose, California, titled, “10 Deploys a Day: Dev and Ops Cooperation at Flickr.”

    Belgian IT consultant Patrick Debois, who had already been frustrated by the issues between development and operations teams, watched the talk online and, with encouragement by American software developer Andrew Shafer, created the first “devopsdays” conference in Ghent, Belgium. The movement (and the term “DevOps”) took off from there, gaining traction worldwide.

    DevOps’ grassroots growth and expansion likely contributes to the lack of a singular definition. The concept was not created by a single organization, nor solidified by a written manifesto, like the Agile movement. In fact, a manifesto may have hurt the DevOps movement, writes Christopher Little on devopsy.kinsta.cloud: “If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.”

    So, DevOps’ history possibly explains its undefined quality, but that could be its strength.

    Who’s Right?

    In response to Clutch’s data, cloud experts gave differing opinions regarding Wikipedia’s definition.

    David Hickman, vice president of Global Delivery at Menlo Technologies, said, “I think that the word culture is misused. It’s more of a methodology trend than a culture, which pertains more to social elements of organizations and how people relate to each other from a professional and business perspective.”

    Brian Dearman, solutions architect at Mindsight, agreed with the culture aspect: “It being a cultural movement is true. Fifteen to 20 years ago, DevOps consisted of two separate things, with operations and development consistently complaining about each other. The culture is being changed, removing the animosity between each side.”

    Meanwhile, Nick Martin, principal applications development consultant at Cardinal Solutions and organizer for the CloudDevelop Conference, criticized Wikipedia’s emphasis on automation: “The definition may be a little over-prescriptive in talking about automating processes. DevOps can be done without such a strong focus on automation. It’s ultimately about collaboration and getting groups working together in order to solve the same problems.”

    Conclusion

    So, DevOps lacks well-defined and universal guidelines. Should that stop you from implementing it in your organization?

    Absolutely not. DevOps’ benefits are clear for most organizations that implement it. However, it’s imperative to clarify what DevOps should mean for your organization before you start implementation.

    The concept of DevOps is broad, but most everyone can agree that increased efficiency, collaboration and communication are positive changes. However, making a point to hammer out the details with your team before implementation is important. Ideas such as increased communication are futile if every employee has a different approach to achieving them.

    Choose DevOps, but choose it thoughtfully.

    About the Author / Riley Panko

    Riley Panko is a Content Developer and Marketer at Clutch, a Washington, D.C.-based research, ratings and reviews platform for B2B services. She conducts relevant research that aims to help consumers enhance their business and select the services and software best-suited to their needs. Connect with her on LinkedIn and Twitter.

  • Security @ the Speed of DevOps Survey: Efforts Still Lag

    Security @ the Speed of DevOps Survey: Efforts Still Lag

    Enterprises today are in a relentless race to digitize or die. If they don’t digitize business processes, services or internal workflows and their competitors do, they will be at a steep disadvantage—and perhaps soon an irrecoverable one.

    In more and more companies these efforts are being driven by DevOps. According to IDC, the vast majority of businesses today think—and rightly so—that it is essential for them to put into place the right resources and IT processes to support a digital business model. Unfortunately, about 75 percent of organizations don’t think that their IT organization is actually scalable enough to deliver and support a comprehensive digital business model.

    There are many reasons why so many organizations have a challenging time with their digital transformation efforts. Many of these are cultural: IT commands tightfisted control over all information technologies used throughout the organization, yet being unable to deliver the infrastructure and digital services enterprises need to succeed, for example. Or, others within the organization still are unable to see how rapidly the world is being changed by digital technologies and so aren’t taking the necessary steps.

    Another reason is security. That’s because this rapid digitization of business processes can have a profound impact on how enterprises secure their data, applications and software development and delivery. In devopsy.kinsta.cloud’s inaugural annual “Security @ the Speed of DevOps” survey, we queried 255 security IT decision makers within organizations currently practicing DevOps or that are on a path to DevOps adoption. The survey found that enterprises of all sizes are embracing DevOps, cloud, continuous integration and deployment. But in securing these processes, however, we found vast differences in maturity.

    When it comes to DevOps practices, larger companies are outperforming. For organizations with 5,000 to 9,999 employees, a full 90 percent have either adopted or started DevOps practices. However, only 38 percent of organizations with 500 or fewer employees have started DevOps or widely adopted such practices.

    As I wrote in our report on the survey, smaller organizations also have a way to go with automated security testing. Only 6.5 percent of those with fewer than 100 employees have automated large parts of their application security testing, while 29 percent have automated some of their application security testing. For firms with 5,000 to 10,000 employees, 38 percent have automated large parts of their testing, and nearly 50 percent some of their testing. For those with more than 10,000 employees, these figures are 20 percent and 48 percent, respectively.

    The challenge here, for many organizations, is the same with enterprise security in general: the view that security slows things down. For the business, it’s about getting more digital capabilities out as quickly as is possible. It’s the same for developers. Security too often is seen as standing in the way of this.

    When this conflict is experienced at DevOps speed, there is the risk not only of development slowing down but also security processes breaking. To succeed, enterprises can’t take the same approaches to security as they did in the past. They must find tools and processes that are designed for the highly automated and continuous world of DevOps.

    Have a look at our survey and report to see how enterprises are tackling this challenge today.

    — George V. Hulme

  • DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey

    DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey

    I had a chance to sit down recently with Nigel Kersten, chief technical strategist at Puppet. Besides the fancy title, Nigel is one of the smartest, nicest people you will meet. Always a pleasure catching up with him. We spent most of our time speaking about the Puppet 2017 DevOps survey, which is now open right here.

    We also spoke about some of the findings of the past five annual DevOps surveys and the DevOps space in general. Great, informative conversation. As usual, the streaming audio of the our chat is below, followed by a written transcript. But please remember to take the 2017 DevOps Survey. Enjoy!

    Alan Shimel: Hi, everyone, Alan Shimel, editor in chief, devopsy.kinsta.cloud here, for another DevOps Chat, and today’s DevOps Chat guest is none other than Nigel Kersten, chief technical strategist at Puppet. Nigel, welcome back.

    Kersten: Hey, Alan—thank you. It’s great to be back, and always good to talk to you.

    Shimel: Absolutely. Nigel, you know—well, first of all, it’s always great to have you on the show, and we’d love to have you on as often as we possibly can, but specifically today, I wanted to talk a little bit about—it’s that time of year again where Puppet will be launching their, the annual DevOps survey, and I wanted to spend a little time talking about it and cluing our audience in, into what’s in store for this year.

    Kersten: Absolutely. Always happy to talk about the survey. So I think, you know, this has been—we’ve been running this for quite a while now, this is now the sixth year. And I think one of the things that’s really fascinating about the survey is, we survey generally technical practitioners, but also managers as well. But, in the course of surveying all of these practices and technical behaviors and how teams communicate with each other, we end up coming to a bunch of really great conclusions around the actual business outcomes.

    And this is why I think it’s so important for people to be going out and filling out this survey, because I see customer visit after customer visit, every time I’m out there on the road, so many people come up to me and say, “We’ve been trying to change the way we work inside our company, and your surveys turned out to be a really useful tool for handing to our senior management, and saying, ‘This is the sort of outcomes we can expect if you let us work the way we actually want to work.’”

    Shimel: Yes. And you know what, Nigel, just a little bit of a frame of reference, I got the number while I was at Gene’s last DevOps Enterprise Summit in San Francisco, but I was speaking to Nicole, Dr. Nicole Forsgren. What was the total—you may not know—but the total amount of people who have taken this survey at this point over the past five years?

    Kersten: There are actually over 25,000 people, which I think is fantastic, and particularly even in the first few years, we’re definitely really focused on the sort of North American market. We’ve been seeing this growing more and more in Europe, in Asia, and we’re starting to see that, really, DevOps has become a global movement and is being recognized as such within the enterprise, not just sort of the, you know, webscale hacker groups.

    Shimel: Yeah. Well, that’s certainly for sure. And Nigel, this year, is Dr. Nicole—well, they’ve actually started a company now around DevOps statistics and research.

    Kersten: Yeah, so we’ve been working with Dr. Nicole Forsgren and Gene Kim, who many people know from the author of, “The Phoenix Project,” and ex-CTO of Tripwire, and the inimitable Jez Humble, who many people know from his Lean Enterprise and Continuous Delivery books. We’ve been working with them for about the last four or five years and, yeah, this year they’ve formed a new company called DORA—DevOps Research and Assessment—where they go in and help companies do benchmarking around their actual sort of DevOps practices.

    Shimel: Yep.

    Kersten: And so I think that combination of industry experience, great sets of contacts, and really, the statistical rigor that people like Nicole actually bring to this—

    Shimel: Exactly.

    Kersten: —make this to be much, much more than just a vendor survey. Because it’d be easy for us at Puppet to just survey the Puppet user base and come to a bunch of conclusions. But I think the really interesting fact is when we get to talk to people—more people than are just using Puppet, people across the whole industry, some people who are just coming to DevOps for the first time.

    Shimel: Sure.

    Kersten: So I’d really highly encourage anyone who’s listening, you know, go out and fill out the survey when we launch next week, and don’t just feel like, “I don’t really know very much about DevOps, I shouldn’t fill out the survey.” We’re really looking for input from people all across the spectrum.

    Shimel: Absolutely. And of course, Nigel, by the time people hear this, it will be next week, and we will include the URL in the show notes so that people can click right out of this article to the survey.

    Kersten: Excellent.

    Shimel: Nigel, I don’t know if you would know this, even, but is there sort of a shortened URL that people can look for, to go to?

    Kersten: Yeah, we’ll give you a shorter URL by the time we actually launch this podcast out.

    Shimel: Okay. Not a problem. We’ll put that in there. So Nigel, six years in, though, if you’re not moving forward, you’re dying, right? [Laughter] As they say. What’s different about the survey this year?

    Kersten: Yeah, so I think we’ve really shown, over the last few years, that there’s a couple of practices that have really been formalized when it comes to DevOps enterprise adoption. We’ve seen that things like version control being heavily used in operations teams and that infrastructure being shared with your development groups, we’ve seen the role of continuous delivery and lean product management practices. So we really feel that, over the last four or five years, we’ve really shown a bunch of this stuff, that it really isn’t changing very much.

    So we’ve switched focus a little bit this year. So one of the interesting things we’re really looking at are the role of infrastructure architecture patterns in DevOps environments. And I don’t just mean, you know, “Are you adopting containers, are you doing macroservices, service-oriented architecture?” But we’re really looking for information on, architecture-wise, in terms of the way your application is set up, is your team self-sufficient and autonomous? Can you make changes quickly on your own, without lots of dependencies across the organization, and can you experiment really quickly?

    Because I think we’ve seen from Agile and from all of the DevOps enterprise movements over the last few years that the ability to do small tests and iterate quickly on the results of those tests to set your larger direction is really critical to both advancing your service, but doing so quickly and more reliably. Because I think that’s been one of the really huge sort of new things for senior management who haven’t been so familiar with these practices to realize is, adopting DevOps practices doesn’t actually mean sacrificing quality for speed or vice versa. It actually means you’re producing better, high-quality software more quickly.

    Shimel: Absolutely. So, Nigel, as I think you mentioned, this week, or the time people are listening to this, the survey will be open. Just in terms of time frames, how long will it be open and when do you think people might start getting a look at some of the data in the report?

    Kersten: Yeah, so we should be launching later on in the year as far as the results go. We tend to leave it open for at least a few weeks. Some of that sort of depends upon, you know, making sure we get a sufficiently large statistical base to get the conclusions that we’re actually looking for. So, the faster people want to see the results, the faster we want to see them fill out the survey. So, basically, head off and go and do it now.

    Shimel: Right. [Laughter]

    Kersten: As soon as we get that critical mass of data, we’ll be launching the results. So you’ll see us talking about this at Velocity, at the DevOps Enterprise Summits and a bunch of the different events happening.

    Shimel: Oh, I’m sure, I’m sure—looking forward to it. And being written about on devopsy.kinsta.cloud, I might add. [Laughter]

    Kersten: Absolutely.

    Shimel: For sure. So, Nigel, if you were king for the day, you know—

    Kersten: Okay.

    Shimel: —what would you, you know, and you looked into your crystal ball, what would the headlines be from this year’s survey?

    Kersten: If I looked into the crystal ball, what I would really like to see is that we’ve drawn some really strong conclusions around the benefits of DevOps practices in the public sector and in nonprofit organizations, because that’s been a constant source of feedback for the last few years, that we’ve managed to draw really great conclusions for profit-oriented companies.

    But I think we’ve also seen, with the rise of the U.S. Digital Service in the U.S. and .gov.uk that’s been running for quite a long time in the UK and the Digital Transformation Office in Australia—we’re really starting to see some of these practices start to be applied to the public sector. And, honestly, that’s in all of our interests, for government infrastructure to work more efficiently and deliver better services that progress more rapidly to all of us.

    So that’s something I would really, really love to see, that we can draw those conclusions, which I’m feeling pretty optimistic about. But I think the big headline I would like to see, continuing that thread of, “How do we make sure that the survey and the results in the report that we’ve come out with are useful for practitioners selling upwards in their organization, as well as senior leaders trying to implement change?” is—give your teams more autonomy. Make sure that you’re designing your infrastructure in such a way that they can test on their own, that they can rapidly experiment on their own, and that you can actually progress things much, much faster than we’re you’re needing lots and lots of meetings just to create major changes.

    So the more we can actually absorb the lessons of service-oriented architecture, and not just create a mass of complicated services, but create clusters of services that teams can work on with a high degree of autonomy and flexibility. That’s really the headline I would love to see—teams that are able to experiment and are autonomous will produce better results for the business.

    Shimel: Absolutely. Nigel, let me ask—go off on a little bit of another tangent, here. You know, one of the things that I kinda, I find fascinating and I tend to come back to and I get as much of as I can is the Project Blueshift stuff that you guys do at Puppet. Gareth Rushgrove is deeply involved in it. And while, today, you know, there’s certainly a strong container focus on it, it really is about sort of future-proofing Puppet, right, and making sure that the folks at Puppet are aware of, you know, what’s the next big thing coming down.

    What can we look for in the survey that may give us a clue in terms of what is the next big thing and hence, you know, something for Blueshift to be aware of?

    Kersten: Yeah, so I think we’ve generally tried to stay a little bit away from stuff that’s too vendor-specific research for us. But I agree—so you’ve totally captured what Blueshift is about for Puppet. It’s very much about us making sure that, you know, Puppet’s a highly successful project, you know, and used by tens and tens of thousands of companies across the world.

    But we’re in a very fast-changing technology landscape right now and I think it’s really critical for us as a company to make sure that we’re not just resting on our laurels there. We’re seeing lots and lots of things change. It’s entirely possible that, in 10 years’ time, everyone will be on completely serverless infrastructure, so to speak. And, you know, you might have been able to hear my air quotes somewhat around serverless, because there’s always someone’s servers running that code somewhere.

    Shimel: Right. [Laughter]

    Kersten: That old saying that the cloud is just someone else’s server.

    Shimel: Uh huh.

    Kersten: And I think, really critical for us, we’ve seen that Puppet, the language, has been an incredibly portable model. We started off in the UNIX and Linux space, and it’s proven to be hugely successful in the Windows space for a lot of our enterprise customers, and people really like having that common language describing all of your infrastructure. And we see no reason why, just as you’ve seen the Puppet container build stuff that we’ve done, that we can use the Puppet language to describe and compose containers and maintain that audibility.

    We can also describe all sorts of infrastructure, no matter where things come from. So, for us, Blueshift is very much about keeping that eye on the sort of next level horizon over the next six to 24 months, and just seeing what’s emerging and making sure that Puppet stays agile and that we start baking in the features to Puppet the language and the platform that will enable us to all take advantage of those things.

    Shimel: Sure. And I—

    Kersten: I think it’s really exciting. I don’t think we’ve seen infrastructure technology change as fast as this, ever.

    Shimel: It’s crazy. And, you know, I don’t know if it’s the gadget boy in me or, you know, I’ve lived in tech for so long, but it’s that—it’s not even a Puppet thing to me, Nigel, it’s a thing. What is the next thing? I think it’s a little bit of how I got into DevOps, it’s a little bit of how I got into computers and technology to begin with. So I’m always interested and curious.

    Kersten: Totally.

    Shimel: And sometimes, you know, the nice thing about this survey is, it does cast such a wide net of responses that you—

    Kersten: Yeah. And I wanna make sure that people don’t feel too left out as well. Because, you know, I often talk to people who are in big enterprise environments, managing important legacy applications, and some of them are still struggling with getting relatively basic principles adopted—of just using version control, using infrastructure as code.

    Shimel: Mm-hmm.

    Kersten: And sometimes you talk to them and they get a little demoralized, going, “You know, everyone’s talking about all this cool technology out there, and we’re not actually getting to use it.” But I think the reality is, most enterprise environments, the software they’re running is delivering actual business value, and it’s important to keep making sure that’s as efficient as possible.

    We saw from the “DevOps Handbook” that Gene and Jez and all of those people are involved in that you can apply these principles to mainframes, you know? You can see people taking incredibly legacy technology, applying these modern ways of working to them, and getting really, really huge benefits.

    Shimel: Got it, got it. Nigel, we’re almost out of time, unfortunately. You know, we can talk all day, but people only listen, it’s the curse of the modern, you know, the 10-minute or the 10-second sound bite and the 12-minute podcast—but first of all, good luck with this here survey. You know, I encourage anyone listening to go, please click on the link and fill out the survey. Can’t wait to see what some of the results are this year.

    Continued good luck with Puppet, too, as you guys are really, you know, coming out of Puppet Conference and meeting with Sanjay and some of the exec team, I was very excited about the possibilities, and I’m sure you are more than me—

    Kersten: Absolutely.

    Shimel: —about, you know, what’s on the horizon here for Puppet, so good luck with that as well. And thanks for being our guest on DevOps Chat.

    Kersten: No problem, Alan. It’s always great to catch up with you.

    Shimel: Okay, my friend. Nigel Kersten, chief technical strategist at Puppet, thanks for appearing on this DevOps Chat, and thanks for telling us more about the upcoming devops survey, or sixth annual devops survey from Puppet.

    This is Alan Shimel for devopsy.kinsta.cloud. Have a great day.

    — Alan Shimel

  • F5 Networks’s State of Application Delivery, 2017

    F5 Networks’s State of Application Delivery, 2017

    For the last three years, F5 Networks has surveyed its users and presented the “State of Application Delivery” report. This year’s report is already a couple of weeks old, and I’ve had the opportunity to read through it. There is good information in there for “NetOps” people—those who are focused on the network but want DevOps-style management. The report discusses the trends and what its customers—which lean to the larger, more established organizations—are doing.

    DISCLOSURE: I’m a former F5 employee, and overall, I loved the company. Its upper management has managed to navigate bad times and thrive in good times, and the direction of the company was generally excellent while I was there. My reasons for leaving had nothing to do with top-level management or product. In short, I’m a fan of F5. Also, my wife is still an employee of the company and—worse than that—had a hand in creating both the survey and the resulting document. And Lori sometimes also writes for devopsy.kinsta.cloud. Thus, any criticisms I offer here I will have to be willing to defend on social media, at editorial meetings and at the dinner table.

    With all that said, since readers can download the report and form their own opinions, I’m comfortable writing about this report. And I’ll even risk doing battle over the steak fries for my loyal readers.

    F5 asked nearly 2,200 users of its gear from a variety of industries a series of questions regarding how they use application services—those things such as load balancing, web application firewalls or DDoS protection that exist for an application but aren’t part of it. Included also were DevOps questions and automation questions outside the realm of DevOps.

    While much of the report is of general interest for any IT practitioner, some of it is specifically of interest to DevOps practitioners. So, with the exception of a few sweeping statements, I’ll restrict myself to the DevOps-relevant portions of the report.

    Insider side note: Lori has mentioned F5 has a metric ton of data it was unable to squeeze into this report, and she would be talking about off-and-on for a while at her F5 blog. If this topic interests you, it might be worthwhile to follow her.

    The first thing to visit is the overall list of takeaways. The report offers four “Key Findings” and, interestingly enough, three of them are relevant to DevOps. When you dig into the fourth (security-related) key finding, you discover that it, too, is at least tangentially related to DevOps.

    While I don’t want to give away the entire report, I will mention the three items directly related to DevOps:

    1. Digital Economy drives application services adoption.
    2. Cloud is growing and skills are needed.
    3. Cost savings are the primary driver for DevOps in their survey base.

    An increase in application services that can be automated kind of strongly implies DevOps, while cloud and DevOps go hand in hand, and the last point explicitly is DevOps.

    The report is packed with information about what F5’s customers are doing, what’s important to them moving into 2017 and what they plan to implement soon. Overall, it is a great read, and might bolster your appeals for executive backing or increased funding.

    There are some oddities in the report, though. I’m not a fan of the editing; some sentences seem clunky (using the same word twice in a sentence with different assumed context, for example); and one list of percentages is for some reason organized least to greatest, while all others are organized greatest to least.

    While editing errors are distracting, the biggest issue I had with the report was the inclusion of Python as a “framework” (along with VMware, OpenStack, Puppet, Chef …). The assumption is made in the accompanying text that this indicates the level of homegrown automation, but since there are many ways to implement homegrown automation, this is at best a low point indicator of that. Overall, it feels out of place in the list:

    DevOpsTools
    DevOps tools as surveyed by F5 Networks.

    But honestly, there is enough other information about trends and number of these “frameworks” in use per org packed into this section that I’m willing to view inclusion of a language as a simple oversight that can be explained away because lots of organizations are using python for automation (I have, at more than one organization).

    The report also talks about the average application having double digits of application services deployed for it. This seems high to me, but it is data from a survey of F5’s customers, and if you’ve already paid for this bundle of services, perhaps you are more likely to make use of as many as possible. What this points to, for me, is an automation of the overall application environment. Considering the commentary F5 received in response to skills questions, it makes sense that automating solutions that can easily be automated would be an easy choice for their respondents.

    Note that in the graphic above, the company did not restrict users to “What frameworks are you using for network configuration?” It might be a reasonable assumption to think it did, as F5 is primarily a networking company (don’t tell the execs I said that—they seem to be repositioning as an application services company these days), but I asked, and the company put no limits on responses. That shows uptake of Puppet among its customers to be far smaller than I would have expected, personally, considering the core of its customer base should be Puppet’s sweet spot—traditional enterprises in a variety of industries.

    The weighting of respondents across roles might have some play in how these are ranked, though. There is a preponderance of networking and management types in the response list, with fewer security, dev, architecture and DevOps types. This could skew results, even if the organization list is relatively balanced across industries.

    Overall, take a look. It’s solid information, with some interpretation available and more commentary on verticals and use cases. It’s definitely a document worth having on hand when explaining the value of what you’re doing, or attempting to expand what you’re doing.

    — Don Macvittie

  • Puppet Launches 2017 State of DevOps Survey

    Puppet Launches 2017 State of DevOps Survey

    It’s that time of year again!

    We at Puppet have kicked off the 2017 annual State of DevOps. survey. Now in its sixth year, we have once again teamed up with DevOps Research and Assessment (DORA), founded by our dear friends Gene Kim, Jez Humble and Nicole Forsgren, to survey technology professionals worldwide in an effort to better understand the health and habits of organizations adopting DevOps. We’re pleased to see that the report now serves as the de facto gauge for the DevOps community to find out how IT organizations are doing and how they can improve.

    One of the most critical aspects of the survey is that it manages to translate the processes between technical practices and choices into actual business outcomes and helps organizations understand the real benefits of DevOps adoption. Through analysis of each year’s survey responses, we’ve been able to quantify IT performance. From last year’s report, we know that high-performing IT teams are pulling away from the pack in terms of throughput. They deploy 200 times more frequently, have 2,555 times faster lead times, have a three times lower change failure rate and recover from failures 24 times faster.

    Survey Says …

    This year, we’re interested in learning more about infrastructure architecture patterns within organizations. We’re not just asking how the services are designed, but we also are curious to see if teams are free to move at their own pace and if they are largely self-sufficient. Can they easily make large-scale changes to their architectural design?

    We’re asking questions about team experimentation and whether teams are able to evolve the design of their architecture as they work and if they are required to interact with a lot of people across the organization. One of the things to emerge from the agile and DevOps movements is that the more we can enable teams to work quickly and self-sufficiently, and increase speed without reducing quality, the better it is for everyone.

    This year, we expect to see proof that high-performing IT teams are those who have been enabled to operate with a much higher degree of autonomy, and that their quality metrics remain stable or even exceed those of high-performing IT organizations. We also expect the findings to confirm that early DevOps adopters are still seeing exponential benefits compared to their colleagues who haven’t yet embraced DevOps. The longer your organization has been adopting DevOps practices, the more it becomes muscle memory and reinforces positive behavior within them, which has unparalleled benefits. As any IT professional working in a large company knows, there’s an awful lot of waste and inefficiency and we’re not anywhere near peak DevOps penetration. With each passing year, survey results show DevOps adoption is a key contributor to enhanced productivity and efficiency. We expect this year’s results to be no different.

    We’ll be publishing the results and our analysis in June, and have no doubt it’ll be worth the wait. Stay tuned!

    About the Author / Nigel Kersten

    Nigel Kersten is CIO of Puppet. He came to Puppet from Google, where he was responsible for the design and implementation of one of the largest Puppet deployments in the world. At Puppet, Nigel was responsible for development of the initial versions of Puppet Enterprise, and has since served in a variety of roles, including head of product, CTO and CIO. He has been deeply involved in Puppet’s DevOps initiatives, and regularly speaks around the world about adoption of DevOps in the enterprise and IT organizational transformation.