devopsy.kinsta.cloud

Tag: devops

  • DevOps and the Dark Pools of Security Technical Debt

    DevOps and the Dark Pools of Security Technical Debt

    We live in a world of digital transformation where organizations across industries are embracing initiatives around automation, cloud deployments and containerization of applications—and for good reason. Enabling transformative technologies such as DevOps, for example, can deliver superior product differentiation, faster time to market for new applications and services and an improved overall customer experience. A win-win, right?

    Not so fast. Amidst the explosion of new technologies, tools and practices, many business leaders are jumping in head first without testing the security waters, so to speak.

    In their race to move fast, it’s all too common for organizations to quickly realize that they’ve landed in a deepening pool of security debt that hackers are eager to exploit. As evidenced by recent breaches resulting from misconfigured AWS security settings, leaked S3 buckets full of secrets, database security misconfigurations, ransomware and the growing interest in exploiting CI/CD tools for hijacking IT assets to mine cryptocurrency, attackers are increasingly targeting DevOps environments.

    Security and DevOps Teams Swimming in Different Pools

    When it comes to prioritizing efforts, devoting attention to the non-functional requirements of DevOps infrastructure security often takes a back seat to the more observable value that the output of these systems provide. This is where security technical debt is created.

    Often times it’s a shortcut in establishing a process around managing security configurations, which is the first step on the path to an “event.” Other times it’s aligning personal development processes to corporate IT security standards.

    No matter what the first step in the chain is, the accumulation of unaddressed issues, incomplete process and failure to attend and improve security posture is how companies and groups find themselves in security quicksand.

    How deep and how wide is the security debt pool for DevOps and digital transformation initiatives?  Numerous studies show that most organizations simply don’t know what their level of exposure is, but there is concern about the unmet need of consistent security posture. We know this because security and compliance consistently rank among the top three barriers for DevOps and cloud initiatives year over year as evidenced in Puppet’s “State of DevOps Report” and RightScale’s “State of Cloud Report.”

    According to the “CyberArk Global Advanced Threat Landscape Report 2018,” fewer than half of DevOps respondents said DevOps and security teams are well-integrated, and 41 percent said security teams are only brought in at the end of the development cycle. These two departments are clearly working in different silos.

    IT security professionals and developers often have different areas of responsibility and focus on the DevOps adoption path. Owing to variable technical capabilities and operational silos, roles and responsibilities can get confusing, and the resulting work may or may not get done—leaving technical debt.

    While DevOps teams typically take ownership over application testing, QA and remediation for security flaws in software, there remains a significant “gray area” that isn’t wholly within the DevOps pipeline flow. For example, managing the security “of the pipeline” and adherence to the corporate standards for login ins/2FA and privileged account management, management of access control to secrets and rotation for shared sensitive corporate assets such as databases can impact other teams. Who builds and maintains these core controls for which the business needs to attest regarding the security of these systems when service level responsibility or operational controls are outside the DevOps team’s controls?

    It’s around these gaps that security responsibilities and operational roles get murky, and the debt pools deepen while issues remain unaddressed. The security maturity of various DevOps tools and open source projects vary widely. Missing security features as well as misconfigurations are to blame for numerous security events at many organizations with new stack components at work.

    As Cyberark Labs research has shown, DevOps pipelines can be starting points for lateral movement to other IT systems, so designs of isolation and containment are often aspirational rather than the actual achieved outcome. And for DevOps teams under tight deadlines, there are only so many hours in the day, and only so many additional items that can be added to the burndown list before something has to push and isn’t addressed in any given release.

    Breaking Down the Silos to Stay Afloat

    When these issues hit a breaking point, we see one of two outcomes: security gets involved too late and “puts the brakes on,” or the team makes a premature push to production of a transformative initiative resulting in a security event when the security process simply isn’t ready.

    When integrated and working toward common KPIs and goals, security can provide the extra bandwidth, focus and expertise to avert issues when they are brought into the process in a consultative role early, so called “shifting left.” Security needs to be built into development pipeline processes, and as we’ve seen with breaches of late, security needs to be a “feature” of the pipeline itself, which is the new attack surface cited above.

    Likewise, security teams must embrace new ways of working in the “fast-flow” of modern software engineering. They need to leave behind alarmism and “all or nothing” mental models, which were the security modi operandi of prior eras.

    Business level visibility to KPIs of success in integrating DevSecOps across the organization is often the missing link.  Whether it is red teaming the DevOps pipeline to raise awareness of the latent issues, or measuring security feature delivery success, measurement creates shared values of burning down security tech debt. Whether it is the most common security events by incident (eg. github hardcoded passwords) or the lead time to security feature delivery by the team, accountability insure attention to security success.

    In the end, it’s critical that DevOps teams work with security to ensure that speed, velocity and resiliency aren’t sacrificed for security. Every company’s fortune rises with the new value being created by digital transformation, but it can also fall with the reputational damage of a breach. Organizations need consistently aligned security and risk postures across all these new tools and technologies to reduce the pernicious pools of technical security debt.

    — Elizabeth Lawler

  • DevOps at Scale

    DevOps at Scale

    According to Accenture‘s APAC practice lead for Agile, DevOps and Test Automation Mirco Hering, there is general agreement that DevOps at scale is a good thing, but the problem is getting from where organizations are to where they want to be.

    Obstacles include having plenty of technology skills but little or no technology management (i.e., people and process) skills, or being driven heavily by technology vendors and ending up with a collection of tools that don’t all work well together.

    Hering has found value stream mapping to be a very successful technique for implementing DevOps at scale. It allows people from all parts of the business to participate in the development of a map of the software delivery process (and, thus, gets different parts of the organization talking to each other), it provides important context for any external consultants that may be engaged, and it provides a visual representation of the real situation (not a formalization that doesn’t reflect reality).

    It also provides an opportunity to explore what the participants think DevOps is really about. (Hering’s favorite definition is “building better solutions faster.”)

    Get the First Bite Right

    Once the map has been created and agreed, the next step is to determine what should be done first. “Find something that is meaningful but not impossible,” he recommends.

    In other words, avoid biting off more than you can chew, but also avoid projects that are so specific that they won’t seem relevant to other parts of the organization. And avoid those involving technology that’s likely to be retired soon, because there might not be time for the results of the project to be appreciated.

    It’s important to understand how you can show progress is being made, and organizations that understand the idea of rigorous continuous improvement are generally better at this.

    There is a particular problem that arises when senior leadership changes: it is important to be able to explain what’s going on and demonstrate the benefits, such as the actual savings made.

    Hering advocates the use of same rigor for applications supporting IT delivery as for business applications. For example, if software development systems or quality assurance systems go down, development and deployment come to a halt while the problem is rectified. The changes that are held up clearly have value to the organization (otherwise there’s no reason to make them), so any delay comes at a cost that can be minimized by applying the same types of backup and failover capabilities that are used to protect business systems. Other aspects of IT that can be applied to ‘doing IT’ include big data.

    Use IT to Support IT

    He points to the IT4IT reference architecture for managing the business of IT, saying “I think it is rarely implemented at this point, but at least someone’s thinking about it.”

    Doing DevOps and Agile at scale requires de-scaling the technology, said Hering. That is, where hundreds of people might once have worked on a single piece of software that was released in a ‘big bang,’ the adoption of microservices and other approaches means small teams work on different parts of the overall project and independently deploy the results.

    “That’s a huge jump,” he said. “A different capability is needed to do that.” Part of that capability involves resolving dependencies by using technology so they don’t need to be handled by people or processes.

    But practitioners sometimes miss the point when they hear about organizations deploying hundreds of releases a day, and then they make the assumption that the practices and technologies required are not relevant to them because they don’t want to deploy that frequently.

    Hering argues that it is really about having a deployment process that can support as many releases as you care to make, with “so little risk that it’s as natural as breathing.”

    Can You Really do Continuous Delivery?

    Many practitioners say they do continuous delivery, but Hering tests them by asking whether they could deploy a system at 4 a.m. the next day. If they are happy with doing that, they probably are on top of continuous delivery; if not, there’s probably something wrong, such as one or more manual steps that still haven’t been automated. Similar litmus tests can be created to cover other aspects of DevOps activity, he suggests.

    Processes that are robust enough to detect any problems before the altered code reaches the customer or user empower DevOps teams to make small changes as required (whether the triggers were user requests, a realization that performance could be improved, or to implement a new business or compliance requirement, for example) without putting the business at risk.

    Accenture has developed its own DevOps platform—a collection of open source based tooling—that provides a common reference point, and Hering recommends other organizations do something similar, warning that “it requires a difficult conversation about what is federated and what is centralized” because there needs to be a balance between the two extremes.

    Changes to DevOps capabilities should be treated as scientific experiments, Hering suggests. The hypothesis might be that increasing unit testing coverage will decrease the number of defects, so you increase the coverage in a particular project (experiment), measure the defects (results), and draw a conclusion. But “very few organizations are that mature,” he conceded.

    Training is Important

    Another danger is that a lot of the information that practitioners hear (eg, at conferences) and read (e.g., in blogs) has been curated by organizations’ marketing teams, and that makes it too easy to focus on specific products or technologies rather than focussing on the issues that are really important to the organization.

    So training is important to make sure everyone involved understands the concepts behind DevOps, and how to do unit testing and continuous integration. An increasing number of organizations say they want to adopt DevOps and Agile practices, but they don’t always understand the concepts and sometimes don’t really want to move out of their comfort zones.

    Other pieces of general advice from Hering include asking why the organization is looking into DevOps (i.e., what are the goals and expected outcomes), making sure someone is going to drive the project, running cross-team workshops with a neutral facilitator to break down existing silos, and taking advantage of your peers’ experience in other organizations rather than trying to re-invent the wheel.

    Very importantly, don’t try to move to DevOps at scale in one fell swoop because it is too much to swallow whole. Rather, take a piecemeal approach by focussing on a few aspects at a time and how they fit in with the next steps of your current project.

    Hering’s book, “DevOps for the Modern Enterprise: Winning Practices to Transform Legacy IT Organizations,” was published this year by IT Revolution and is available from Amazon. He blogs about software delivery, Agile and DevOps at Not A Factory Anymore.

    — Stephen Withers

  • DevOps Chat: DevSecOps with ShiftLeft CTO Chetan Conikee

    DevOps Chat: DevSecOps with ShiftLeft CTO Chetan Conikee

    Security in the DevOps process has gotten a lot of attention lately, as companies grapple with ways to include security further up the application development process. The industry is still very much a nascent space, as players remain engaged in the security-versus-speed conversation—one always is sacrificed for the other. ShiftLeft, however, doesn’t believe that’s the case.

    In this DevOps Chat, Chetan Conikee, CTO of ShiftLeft, discusses his company’s approach to DevSecOps and how it can help keep the security department from being the “department of ‘no.’”

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone it’s Alan Shimel and I’m here for another DevOps Chat – DevSecOps related. I’m joined by Chetan Conikee, a CTO and cofounder of ShiftLeft. Chetan, I hope I didn’t mess your name up too bad.

    Chetan Conikee: Absolutely not, you did a great job. Thank you Alan, appreciate it.

    Shimel: Thank you. So Chetan, as I mentioned you’re the cofounder CTO of ShiftLeft – we’re going to talk a little bit more about ShiftLeft later in the show – but I wanted to start off talking about what is really one of the hottest topics in our world today and that is this whole whether you want to call it DevSecOps or DevOps and Security or Security Shifting Left – hence the name – talk to AppSec, some other people do – you know what about in your world? Are you seeing this kind of emphasis like never before on what some are calling DevSecOps?

    Conikee: Absolutely. Great question, Alan. Let me first start with the term shift left because it has two definite representations; one is a word and the other is a noun. Formerly ShiftLeft started as a way of doing things; meaning taking a practice and moving towards the left in order to reduce what they call as the meantime to repair. And that something could be testing or perhaps measurement of security as well.

    So when we adopted that name or changed the word to a noun we wanted to take this seriously; meaning how can we effectively build a product that can measure the security posture of another product at the left, informed from the right as well because often DevOps is nothing but a pipeline – an affective pipeline that is operating both at automation and high velocity. DevOps is all about taking code, building, packaging and thereafter deploying into your production ecosystem.

    But it doesn’t just end at deploying: it ends at measuring and feeding back how to optimize your systems thereafter. Often security does not fit well into this high velocity motion because most of the security products today are legacy or antiquated. These technologies like static analysis, dynamic analysis or perhaps a web application firewall finds it hard to fit into this streamline DevOps biplane. And I use that term emphasis with heart simply because these tools are producing outcomes and these outcomes are nothing but logs, information, alerts and all of this is sent back to humans in silos. And it is upon the human to figure out how to correlate this information and take affirmative action.

    So in essence this is impeding velocity rather than accelerating velocity, which DevOps is all about acceleration. As a consequence security gets left behind in organizations.

    Shimel: Can I tell you – I’m sorry – that was one of the best ones I’ve ever seen – one of the best definitions I’ve ever heard.

    Conikee: Thank you. Appreciate it. So we take this seriously as well because what we are trying to do is convert that definition into automaton, meaning how can you measure security thereafter quantify threats to vulnerabilities because often vulnerabilities are measures on the left, threats are measured on the right, so how can a human comprehend both these vectors, associate them and then address and fix these issues, because security is a huge concern these days.

    Shimel: Yeah. Agreed. So Chetan this brings up something I wanted to spend some time talking about here today and that is it’s a – not a survey but a study that ShiftLeft’s done – I think you guys had a partner on it – why don’t you share a little bit with our audience kind of just laying the groundwork there.

    Conikee: Absolutely. Today we are announcing the industry’s first real world benchmark of what we call a continuous application security solution. And in order to conduct this benchmark test we partnered and collaborated with Cobalt which is a leading provider of integration testing. They have some of the world’s best penetration testers working for them.

    So in order to conduct this benchmark test we submitted two instances of an application – a vulnerable application. By vulnerable I mean it essentially contains a certain set of vulnerabilities in it which we often test against in order to measure the efficacy of our platform.

    In this test we took that application and we deployed two instances in production. One instance was unpredicted: the typical instance that represents these vulnerabilities and have no protection applied to it. Whereas the other instance was protected by ShiftLeft’s one-time agent.

    So the premise of this test was to essentially let these penetration testers conduct tests against these two applications and thereby come back with results. And both these results had a certain degree of focus. The results were to identify what vulnerabilities can be declared by these pen testers upon the application that is not protected by ShiftLeft and thereafter subject the same set of tests on the application protected by ShiftLeft and come back to let us know whether they could penetrate that application or not, or perhaps could exploit that application or not.

    So this was a 14-day exercise and we defined the scope for this exercise – meaning what we essentially did was identified the most vulnerable or relevant applications called and racked by OWASP top ten and thereafter opened these applications to the Cobalt pen testers.

    Now as they began this exercise and Cobalt had hired essentially three white-hat hacking experts to attack both these applications. Cobalt was able to find and exploit all the six vulnerabilities in the unprotected application which is a validation for the fact that this was a beta application, it had the vulnerabilities and these exercises were successful from the pen tester’s perspective.

    Now they took that same exercise and applied it to the application protected by ShiftLeft and the outcome was they were not able to exploit any of those scoped vulnerabilities that we had described in the application.

    So the proof point for this exercise was to make ensure that ShiftLeft took the onus of protecting the application from any existential breaches or exploits applied by both potential white hats or black hats in the real world.

    Shimel: Got it. So fascinating stuff here. Talk to me now – so how – and forgive me and forgive our audience – we may not be knowledgeable about ShiftLeft – how does ShiftLeft in your company – not as the noun or verb here – how does what you do at ShiftLeft play into this Chetan?

    Conikee: Absolutely. Great question Alan. ShiftLeft is the industy’s first convert solution that seamlessly integrates into DevOps pipeline and protects the application by identifying its attack surface without reacting to threats. And let me explain what I just described in a moment.

    Often security solutions that have been thriving over the past few decades are built to essentially identify and understand exiting threats and thereafter protect the application. And by that I mean often when a threat is applied or an exploit is applied on the application that threat is published in public databases like missed CBEDBs and NBDBs.

    Then after all of these instruments that protect the application are validating every request applied on this application informed of the threat landscape. Now often threats have a lifecycle, meaning an attack or attacks an application by identifying potential breach paths. Now after they attack it is titled as an unknown vulnerability and when it is discovered it becomes a zero day vulnerability and thereafter when it’s published in a database it becomes a known vulnerability.

    Now note that often organizations are exposed in that journey from unknown to zero day known because it’s yet to be published. And for all these instruments that are protecting applications there is yet to update its policies to thereby protect the application.

    So we at ShiftLeft have devised a convert solution that first of all understands the applications evolving at that service. Now in the world of DevOps we deploy application multiple times a day, a week or a month. Now as the application evolves to serve a company’s business needs the application’s attack surface is evolving as well. It’s either heading in a positive drift or a negative drift. Often more times it exists or traverses in the negative side because engineers are coding at high velocity and when they code they don’t take security as a function into consideration.

    As a consequence attackers can figure out more creative ways to exploit the evolving attack surface of the application.

    So ShiftLeft has devised a technique that automatically processes byte code into the CI portion of the CICD of DevOps and extracts what we call is the attack surface of the application. Now from the attack surface we extract a policy: the policy that defines how to protect the application in one time because we do not want to feed these alerts back to humans and ask humans to correlate and address and prioritize these vulnerabilities.

    So in the spirit of respecting the fast motion of DevOps we extract the security profile from this attack surface and bootstrap an agent that is instrumented with the running application.

    Now the job of the agent is to act like one-fold full-time employee. The agent has taken the onus of identifying what is a potential imminent threat that is applied on the application by a black hat hacker and thereby understand better this particular track that’s taking this application into an inadmissible state because often attackers want to first take the application into a state that they wish to take it to and thereafter either exfiltrate data from the application or perhaps install some malicious payload on the host.

    So the job of the agent is to identify and segregate malicious intent and thereafter prevent that particular intent from manifesting.

    Shimel: Now Chetan I sit here listening to you – and keep in mind I have 20 years – 18 years in the ______ site space and I remember writing articles and papers on when is a zero day a zero day, when is it less than a zero day, you know, this whole discussion around what we can do to make our applications less vulnerable.

    And what amazes me is – I think we all agree, right, application security – at least for the last three to five years, maybe more – has really been at the forefront of cybersecurity research and so forth. And it’s only now that we’re starting to see solutions like ShiftLeft which are kind of not the same old same old taking a different view to an old problem or a different solution to an old problem.

    And yet, you know, I just got back from Black Hat – I’m not sure if you were there – we hear about one breach after the next and they’re still spinning money out of ATM machines. Are we finally on the right track to you think? Are we making progress?

    Conikee: Great question Alan. I would say that we have begun to make progress. You know, there is a journey, we have to embark on this journey and that journey means taking a practice and embedding into our typical pipeline – a pipeline of how we build applications, deploy applications and protect applications.

    So this is a beginning but a great beginning. But what has enabled this beginning is inspiration. You know often we learn from other systems and what I’m sensing is security is learning from DevOps. DevOps is all about automation, meaning before Amazon – the advent of Amazon or any public cloud like Azure or GC there was – the notion of provisioning a host took more than one step: we had to write a multitude of scripts in order to provision a simple physical appliance.

    And with the advent of companies like Chef Puppet and the public cloud they created this concept called this cloud formation; meaning how do you provision a virtual appliance in a matter of seconds and make it predictable thereafter? Because there is a system of record of your provisioning script and its evolution thereafter – that is one part. The other part is the predictability: how can you assess that particular script and understand its posture? Posture from a resource consumption perspective and resource provisioning perspective?

    Now if you take these two same principals to the antiquated world of security – and I use the term antiquated because in the past security was all about reacting to threats and alerts and then we had to deal with how to prioritize alerts because alerts can contain mixes of true positives, false negatives, false positives, et cetera. So how can we steal a page from the book of DevOps? How can we automate security? Meaning you’re creating code, from this code how can we automatically extract its security posture?

    Because in the world of security we are assessing code with three particular filters – or what they call SOSAs, sanitizers and syncs – SOSAs are where consumers interact with our application; sanitizers are where we are validating that input; and syncs are all communication points outbound from an application perspective.

    Often attackers are attempting to create new syncs after they successfully exploit the application. So how can we extract this particular fabric or script and thereafter take a security function into consideration?

    So this is our goal at ShiftLeft and we are hoping that this becomes a norm and other companies like us are adopting the same principal as well.

    Shimel: We can hope can’t we? But it’s interesting. You know I – what’s interesting Chetan is no developer raises their hand and says, “I want to develop insecure code.” No ops person says, “Boy, I want us to be the victim of a breach or have a security incident.” Nor does any security person say, “I hate the rest of the IT team so much that I hope they get hacked.” Right? None of this is true.

    But yet we have problems – and some of it granted is not just from a technology or toolset perspective, a lot of it frankly is cultural, right, as I’m sure you’ll agree as well. You know, and any time we could use tools that help foster culture, that help foster greater communication and teamwork – I mean I think we all benefit from it, right?

    And I hear a little bit with ShiftLeft, you know, this is something that I think is a byproduct if you will of your solution, is that true?

    Conikee: Absolutely. Well said, Alan. For the most part security should be an enabler rather than a department of no.

    Shimel: You’ve got it.

    Conikee: And security should – there should be a common lingua franca between various departments: meaning security, engineering, quality assurance and operations should speak the same language. The language should be comprehensible so that it becomes actionable.

    Shimel: Amen. Amen. You know, Chetan when we first started I think I mentioned to you the time goes so darn quickly.

    Conikee: Absolutely.

    Shimel: We’ve blown past our 15 minutes onto 20 here so we may have to call it an end but for people who may be interested in the recent study you did with Cobalt – and my friend Carolyn Long is a VP at Cobalt and she is one of the smartest people I know in security – where can they get more information?

    Conikee: Absolutely. Please visit blog.shifleft.io and on our blog we have a recently trending article that gives you the necessary detail about this exercise. And at the end of the article is the published benchmark’s test for those that want to delve into the detail – which I highly recommend – and thereafter visit www.shiftleft.io and – or contact us; we are happy to onboard your application and thereafter protect your application as well.

    Shimel: Fantastic. Chetan Conikee CTO co-founder ShiftLeft. Thanks for being our guest in this episode of DevOps chat and continued success with ShiftLeft – your success is all of our success.

    Conikee: Thank you Alan. Pleasure, and thank you for hosting us.

    Shimel: Okay. This is Alan Shimel for DevOps Chat. You’ve just listened to another DevOps Chat. Have a great day and see you soon everyone.

    — Alan Shimel

  • Microsoft Revamps Approach to DevOps on Azure

    Microsoft Revamps Approach to DevOps on Azure

    Microsoft this week unfurled a broad range of DevOps services for the Azure cloud that are intended to make it easier for organizations to embrace modern application development and deployment processes.

    Jaimie Cool, director of product management for Azure DevOps, said it’s fundamentally simpler for organizations to embrace DevOps processes using tooling hosted in the cloud because they don’t have to spend time setting up the underlying infrastructure themselves. Once they master those processes in the cloud, organizations can take the tooling provided by Microsoft and extend it out to either instances of Azure running in a local data center or Windows Server platforms.

    The Azure DevOps portfolio spans Azure Pipelines, a continuous integration/continuous development (CI/CD) platform that supports any language; Azure Repos, a private repository based on Git; and Azure Test Plans, a wide range of testing tools. Azure DevOps also includes Azure Artifacts, which provides Maven, npm and NuGet package feeds from public and private sources, and Azure Boards, a suite of collaboration dashboards and reporting tools.

    Microsoft is positioning Azure DevOps as an evolution of Visual Studio Team Services (VSTS). VSTS users will be upgraded into Azure DevOps projects automatically. Organizations that are using the on-premises Team Foundation Server (TFS) component of VSTS will continue to receive updates based on features made available in Azure DevOps. TFS will be rebranded Azure DevOps Server starting with next release.

    As part of this launch Microsoft is also making Azure Pipelines available for free with unlimited minutes for 10 parallel jobs for every open source project. Major open source projects already using Azure Pipelines for CI/CD include Atom, CPython, Pipenv, Tox, Visual Studio Code and TypeScript.

    Cool said that when it comes to application development, too many organizations overlook the critical role of DevOps processes in making a project a success. There’s a tendency to focus too much on features rather than the tools that enable an organization to deliver those features consistently. DevOps processes are crucial when it comes to improving the quality of software and the velocity at which upgrades are delivered, he said.

    But the ultimate DevOps goal is to not to increase the number of releases put into production over a specific amount of time such as a week, month or quarter, he added. Rather, organizations should be able to updates to applications whenever they are ready or required.

    Cool noted there’s a high correlation between adoption of Docker containers and an appreciation of the value of DevOps. As organizations embrace microservices-based architectures based on containers, the complexity of the IT environment overall increases. That issue soon may be coming to a head for more organizations, as Microsoft is now seeing containers all over the place, he said.

    Longer term, Microsoft expects to see machine learning incorporated into DevOps processes as well, Coole said, noting that it’s still early days as far as machine learning and DevOps are concerned.

    Clearly, Microsoft is trying to provide a more sophisticated DevOps experience as part of an ongoing battle with Amazon Web Services (AWS) and other cloud service providers to attract developers to its platform. As those efforts continue to expand, the number of organizations Microsoft schools on the DevOps processes should increase correspondingly.

    — Mike Vizard

  • Speed Rules in Chef’s DevOps Survey

    Speed Rules in Chef’s DevOps Survey

    DevOps is all about streamlining and accelerating. Organizations that embrace DevOps are driven by a focus on maximizing the combination of efficiency and effectiveness—which explains why speed is the central theme of Chef’s “The State of Enterprise Applications” survey.

    Chef surveyed nearly 350 application and operations professionals in an effort to understand trends in DevOps, identify how the industry is shifting and get an idea of what the future of DevOps looks like. What it found is that speed is one of the primary driving factors for organizations that function at the cutting edge of technology. Chef also found that organizations are eager to adopt new platforms that promise to help them move faster.

    The Need for Speed

    There are a variety of ways to measure success for application development and deployment. You can look at the features and capabilities of the app and whether it delivers the expected functionality, or you can determine success based on user feedback and how satisfied users are with the app experience. According to the Chef survey, 72 percent of organizations are focused on speed as the primary measure of a successful app deployment.

    That said, it generally takes weeks—or even months—to get an app developed and deployed. More than 60 percent of survey respondents shared that it takes days or more to complete an application build, and 55 percent indicated that it takes four or more builds before an app is ready to be deployed. Almost 60 percent said it takes days or more to actually deploy the app once the final build is approved.

    Platforms and Tools to Accelerate App Deployment

    In the quest for speed, organizations are moving to platforms and tools that can help accelerate development and decrease the time it takes to make an app available. According to data from “The State of Enterprise Applications” survey:

    • Only 9 percent of organizations are using public cloud for more than 50 percent of app deployments today, but that is expected to increase to 32 percent by 2020.
    • There is a 144 percent increase expected in the next two years in the number of organizations using container technology for more than 50 percent of app deployments—to 22 percent from 9 percent today.
    • The number of organizations using microservices for more than 50 percent of app deployments is expected to double—to 24 percent from 12 percent—in the next two years.
    • More than 80 percent of survey respondents are adopting a multi-cloud strategy.

    Putting App Deployment in High Gear

    Chef is in the business of automating and streamlining app development and deployment, so it should come as no surprise that the survey included questions related to that as well. The report states, “The most successful software-centric organizations use one consistent way of building, deploying, and managing applications.”

    More than 9 out of 10 (93 percent) of survey participants agreed that an application packaging solution that allows deployment to any environment would be valuable. This is especially true when developers have to deal with hybrid or multi-cloud environments.

    If speed is your primary measure of success for app deployment, you need to make sure you have the tools and processes necessary to develop and deploy applications as quickly as possible. Chef’s report shows organizations are well on their way.

    — Tony Bradley

  • Why the DevOps Trinity is Key for Digital Transformation

    Why the DevOps Trinity is Key for Digital Transformation

    As digital technology continues to disrupt and transform businesses across industries and around the world, the ability to deliver high-quality software rapidly will make the difference between survival and extinction for many companies. DevOps seeks to change the dynamics in which operations and development teams interact. Ultimately, successful adoption of DevOps and the process of continuous delivery are likely to determine whether an organization thrives or fails in the digital age.

    To build a sustainable DevOps culture and achieve true DevOps success, organizations need to consider the DevOps Trinity—people, processes and tools—and understand how to connect all three:

    People and Culture

    The core tenet of DevOps is a culture of collaboration and shared goals, which eliminates finger-pointing and promotes teamwork, with everyone working together in support of the same outcome—reliable software quickly delivered to production. In essence, the goal is to enable the different stakeholders in the software development and delivery process to reach the mutual understanding and empathy needed to drive alignment on shared goals. To achieve this change, teams need to have trust, honesty and responsibility.

    Process and Practices

    DevOps aims to achieve predictable, efficient, secure and sustainable operational processes. Using a DevOps approach, simple processes become increasingly programmable and dynamic. Automation supports this objective by using technology to streamline the steps within the process.

    Tools and Technologies

    Some categories are more essential in a DevOps toolchain than others, especially continuous integration (build) and infrastructure as code (configure) tools. The common elements of the toolchain include applications for coding, building, testing, packaging, releasing, configuring and monitoring. Often, rather than a single tool, there are sets of tools (or toolchains) of multiple tools, that make up the process.

    A sustainable DevOps organization cannot be achieved without all three components of the DevOps Trinity.

    For those looking to learn more about people, processes and technology needed for successful DevOps implementation, join us in San Francisco Sept. 16-19 for DevOps World | Jenkins World. With this year’s conference theme “TRANSFORM,” attendees will learn how organizations are transforming software delivery, adopting DevOps and returning business value to their organization from DevOps initiatives.

    Don’t miss Viktor at DevOps World | Jenkins World! Be sure to register today for 20 percent off your registration using the special DevOps.com code just for our readers: JWDEVOPSCUST

    — Viktor Farcic

  • DevOps Ethics: The Danger of Unethical Code

    DevOps Ethics: The Danger of Unethical Code

    The accident could not have come at a worse time for Uber. Already under scrutiny following several high-profile lawsuits for sexual harassment, intellectual property theft and other accusations that played at least as significant role in founder and former CEO Travis Kalanick’s departure, the ride-hailing firm’s driverless test vehicle was involved in a fatal pedestrian accident earlier this year. It was later revealed the test driver, who was paid to take over driving in case of an emergency, was watching an episode of “The Voice” and thus too distracted to notice a pedestrian who suddenly appeared out of the darkness directly into the car’s path.

    Pending the final verdict of the National Transportation Safety Board (NTSB) investigation, it remains to be seen whether the Uber test driver could or should have been able to avoid the pedestrian or had time to apply the brakes to lessen the impact. However, the Uber SUV’s self-drive sensor system reportedly failed to detect and react to the pedestrian due to software failings—in other words, the system failure likely can be attributed to just plain bad code.

    Prior to the accident, Uber software developers and engineers were already struggling with ethical concerns regarding algorithms they created that, among other things, allegedly were designed to exploit underpaid drivers, deny services to passengers and skirt governmental regulations. A former software engineer, Susan Fowler, also described a toxic culture when filing a sexual harassment legal complaint against Uber.

    However, the allegations levied against the company, even if true, can be seen as an anomaly in software development and DevOps culture in general. One can suppose, for example, that basic human decency dictates most software developers refrain from engaging in unethical behavior and designing code for nefarious reasons. Data from recent studies supports this assumption.

    According to a recently published meta study by Stack Overflow, only a fraction of more than 100,000 developers surveyed said they would write unethical code or “that they have no obligation to consider the ethical implications of code.” When asked what they would they do if asked to write code for an unethical purpose, 58.5 percent reported they would not, while 36.6 percent said it depended on what it was. Only 4.8 percent said they would.

    However, the report describes a lot of “ethical gray.” “Developers are not sure how they would report ethical problems and have differing ideas about who ultimately is responsible for unethical code,” Stack Overflow said in a statement.

    Meanwhile, the fact that many of Uber’s arguably poor ethical choices originated from upper management and its DevOps team points up how, conversely, it is up to DevOps to instill ethical guidelines for organizations to follow. To that end, DevOps must create, among other things, “full audit trails showing who developed what code and when and a culture that enables developers to voice ethics concerns without fear,” said Torsten Volk, an analyst for Enterprise Management Associates (EMA).

    “Knowing that a full audit trail is in place will make DevOps more likely to raise a red flag with their team leads,” Volk said. “Then, ideally, the outcome of this discussion should be documented in a source code management system.”

    In addition to sending the message to their developers that following ethical principles during code creation is the right thing to do, organizations should support an ethical culture for software development—as well as for the entire enterprise.

    “It is critical for the entire business to understand the net positive impact of ethical conduct in development on the businesses risk profile and overall bottom line,” Volk said. “Similar to GDPR compliance, there should be awards for outstanding ethical conduct in coding that can be published to the outside, showing customers the value of doing business with this company.”

    — B. Cameron Gain

  • Keynotes and Announcements at DevOps World | Jenkins World 2018

    Keynotes and Announcements at DevOps World | Jenkins World 2018

    Each year DevOps World | Jenkins World is bigger and better than the year before. This means the announcements at the show also continue to evolve to keep pace with the rate of innovation. With the tremendous growth in DevOps adoption, the event will highlight the contributions of industry leaders and provide insight for attendees to better optimize their DevOps transformations. This year’s conference, taking place Sept. 16-19 in San Francisco and aptly themed “TRANSFORM,” will showcase the ways organizations are transforming software delivery, adopting DevOps and returning business value to their organization from DevOps initiatives.

    CloudBees has already released two big pieces of news for DevOps World | Jenkins World: The first is the name change from simply Jenkins World to denote the inclusion of the larger software development industry, while the second is the addition of a conference in Nice, France, to reach the global community of DevOps practitioners.

    Although most news is top secret until the event, there will be plenty of exciting announcements coming out of DevOps World | Jenkins World from CloudBees, sponsors and the Jenkins community. Attendees will experience keynote presentations on Tuesday, Sept. 18, where all the latest from both CloudBees and the Jenkins project will be announced. This will include news around the growing trend of “as-code,” collaboration between CloudBees and the Jenkins community and serverless capabilities. All announcements will underscore how organizations can adopt modern technology and infrastructure automation processes for accelerated software delivery.

    Along with CloudBees-specific and industry announcements, Dr. Nicole Forsgren, co-founder, CEO and chief scientist at DevOps Research and Assessment (DORA), will keynote the conference in San Francisco this year. In addition to her keynote, “The Data Behind DevOps: What Does it Take to Be a High Performer?,” which will cover insights into the key leadership, technical, architectural and product capabilities that drive these outcomes, she will also be hosting a session, “Leading Through Change,” which explores the aspects of leadership that drive successful outcomes.

    Additionally, DevOps World | Jenkins World San Francisco will boast more than 100 sessions this year. With a variety of industry experts covering everything from security, pipeline automation and containers to DevOps adoption and continuous delivery best practices, here’s a few sessions you won’t want to miss:

    With DevOps World | Jenkins World only days away don’t miss your chance to sign up for 20 percent off the cost of registration with this special code just for DevOps.com readers: JWDEVOPSCUST.

    — Heidi Gilmore

  • Continuous Testing in the ‘2018 Accelerate State of DevOps’ Report

    Continuous Testing in the ‘2018 Accelerate State of DevOps’ Report

    Here’s a peek into what continuous testing means to DevOps today

    The “2018 Accelerate State of DevOps” report is the brainchild of Dr. Nicole Forsgren, Gene Kim and Jez Humble at DORA (DevOps Research and Assessment). Based on five years of research, with more than 30,000 data points from thousands of companies, the project aims to understand precisely what practices enable teams to deliver better software faster.

    The 2018 report places an increased focus on testing and quality, including a new report section dedicated to continuous testing.  Here are three key report takeaways that are important for continuous testing:

    1. Testing must change—significantly—to keep pace with DevOps

    Consider this:

    • Elite performers deploy code on-demand, multiple times per day.
    • At elite performers, less than one hour elapses between code commit and production.

    The rate of change is accelerating—fast. Testing must somehow keep pace. Evolving testing for DevOps is critical for realizing DevOps’ full potential in terms of accelerated delivery, agility and all the derivative business outcomes outlined in the previous point.

    2. High rates of test automation (~90%) are essential for DevOps

    At elite performers, manual testing represents only 10 percent of the total effort. Even the 30 percent manual testing rate for low performers is significantly better than the industry average of 80 percent+ manual testing (including teams that have not yet adopted DevOps).

    The importance of test automation is underscored by the findings of a recent Forrester report that’s focused specifically on what quality practices separate DevOps leaders from DevOps laggards. That research found that DevOps leaders are:

    • Transforming software testing into continuous testing by adopting five core practices, such as automating end-to-end functional testing and integrating testers into cross-functional teams.
    • Almost twice as likely to consider automating the software quality processto be a “critical business differentiator” (53 percent vs. 27 percent).
    • Significantly more likely (by 23 percentage points) to have high levels of automation for key testing and QA processes (test case design, functional test automation, test data management, etc.).

    3. Quality is correlated to DevOps success

    Elite performers have a 7X lower change failure rate than low performers. They also spend 2X less time fixing field-reported defects.  Exactly what DevOps practices are contributing to the impressive quality outcomes being achieved in the top-performing organizations? And how are different quality practices contributing to DevOps success?  This is certainly an area that’s ripe for further research and analysis.

    Want to learn more about this report’s findings—and what it all means for software testing?

    Join Nicole Forsgren, PhD, CEO and Chief Scientist at DORA and Wolfgang Platz, Founder and Chief Strategy Officer at Tricentis, for a webinar to explore “Continuous Testing’s Role in DevOps success.” The focus will be on helping IT leaders understand:

    • Why and how high-performing teams make Continuous Testing a linchpin of their DevOps process.
    • What specific strategies and practices enable high-performing teams to deliver faster and dedicate more resources to innovation.
    • Which quality-related technology and process investments have the greatest impact on DevOps success.

    — Cynthia Dunlop

  • Open Mainframe Project Launches Zowe to Advance DevOps

    Open Mainframe Project Launches Zowe to Advance DevOps

    The Open Mainframe Project has launched Zowe, an effort to make mainframes running z/OS both more accessible and programmable using REST application programming interfaces (APIs).

    Announced at the Open Source Summit, the Zowe project is being led by IBM, CA Technologies and Rocket Software.

    Matt Hogstrom, chief architect for z/OS Systems at IBM, said the goal of the Zowe project is to attract a new generation of IT administrators to the mainframe platforms and make it simpler to include mainframes within the larger scope of an integrated set of DevOps process spanning multiple platforms.

    In addition, IBM, CA Technologies and Rocket Software collectively are trying to create an ecosystem around the mainframe that resembles more of the types of interactions that occur between companies that participate in the Linux community, Hogstrom said. The Open Mainframe Project operates under the auspices of the Linux Foundation.

    Now that IBM mainframes are more than 50 years old, IBM and its allies are increasingly relying on open source tools to make sure mainframes stay relevant for another 50 years, he said.

    To achieve that goal, Zowe provides access to an extensible z/OS framework that provides new APIs and z/OS REST services. The Open Mainframe Project, as part of Zowe, has also created a unifying workspace based on a desktop app container accessed via a browser and a scriptable command line interface (CLI) that makes it easier to integrate z/OS into cloud and distributed environments using a set of low-code tools.

    Greg Lotko, General Manager for Mainframe at CA Technologies, said the contributions to the Zowe Project made by CA Technologies are based on CA Brightside, a set of DevOps tools developed specifically for mainframe environments.

    The biggest challenge the mainframe community now faces is a dwindling pool of talent. Most college graduates today have limited exposure to mainframes at a time when many of the IT professionals who do have mainframe skills are retiring. In the absence of skills to manage mainframes, IT organizations wind up making decisions regarding where to put workloads based on the availability of expertise available to run those platforms. IBM, CA Technologies and Rocket Software all have a vested interest in leveraging DevOps tools and processes to eliminate the silo that currently exists between mainframes and other platforms by making it easier to call services residing on a mainframe using REST APIs, while at the same time making it easier to manage mainframes within the context of a common set of DevOps processes spanning multiple platforms.

    Mainframes, of course, are still comparatively expensive platforms to acquire. IBM has sharply reduced the cost of mainframes over the years. But the primary economic value proposition of mainframes is that the total cost of operating a mainframe is less than a distributing computing environment running a comparable set of workloads. Mainframes are highly automated, so IT organizations that can afford the cost of entry tend to still favor mainframes for complex transaction processing and analytics applications. The challenge—and opportunity—for mainframe shops now is in turning those applications into a set of reusable services that can be readily invoked from anywhere in the enterprise.

    — Mike Vizard