devopsy.kinsta.cloud

Author: Ericka Chickowski

  • Will DevOps Kill Outsourcing?: Part 3

    Will DevOps Kill Outsourcing?: Part 3

    Part 3: What’s the differentiator? Understanding how to balance build vs. buy

    (Check out Part 1 and Part 2 of the series Will DevOps Kill Outsourcing?)

    The DevOps movement has spurred a lot of organizations to reevaluate their IT outsourcing strategies. But the reality is that there will be no cataclysmic shift of insourcing. Sure, there will be plenty stand-out case studies and successes among rapid first adopters in the swing away from massive outsourcing. But like all of the biggest sea changes in IT, things will happen gradually when we look across the industry.

    “At the moment, it isn’t necessarily  that enterprises are bringing development back in-house – instead what  we’ve seen is that larger organizations attempt to adopt DevOps and stand  up new teams for new applications in-house, rather than contracting those functions out as they might have done in the past,” says Dan Cornell, CTO of Denim Group. “So, over time the center of gravity will be shifting back toward in-house development. But that will take time.”

    And that won’t even mean that over time DevOps will completely sound the death knell over outsourcing. Most experts believe it’ll always play a part in the IT ecosystem.

    As Alex Henthorn-Iwane of QualiSystems says, he’s observed among customers that even when they bring a lot of functions back in house in order to support DevOps, these companies are still keeping major development processes outsourced. They’re just finding a way to fold them into new processes.

    “So far, it would seem that the pieces of the puzzle that are insourced are the strategic glue pieces,” he says. “There is still a lot of dependence on outsourced, contracted or vendor-delivered services and technology in our customer base.”

    In order to better fit outsourcing engagements into a DevOps-enabled enterprise, organizations will have to get smarter about how they construct their relationships with outside support. It’ll need to be done with flexibility top of mind, says Jeff Gallimore, founding partner at Excella Consulting.

    “They’ll contemplate how that support will integrate with the rest of their staff and work with those who can and do collaborate with their staff. Contracts will be more flexible and accommodating of change,” he says. “That could mean smaller, lightweight, short-term contracts or contracts that provide simple, trust-based change mechanisms.”

    It’ll also require organizations to think carefully about the balance between building, buying and outsourcing the technology that they’re delivering.

    “A  rule of thumb in IT is to insource the most valuable core competencies of the company,” says Andrew Storms, vice president of services for New Context, who explains that’s easier said than done.

    The problem is that as the pendulum shifts to insourcing many people are “poorly assessing which software is the differentiator,” says Theo Schlossnagle, founder of Circonus. There’s a point at which it doesn’t make sense to build something, otherwise everyone would be building it all themselves instead of using off-the-shelf software.  In his mind, the majority of IT effort today is spent integrating, not innovating.

    “When you conflate integration with innovation you lose,” he says. “The goal should be to buy over build when possible, but innovate in-house precisely those things that are core to your business that can change how you compete in your market.”

     

  • Will DevOps Kill IT Outsourcing?: Part 2

    Will DevOps Kill IT Outsourcing?: Part 2

    Part 2: Continuous delivery tool chain efficiency > Outsourcing savings

    (Check out Part 1 of the series Will DevOps Kill IT Outsourcing?)

    Experts on digital disruption and DevOps practices are vocal in their belief that DevOps and traditional outsourcing models don’t mix well.

    “Adopting DevOps requires organizations to erase the barriers between development and operations teams,” says Dan Cornell, CTO of Denim Group. “This is hard enough to do within a single organization and nearly impossible to do across organization boundaries.”

    If push came to shove and an organization needed to justify an either-or decision for DevOps over outsourcing, the argument would likely revolve largely around business value. Continuous delivery makes it possible to move to market more quickly, develop products better aligned to customer sentiment and kick the pants out of competitors who don’t do the same. That was the impetus behind the shift at GE Capital. Last year the firm’s CIO Jim Fowler said he was looking to significantly reduce IT outsourcing and shift toward more Agile teams. Earlier this summer Matt Merchant, former global managing director of DevOps for GE Capital gave devopsy.kinsta.cloud a snapshot into how this is driving innovation. (Ed. Note: Merchant suddenly passed on this summer. Our interview was just prior to this tragic event.) He explained how the company was able shift customer-facing mobile app development from a six- to eight-week release cycle to twice weekly.

    But the decision to dump outsourcing in favor of supporting DevOps practices within a more centralized IT group doesn’t just have topline revenue and innovation benefits. The upside presents itself in the bottom line as well.

    In many ways, we can chalk that up to the fact that the automation and cloud technology that facilitates continuous delivery is light years ahead of where it was when belt-tightening outsourcing deals crescendoed following the 2008 financial crisis. As things stand, the cloud has enabled IT to decouple infrastructure outsourcing from operational and process outsourcing.

    “Companies today realize they can achieve many of the cost efficiencies that outsourcing was originally intended to achieve by leveraging cloud technologies,” says Thomas Enochs, vice president of customer success at Chef . “There is a general trend towards leveraging cloud services rather than cheap labor to achieve the scale, speed, and flexibility they desire.”
    The fact is that many an outsourcing deal was born in a day when the tools of development were slow to deploy and expensive.

    “DevOps practices and modern software tools have drastically reduced the time and cost required to develop custom applications,” says Bernard Sanders, CTO of CloudBolt Software. “In the early 2000s, the step of just getting the servers and infrastructure set up for a new app could be a multi-week or -month chore.”

    Virtualization vendors, cloud providers and self-service automation have all made it possible for developers to get easy and affordable access to the infrastructure they need when they need it, Sanders says. And then there’s the advances in deployment pipeline automation that are seriously streamlining hand-offs over the course of the software development lifecycle. It’s all adding up to added efficiency and reduced cost of development and deployment.

    “In the future, the overhead required to build custom apps will be driven to near zero, and enterprises will be able to in-source this development, retaining this function that has become key to enterprises’ brand identity, product offerings, and customer experience,” Sanders says.

    Even now, though, the DevOps toolchain is completely blowing up a lot of the financial models that initially drove IT departments to aggressively outsource. While many outsourcing deals continue to be renewed without reviewing old assumptions, this is starting to change.

    “We have seen cases where outsourced functions like automating test or other processes has been brought back in house because equipped with the right approach and tooling, the internal team could achieve better results, but also because the automation work was a key building-block to a longer-term DevOps plan,” says Alex Henthorn-Iwane of QualiSystems.

  • Will DevOps Kill IT Outsourcing?: Part 1

    Will DevOps Kill IT Outsourcing?: Part 1

    Part 1: DevOps and outsourcing like oil and water

    After nearly two decades of steady IT outsourcing for the sake of savings and efficiency gains, the shine seems to have worn off from this once glittering phenomenon. And according to many experts, DevOps and continuous delivery practices are playing a big part in many enterprises’ plans to reverse course on outsourcing key functions in their technology stack.

    “DevOps transformations emphasize collaboration, which is often at odds with outsourcing arrangements,” says Jeff Gallimore, founding partner at Excella Consulting. “Outsourcing arrangements often reinforce stovepipes and silos rather than break them down. And silos are speed killers and barriers to improvement.”

    According to a report out earlier this spring by outsourcing research firm Information Services Group (ISG), average outsourcing contract values saw their worst first quarter in a decade, dropping by 27 percent year-over-year. Big deals over $30 million were particularly hit hard, declining by 25 percent in both number and value.

    Even without the tidal wave of Agile and DevOps practices seeping into enterprise IT over the last few years, many organizations are already predisposed to take a second look at their outsourcing contracts, says Gallimore, who sees time and again that many businesses aren’t getting the value they thought they would from their outsourcing deals.

    “I hear many more negative experiences organizations have had with outsourcing arrangements than I do positive ones,” he says. “Poor quality. Higher-than-expected management overhead required. Inflexibility. Process challenges. All are reasons cited for why the arrangements didn’t live up to expectations.”

    The anecdotal stories are also piling up of big name enterprises pulling more of their IT resources back in house after years of outsourcing. For example, General Motors made waves three years ago when its CIO Randy Mott said he would completely invert the outsourcing ratio the car company had by 2017. The firm continues to make headway in changing from 90 percent outsourced IT to 90 percent insourced, with many of the positions advertised these days focused on DevOps and innovation-related roles. Similarly, David Smoley, CIO of pharmaceuticals firm AstraZeneca, went public with his goal to shift the company from 70 percent dependence on outsourcing to 30 percent, along with a commitment to Agile and lean development.

    As organizations increasingly witness the business boosts gained through a more collaborative DevOps delivery model, they are seeking ways to adopt continuous delivery practices across their entire software delivery lifecycle. But they’re finding that these practices are often wholly incompatible with the outsourcing arrangements they’ve developed, says says Jonathan Braunhut, chief scientist at KEMP Technologies. As he explains, many organizations will need to “unwind” these arrangements if they want DevOps to work well because in many cases the contracts and SLAs that govern them are inextricably tied with waterfall development.

    “Outsourcing in an enterprise setting is often implemented in a way that advances outdated waterfall-like practices and processes that are antithetical to continuous delivery,” Braunhut says. “The very wall between dev and ops that the DevOps movement seeks to eliminate can become codified in outsourcing agreements, as a reasonable means of achieving an enforceable and accountable contract.”

    More specifically, outsourcing tends to fly in the face of DevOps’ lean ethos, which is to “minimize handoffs and waste and increase quality by thinking about the overall system and flow,” says Gallimore, who believes that traditional contractual arrangements simply can’t operate with the kind of agility necessary to establish speedy and iterative cycles of continuous delivery.

    Perhaps even more fundamentally flawed in the outsourcing relationship is the idea of ownership. As many organizations finally recognize the value that IT brings to the table—more likely now to serve as a revenue generator than a cost center—it doesn’t make as much sense to give up so much ownership over the technology and tech-enabled services that could potentially transform the business.

    “To be most effective, enterprises need to own the transformation, and it has to be a truly collaborative effort across disciplines–business leadership, engineering, system administration, security & compliance,” says Thomas Enochs, vice president of customer success at Chef. “Collaboration and transformation are difficult to achieve with outside third parties or vendors. They need to own and drive the change themselves, and not be dependent on others.”

  • Inside Look at State of DevOps Report: Q&A With Puppet Labs

    Inside Look at State of DevOps Report: Q&A With Puppet Labs

    Last week Puppet Labs released the analysis behind its annual study of DevOps and continuous delivery practices in the 2015 State of DevOps Report. Now in its fourth year, the report offers an in-depth look at the findings of the team on what it means to be a high-performance IT organization—the cultural characteristics these organizations share, the lean engineering practices they engage in and the technical architectures they depend upon.  Like last year,  however, the report tends to be a bit of a black box when it comes to actual statistical findings. While some figures do make it through, for example the oft-flogged statistic of high-performance organizations deploying 30 times as fast with 200 times the lead time of low performers stands pat, the report itself is somewhat oblique about the statistical basis upon which the designators of low-, medium-, and high-performance were determined.

    devopsy.kinsta.cloud spoke to Nigel Kersten, CIO for Puppet, and Alanna Brown, senior product marketing manager for Puppet,  about the report to get a little more detail, to have them explain the process behind the analysis, and to offer up some of the most important facets of their findings over the last few years.

    devopsy.kinsta.cloud: Can you tell our readers a little bit about the high points from the report?

    Kersten: Big finding from 2013 was the orgs that used Devops’ practices deployed code 30 times more often and had 50 percent fewer failures.  In 2014 what was quite fascinating was that we actually found a link between these practices and overall organizational performance, not just IT performance. Higher-performing IT organizations are twice as likely to exceed their own profitability, market share and productivity goals.

    If we fast-forward to today, the high-performing organizations using Devops practices are more stable and reliable than they’ve ever been.  They’re recovering 168 times faster from their failures and have 60 times fewer failures due to their changes.  So we’re not actually seeing throughput increase from the year before, but what we are seeing is the quality and speed has definitely increased.  So people are producing changes that are of higher quality and that require fewer rollbacks.

    And so what we’re concluding from the data that we’ve seen this year in the report is that there’s been a really huge focus to the left of the assembly line from production. So if we envisage the developer work flow application delivery, essentially we start with the developer laptop like on the far left, and on the far right is the application actually existing in production.  So from the point between the developer’s laptop and the actual release, we’re seeing organizations focus much more on that stage, putting more testing in the hands of the developers, and all of these practices not just being focused around the release but the pre-production stage of the application life cycle having a really huge impact upon quality.

    devopsy.kinsta.cloud: Why doesn’t Puppet publish the actual data from the survey? You have great analysis here, but there’s very little statistical proof behind it—why don’t you provide that?

    Brown: Well so we have a ton of data, and part of the reason we don’t issue the data is because you wouldn’t be able to actually get to the same results without doing a ton of data cleansing and statistical analysis.  So our analysis is actually fairly rigorous, and some of that analysis doesn’t really lend itself very well to graphs and charts and visuals and things like that because it’s all based on correlations and predictive regressions.  So that’s part of the reason.

    Kersten: I think in many ways it’s analogous to releasing software to the world. We have all of these tools inhouse.  We have all of these Excel spreadsheets we’ve put together.  We have all of these you know pivot tables and different bits of cluster analysis, but they only – they’re not particularly usable for anyone else right now.

    As much as we would love to work out how to polish all of that up and share it so it’s one big data set along with all of the tools, our biggest worry is honestly being that people would actually draw sort of misleading and incorrect conclusions from the data because of the level of analysis that was required.

    devopsy.kinsta.cloud: Can you tell us, then how you came to the determination of what’s a high-, medium- or low-performance organization? Because if you look at some of these numbers, you say they’ve got thirty times more deployment frequency. But of course they do because they’re high performers. So how does that work out statistically?

    Brown: No, no, you’re absolutely right, and I will agree that IT performance metric is a bit circular.  However, those are the actual metrics that are important to an IT organization, so they care about deploy frequency, deployment lead time, their mean time to recover and change failure rate.  So we feel like that’s a pretty good approximation or a proxy for IT performance, and it’s better you add at doing those things that is correlated to higher performance overall.

    Kersten: One thing, too, is that even though there’s a whole spectrum in terms of how fast people are able to actually deliver and ship code, what actually came out really strongly out of the survey this year and in previous years is that the high performance (orgs) definitely cluster in terms of data points. It’s not just a smooth spectrum, but there’s this really obvious clusters of high performance that leap out that all have a very high correlation of the kinds of practices they use.  So it is a little bit circular but it’s also it’s not that we’re seeing this smooth spectrum from zero to 100.  We’re seeing the masses and then the high performers, and they divide into quite clear clusters.

    Brown: Yeah, and they’re not arbitrary clusters; they’re actually statistical.  So the low IT performers share all the same characteristics and the high IT performers share all the same characteristics, so they’re very clear.

    devopsy.kinsta.cloud: OK, so let’s talk about some of those common characteristics between these groups if you’ve got statistical bases for these.  Tell me a little bit about the low performers and we’ll kind of go on up the spectrum and we can talk about the characteristics they share.

    Brown: So for IT performance, deployment pain was actually the number one most highest-correlated construct. And deployment pain consists of a couple of questions.

    Like how painful are your deployments?  Are they very disruptive events, etc?  So there’s three questions that we ask around deployment pain.

    The next thing that’s highly correlated with IT performance is version control. We use the version control for all production artifacts.  Following that is culture, and the model we use for culture comes from a guy named Ron Westrom who is a sociologist.  And he created a typology of cultures, and you can see the table in the report itself.  So he has a pathological culture, bureaucratic, and then generative.  So the more generative your culture is, the more likely you are to have higher IT performance.

    Kersten: And I think this is what was so fascinating for us when we first started adopting Westrum last year We actually adopted Westrum as part of the model in that this pathological versus generative cultures, this is the language our practitioners in this space use to talk about you know what’s so great about working there: “My ideas are valued. I get to create ideas.  I can create impact.” Similarly around what’s horrible about working at this other place.  It maps to the pathological and generative descriptions of organizations perfectly really.

    devopsy.kinsta.cloud: So what would you say is the key characteristic in that first leap from low performance to medium performance, based on your data?

    Brown: So the lower performers in terms of IT performance will be doing less automation, less testing.  They haven’t automated their deployments, for example.

    Kersten: I think one way I at least think about is that there are these characteristics that are necessary but none of them are sufficient on their own, and so you see people who say just adopted version control.  They’re definitely heading ahead of the pack of the people who haven’t adopted any of these tools.

    But there’s this transformative leap once you actually adopt version control and continuous delivery and the highly-automated conflict management system, that those things together are greater than the sum of their parts.  That is at least how the data seems to us, ’cause we don’t actually have this smooth little spectrum between low performers and high performers who just adopted one of those technologies.

    We definitely see improvement from those people, but it’s when they adopt all of them in total that they suddenly take this sort of order-of-magnitude leap.

  • Rancher Labs hopes to help DevOps teams rope in container management

    Rancher Labs hopes to help DevOps teams rope in container management

    DevOps teams have turned to containerization in a big way in order to help improve their efficiency. But many enterprises have run into problems scaling containers across their infrastructure to account for issues like networking and load balancing.

    Rancher Labs, a Cupertino-based cloud software startup, is hoping to help organizations address the scalability with a new open-source Docker platform. Eponymously dubbed Rancher, the beta version for the platform went live this week. It’s designed to be a full set of tools to help DevOps teams manage Docker containers in production. The platform folds in infrastructure services built specifically for containers, including networking, storage management, load balancing, service discovery, monitoring, and resource management.

    The goal of containers is efficiency and full portability, but Sheng Liang, co-founder and CEO at Rancher Labs, notes that the implementation can be hard to get perfect.

    “As users deploy containers across different infrastructures, they quickly realize that different clouds, virtualization platforms and bare metal servers have dramatically different infrastructure capabilities,” said Liang. It’s these variables that Rancher seeks to limit. “By building a common infrastructure backplane across any resource, Rancher implements an entirely new approach to hybrid cloud computing,” said Liang.

    The company is going long on containers—an assessment that backers agree with. The company also recently announced that it has received $10 million in series A funding from Mayfield and Nexus Venture Partners. In addition to its Rancher suite, the company also produces RancherOS, a minimalist Linux distribution tightly focused on running Docker containers.

    The management team behind Rancher is one that is familiar to many cloud practitioners. Co-founder and CEO Sheng Liang was co-founder and CEO of Cloud.com, and continued on at Citrix as CTO of Cloud Platforms Group after the company’s 2011 acquisition.  Also on board are Cloud.com and Citrix veterans Shannon Williams as vice president of sales and marketing, Darren Shepherd as chief architect and Will Chan as vice president of engineering.

    According to industry analyst Paul Burns, Rancher Labs’ niche is ripe for new innovation.

    “In its current state, running any containerization solution at scale and in production requires a significant amount of effort from those adopting the solution,” says Burns, who is president of analyst firm Neovise. “Key functions such as networking, service discovery, storage and load balancing can cause integration issues, keeping enterprises from truly reaping the benefits desired. By providing a unique solution that eases and simplifies the management of container software, Rancher is allowing companies to better utilize and benefit from the technology.”

  • Software-Driven Economy Drives DevOps

    Software-Driven Economy Drives DevOps

    Venture capital scion Marc Andreessen predicted years ago that software would eat the world. Now his instinct for prescience is backed up by hard numbers as experts from Oxford Economics reveal the results of a new study today.  Commissioned by CA Technologies, the global study shows how important applications are becoming in establishing competitive advantage in today’s economy.

    It found that within three years, most businesses will be software-driven and that today 43 percent of businesses already see becoming a software-driven enterprise as a critical driver for competitive advantage.

    “No longer is it enough for companies to have superior products or services,” wrote Jacqueline Gold, senior analyst for Oxford Economics and author of the survey report. “Today, success depends on increased agility and time-to-market, better customer service, and a better overall customer experience—and these mandates require an increasing ability to leverage software.”

    These drivers are already having a drastic impact in a number of areas today. Nearly half of companies say that it has helped them with market share and time-to-decision. And while only a little over a third believe it has improved their overall financial performance, 62 percent believe that in three years it will translate to financial health.

    Interestingly, Oxford Economics’ analysis found that enterprises that were bet able to adjust to become software-based organizations also emphasized internal application development. Overall, the survey showed that 50 percent of respondents are bringing more software development back in-house.

    As IT departments shift to this new reality of the application economy, many will need to re-architect their processes and culture to support greater business agility through software. Approximately 58 percent of organizations say they’ve instituted or plan to institute process improvements and 56 percent say they’ve implemented or plan to implement more collaboration across business units and functions.

    According to the survey, DevOps skills rank among the top three skills businesses have identified as necessary to develop and recruit to keep up with the software-oriented focus necessary for success in the future. Approximately 20 percent identified it as a highly important skill, compared with 21 percent who ranked collaboration and 22 percent who ranked data science as highly important. Other key skills included API development and usage, analytics, and programming and development. Clearly there’s crossover in these skills category, with the prevailing trend being that organizations need to find a way to write better code faster, use data to its fullest, integrate application frameworks well and ultimately work well as a team to accomplish these goals.

  • DevOps and QA: What’s the real cost of quality?

    DevOps and QA: What’s the real cost of quality?

    As continuous delivery and DevOps speeds the cadence and volume of development, quality assurance professionals and the groups they work in must find ways to transform their roles. Because in order for businesses to truly get value out of the applications they’re delivering through DevOps automation and iteration, they don’t just need to attain speed from the process but also quality. And if they don’t, the costs to the business may be more than people think.

    “Software is transforming from a business enabler to a business differentiator,” says Wayne Ariola, chief strategy officer for Parasoft. “The costs and risks associated with failure has shifted dramatically over the years.”

    Ariola recently presented some cost figures at the STAREAST conference to show how dramatic the costs of quality failures can be. Over the past few years he’s made it a pet project to follow headline news on notable public company software failures and track them to stock prices to do a quick back-of-the-napkin equity analysis. According to his analysis, the typical net decline in the value of a company associated with the announcement of a failure is $2.3 billion.  These types of events can be anything from something like American Airlines’ announcement of that a glitch in iPad software used by pilots in the cockpit grounded a number of flights this spring to Chrysler’s admission that software incompatibilities between the electric control unit and the battery pack control module in Fiat electric cars could suddenly shut cars down.  Ariola says that in 2015, the average net decline of publicly-traded companies that made headline news for software failures was 4.18 percent.

    “When you’re about to release something, and it’s about to go out the door, do you hang out with the developers and say, ‘Hey, if this fails our stock price is going to decline by 4.18 percent? ‘” he says. “These are conversations we’ve got to start having (as QA professionals).”

    Market valuation is only one indicator of the costs, too. There’s also the more difficult to track issue of customer churn, which is only going to increase as the software-driven world evolves and newer generations’ expectations of software quality ramp up. Whereas Boomers, GenX and GenY consumers simply got used to things like the blue screen of death and troubleshooting wonky software, Millennials have been less desensitized to quality issues. What’s more, they have more alternatives than ever, so when problems come up, they’re more likely to ‘nuke’ a product or service and choose a competitor—say switching between one app to another on their phone—rather than even bothering with failed software.

    “Their tolerance for faulty software is much, much lower than ours is, and it’s going to change the way people consume software,” Ariola says. “We need to be aware of that as a team of testers, because we need to drive the agenda much differently than we are today.”

    One of the key elements of that is switching the mentality of testing as a time-boxed event into a set of practices that “infiltrate” development and deployment processes and “escalate the process maturity.”

    “You’ve got to go from manual to continuous tests.  You’ve got to get beyond this idea of just pure automation, and strategically look at this application so you understand the risks associated with it today, and the concept’s going to change,” Ariola says. “So with this speed comes a totally different paradigm.”

    In the past, the question that gated releases was whether testing was done or not.

    “I’m going to propose that the real question is does the release candidate have an acceptable level of risk?” he says. “I have to understand the business expectations associated with the risk of that application, and if it’s in an acceptable boundary, we’re going for it, we’re releasing it, and hopefully we can roll back really fast if we need to.”

     

     

  • The #1 trick DevOps shops use to reduce vulnerabilities

    The #1 trick DevOps shops use to reduce vulnerabilities

    A new report out this week highlights how important it is to find ways to fold in vulnerability assessment information into the software development lifecycle. Released by WhiteHat Security, the Website Statistics Report 2015 offers a smorgasboard of interesting data around web application security. Amid all of the statistics, though, DevOps shops should perhaps home in on one major takeaway—statistical evidence that points to a single practice that could make a huge difference in reducing vulnerabilities in the long run. The trick in question? Tying vulnerability data into the bug tracking system.

    “When it’s all said and done, there are three metrics that matter in application security. It’s the number of vulnerabilities you have, the speed at which you fix them and the percentage of which are fixed,” says Jeremiah Grossman, founder of WhiteHat. “And what we’ve found is that when you wire into the apparatus  whatever vulnerability  assessment data that you get into the bug  tracking system, which is very important  for DevOps, that actually is what achieves the best results.”

    As he explains, simply providing vulnerability assessment data in a raw format—for example, a PDF document listing flaws—this does nothing to fit within an automated pipeline and vulnerabilities will remain unfixed. In the report released this week, Grossman reports that organizations that made the connection between the vulnerability feed and the development process’ bug tracking system exhibited 40 percent fewer vulnerabilities, fixed issues a month faster on average and increased their remediation rate by 15 percent compared to the rest of the pack.

    While Grossman admits that it is difficult to know exactly what percentage of customers ascribe to different development methodologies, his rough guess is that about half at this point are instituting some kinds of DevOps principles in order to release at least every two to three weeks. He recommends that security professionals hoping to get more involved in the spirit of cooperation that drives DevOps transformations should start with metrics.

    “Create a metrics program, just like the DevOps guys do, to measure the security of that environment,” he says, explaining that the three metrics mentioned above are good ones to start with. “Then you can track the performance of the DevOps groups in terms of security and deliver that data back to the group. Then when you want to get strategic about what processes and improvements in the DevOps environment that need work, you can be very laser focused. App sec programs should be tailor-made to the internal processes of the organization around the metrics they want to improve.”

  • Survey: Fed gov cloud success hinges on DevOps

    Survey: Fed gov cloud success hinges on DevOps

    A new survey out last week by MeriTalk and Accenture Federal Services shows that the federal government is on the cusp of finally putting its money where its mouth is with regard to cloud and that DevOps will play a big role in the transformation. In fact the government’s cloud success may hinge on DevOps.

    The survey looked at perceptions of federal IT managers familiar with their agencies’ cloud progress. Many of them report difficulty in gaining cloud momentum, in spite of the fact that 66 percent believe that their agency needs to move IT services to the cloud faster to meet mission and constituent needs. Fewer than half of Federal agencies have made process or policy changes to facilitate successful transitions to the cloud, only 30 percent have made necessary cultural changes and just 28 percent have made organizational changes. What’s more just 12 percent of Feds report their departments have all the tools they need for a cloud transformation.

    However, 57 percent believe DevOps holds the key to help them succeed in the cloud and 63 percent say DevOps will help them speed up application delivery and migration. As things stand, only one in ten respondents believe that developers and administrators are highly collaborative in the Federal setting and only 5 percent say their agency has fully deployed DevOps patterns.

    “A DevOps model brings software engineering, quality assurance, and IT operations together as an integrated team,” stated Tim Hoechst, Accenture Federal Services’ chief technology officer (CTO).  “Federal agencies can start up new projects more quickly, improve resource utilization, and reduce downtime – ultimately driving the innovation needed for real change.”

    Respondents are hopeful of that vision, with 60 percent reporting they see DevOps in their agency’s future. Approximately one-third say they’ve already started adopting the model or plan to do so within a year.

    But it’s not clear whether this is pie-in-the-sky hopefulness for a silver bullet or a real commitment to DevOps. A big red flag from the survey was that some of the same barriers to Federal cloud adoption are those that typically stand in the way of DevOps transformations. For example 40 percent of Feds said fear of change and inflexible practices have stood in the way of their cloud efforts.

    Over half of respondents say they will need to train current personnel to implement DevOps, and 40 percent say DevOps success depends on incentivizing changes in culture to make it happen. Meanwhile 41 percent believe they’ll need to establish a new vision for the future to make DevOps possible.

  • Security, DevOps and the shift to a software supply chain

    Security, DevOps and the shift to a software supply chain

    Last week at the DevOps Connect event held in conjunction with RSA Conference, the security and continuous delivery worlds united to deliver an overarching message that security teams that can embed themselves in DevOps patterns can not only secure IT at speed, but they can actually contribute to a more reliable, repeatable and higher quality release cycle.

    “DevOps extended the value of Agile so that we went from just continuous integration to continuous integration and continuous deployment,” says Josh Corman, CTO of Sonatype. “If the three measures of any software manufacturing lifecycle is speed, efficiency and quality/risk,  then I think this Rugged DevOps era ideally allows you to go even faster, be even more efficient because of fewer break fixes and faster mean time to repair and better quality and lower risk.”

    To read more about security and DevOps, check out our eBook on Rugged DevOps. 

    Corman and Gene Kim, author of The Phoenix Project, developed on this idea in their talk, which pushed the thought that the ultimate Zen state of software delivery to strive for is a software supply chain.

    “The way we can get more safety and security into digital infrastructure, is to move to the ultimate evolved posture of software development as a supply chain,” Corman explains. “This makes you even faster than DevOps–even more efficient and with higher quality and risk mitigation without tradeoffs.”

    The idea of the software supply chain further builds on the lean manufacturing principles of W. Edwards Deming, who many in the Agile and DevOps worlds see as the spiritual grandfather of these movements.

    “If you take Deming to his logical consequence, we’re going to start paying attention to the quality of our suppliers, the quality of our supply and the traceability and visibility of which parts went were, such that when there’s another Heartbleed, we can do a prompt and Agile response,” he says, explaining that that avoiding known bad parts, such as a bad version of struts in car manufacturing or a faulty SSL component like the one that caused Heartbleed, “will make you keep top speed, halve your blowouts, faster meantime repair, better traceability and make the auditors go away with less pain”

    Security teams have traditionally been known as roadblocks rather than speed enhancers to development processes. But looking at it from the perspective of creating an effective software security supply chain, security actually plays a role in further speeding up production if it is helping organizations depend on higher quality components of production code and the code running infrastructure.

    “If we get better at our component selection and our traceability of what we’re using where, we can reduce the number of break-fixes or reduce the number of unplanned unscheduled work,” Corman explains

    He emphasizes that security debt tracks roughly with technical debt and CISOs should be having conversations with DevOps teams to that end. In the end security work pays down principle on technical debt, making it possible to spend more time writing code and less time on rework

    “I’d love to give us a more defensible opportunity which embraces what devops already cares about and doesn’t articulate how we can make them safer, instead articulate how we can make it faster and more efficient,” he says.

    As security pros start to do so, they might be surprised at their reception by the developers and operations folks. As Kim explained in their talk, in the end everyone does want the kind of quality that a cooperative security team can bring to the DevOps equation.

    “When security imposes itself on day-to-day DevOps processes, dev and ops say ‘thank you,’” he says.