Tag: devops

  • When AI Met DevOps: Machine Teaching

    When AI Met DevOps: Machine Teaching

    One of my favorite quotes about artificial intelligence (AI) isn’t from a data scientist or tech industry analyst. It’s from a doctor.

    When asked if AI would eventually replace radiologists, Dr. Curtis Langoltz of Stanford University pithily replied “No, but radiologists who use AI will replace those who do not use it.”

    This great insight is highly applicable to IT. Yes, there are many ways we can use AI methods to fully automate a broad range of DevOps tasks. Companies, including CA Technologies, are actively involved in the development of solutions that enable our customers to do exactly that.

    Algorithmic machine learning, however, doesn’t just empower systems to perform tasks and solve problems autonomously. It also makes them great active partners with human beings. In fact, much of what machines learn they also wind up teaching.

    The synergy between AI and human radiologists, for example, stems in part from the fact that digital systems can differentiate about 200 levels of gray in a diagnostic image—compared to only about 16-20 that are discernable by the human eye. Train an AI system with enough images, and that precise cognitive power can more effectively detect that something is going on.

    But for the most effective diagnostic process, you don’t just depend on that detection alone. You use that detection to empower a human diagnostician who can apply a broad understanding of pathologies and deep experience with the complexities of individual patients to deliver the highest quality care.

    In DevOps, we can do the same. We can use AI to capture insights that teach us how to continuously optimize our workflows and processes. We can also use our AI learnings to push our work up higher on the value chain.

    More specifically, the synergy between AI and human intellect can:

    Make development smarter. The speed, quality, and efficiency of development pipelines can be affected by all kinds of subtle factors. A less-than-optimally designed API, for example, can be a small but chronic stumbling block to everyone who has to use it. Scrum outcomes can be undermined by anything from a particular type of technical challenge to a nascent personality conflict.

    By capturing a rich set of DevOps metrics and applying machine learning to those metrics, development leaders can discover process bottlenecks and skilling shortfalls. They can better coach individuals and promote team collaboration. The result: a better working environment that facilitates digital agility for the enterprise and higher satisfaction/retention for valuable employees.

    Make ops smarter. Enterprises are running increasingly volatile and complex workloads on increasingly hybridized infrastructure. At the same time, the tolerance of internal and external users for latency and outages continues to approach zero. There are also real costs associated with performance problems.

    The elastic capacity of public and private cloud does much to help with workload volatility. But adding cloud capacity also has its costs—and end-to-end application performance often depends on back-end systems that are not cloud-based. So not every performance issue can be solved by simply throwing more capacity at it. Nor should it be, if a rearchitecting can fix a bottleneck less expensively.

    Here again, AI can teach us a lot. We can uncover opaque interdependencies in processing load and data throughput. We can spot conditions when it may make business sense to throttle cloud costs that aren’t cost-justified. We can even better understand the real-world conditions—whether patterns in customer behaviors or our own marketing programs—that are driving our demand spikes and troughs. All of this helps us deliver consistently responsive digital experiences at a cost that makes good business sense.

    Make security smarter. AI is already being broadly implemented in security solutions such as endpoint protection and threat response to automate the detection and neutralization of anomalous activities in the enterprise environment. But effective multi-layer security isn’t just about finding and stopping exploits. It’s also about building applications that are themselves inherently less vulnerable to hacking. This is the essence of DevSecOps.

    AI has huge potential value here. We are writing a rapidly growing volume of increasingly sophisticated code. It is very easy for subtle vulnerabilities to hide in that code. As our development practices become more complex—often including multiple contractors—it becomes more difficult to understand exactly where and why these vulnerabilities were introduced into our code. Machine learning can teach us the answers to these questions, so we can more proactively secure our data and our businesses.

    It’s especially interesting to consider what may happen as we start to apply AI to DevSecOps across our organizations, as well as within them. More diverse inputs enable machine learning to discover more factors that impact code pipeline performance. By aggregating our knowledge about how we build, deliver and secure our code, we are all likely to benefit with better practices and stronger guardrails.

    — Cameron Van Orman

  • How Cloud-Native Computing Is Changing IT Job Roles

    How Cloud-Native Computing Is Changing IT Job Roles

    The cloud native age is upon us. This means not only that infrastructure, application deployment and security strategies look very different than they did just a few years ago, but also that the way companies design and fill IT jobs has changed—or should change, at least, for those seeking to stay relevant in our fast-changing, cloud-centric world.

    Which types of new roles are emerging in the cloud-native age? What should employers and employees be doing to make sure that the roles they design and fill meet today’s needs? Keep reading for insight into these questions.

    Traditional IT Job Roles

    Traditionally, IT job roles have been pretty consistently and clearly defined. They broke down into two main groups.

    First, there were developers—who may also have been called software architects, application programmers or software engineers. Whatever the exact job title was, the role centered on designing and writing code.

    Second, there were support people. They might have been called sysadmins, tech support, problem analysts or IT Ops. Their roles could include end user support, backend system management or both. In any case, their task list was limited primarily to deploying and managing software that was written by other people.

    There are a variety of traditional IT job roles as well, such as business analysts, network engineers and security analysts. But programmers and sysadmins were the two main types of IT positions that virtually every organization filled; the other roles addressed specialist needs that may or may not have been a requirement at a given organization.

    The Rise of the DevOps Engineer

    The DevOps movement has changed IT job roles a bit over the past decade. Inspired by the DevOps mindset, companies have moved to create roles that blend development and IT Ops together.

    This is where the SRE and DevOps engineer roles (for both of which there are hundreds of available positions on Monster.com at the time of this writing) came from.

    Yet, although the DevOps movement has spawned the creation of these new roles, it hasn’t killed off traditional IT job titles. People who specialize in just development or IT Ops can still find plenty of jobs.

    Cloud-Native Computing and the Future of IT Job Roles

    That may not remain the case in the future. As the trend toward cloud-native computing redefines everything about the way applications are designed, deployed and managed, the viability of traditional IT job roles is somewhat in doubt.

    To be clear, when I mention cloud native computing, I am referring to the present era in which virtually everything is designed to run by default in the cloud. I’m not suggesting that everything runs in the cloud; that is obviously not the case. What I mean is that we are living in a time when the norm is to deploy in the cloud (often using next-generation infrastructure technologies such as containers or serverless) and conventional on-premises infrastructure has become the exception.

    In an age when sophisticated cloud-based deployment environments have emerged as the default, IT job roles need to change. The landscape as it currently exists (where most professionals fall into either the developer or IT Ops camp, and a handful of DevOps engineers or SRE positions help to unite them) no longer works well.

    Why? Because in the cloud-native age, it is becoming increasingly difficult to fulfill a job role competently without a meaningful understanding of both application development and IT Ops. And having a few SREs on staff is no longer enough to bridge the gap.

    For example, if you want to deploy an application in a container, you’re going to need to know something about scripting and possibly infrastructure-as-code. At the same time, if you are writing application code that will run inside a container, you’ll need an understanding of how containerized infrastructure works, how to break down stateless from stateful components, how to implement communication between microservices and how to handle the unique security challenges associated with containers and microservices.

    In other words, it would be pretty hard to write or deploy a secure, well-designed, efficient containerized application without having some mastery of both software development and software administration.

    On top of this, cloud-native deployments also often require expertise in areas including software-defined networking or scale-out storage. Unless your company hires engineers who specialize in those specific areas (which is often not realistic or efficient, because the company may not need full-time positions in those niche roles) the rest of your IT staff will need to be able to address this need.

    To make things even more challenging, your IT team needs to be able to achieve all of the above while keeping pace with the rapid demands of continuous delivery. Typically there is little time to step back and make a plan for addressing unexpected skills gaps if you don’t have the right roles from the get-go.

    Conclusion

    Ultimately, what all this means is that we are moving toward a future where IT job roles will increasingly involve a broad mix of diverse skills, and specific specializations will become less common.

    That’s not to say that specialist IT job titles will entirely disappear. Some companies will always have a need for people who only do programming, only do system administration or only do software testing, for example. But creating, deploying and managing a cloud-native workload often requires each team member to possess a mix of specific skills that don’t align cleanly with traditional IT job roles.

    That’s why companies need to start hiring for this type of role (call it Cloud-Native Engineer, if you like), and IT professionals should begin preparing to fill it.

    — Ben Bernstein

  • Revisiting My Bet on DevOps

    Revisiting My Bet on DevOps

    On Dec. 29, 2015, I bought some stock. It was a bet on DevOps that my wife kindly tolerated. Since then, the S&P 500 has risen 31 percent and my DevOps portfolio is up 113 percent. This blog is a retrospective on a bet that worked out.

    I was inspired by Nicole Forsgren’s talks and the “State of DevOps Report,” whose data showed better profitability, market share and stock price performance among companies claiming to do DevOps well. DevOps, after all, exists to help the business win, and as digital transformation sweeps industry after industry, technologists increasingly are in a position to make that difference.

    My process has been very, very simple: Companies whose talks at DevOps conferences convincingly convey a passion for DevOps are ones that I would consider buying. Would I do deep research on each one? Nah—whatever I could research aside from DevOps would already be priced in by people who understood that content better than me.

    At the one-year mark, I summarized the results. The crazy project was up 12 percent against an S&P that was up 8 percent—a nice little win. The first six months of 2018 have been tremendous, though: The S&P is up almost 2 percent and the portfolio is up 42 percent.

    A key disclaimer is that I am trying to read corporate culture from the outside. For insiders, I am sure I will have some of this comically wrong.

    Remixing the Strategy (and Portfolio)

    Over the past year and half, I’ve made a handful of trades based mostly on two triggers.

    The first trigger is a signal that a company is losing its commitment to DevOps. I did this with Nordstrom: Its DevOps leaders all moved on to different companies. For example, Courtney Kissler went to Starbucks and Suzanne Conniff was off to T-Mobile. About the same time at a meetup, a Nordstrom employee told me that DevOps had fizzled. I was out. In the last year, Nordstrom is up 7.5 percent while retailers I kept are up: Target 46 percent and Amazon 74 percent. That said, Target is a bit of a difficult case.

    The second trigger is silos. I worry about an either IT-centric view of DevOps or DevOps in just a small slice of the business. Before I invest in a new stock, I want to know the transformation is taking root enterprise-wide.

    Barclays for Bank of America is an example of chasing the all-in company that didn’t work out: negative 8 percent growth versus 25 percent at BoA. Overall though, shifting toward all-in and unicorns has been solid.

    Who’s in Today

    • Amazon: 121 percent
    • Barclays: -15 percent
    • Capital One: 26 percent
    • Cisco Systems: 52 percent
    • Etsy: 340 percent
    • Live Nation: 93 percent
    • Netflix: 235 percent
    • Nike: 20 percent (since December 2017)
    • Target: 0 percent

    Amazon: Amazon’s net gain at 121 percent looks a lot like the portfolio as a whole (113 percent). The shares I purchased in 2015 are up 150 percent. The company is a natural fit, given that its CEO wrote the “two pizza rule” and demands microservices. It is also a hedge, as the company directly competes with much of this list including Target, Netflix and Etsy. With cloud and DevOps often joined at the hip, Amazon’s cloud revenue is also a rough proxy for DevOps growing overall.

    Barclays: Did I invest in a British bank shortly after the Brexit vote? Yeah. It was a bit of a test of the “Everything except DevOps is already priced in” rule. This one hasn’t panned out, but from the outside Barclays is among the banks doing best at DevOps.

    Capital One: Has performed about average among banks that I looked at this morning. I adore its start-up attitude and how the company goes about getting talent and contributing to the community.

    Cisco Systems: Cisco has had some great talks and is undergoing a digital transformation of sorts of its own. The company is doing fine.

    Etsy: Holy cow, Etsy. Etsy is an interesting case in that it has been a DevOps darling for many years. With the stock flagging a bit, the CEO and the CTO (our DevOps hero, John Allspaw) were shown the door and the perception was the grown-up business types were taking over. I increased my bet based on the thought that technical foundations pointed ruthlessly at business problems might work out. When the stock price doubled, I cashed out my original investment.

    I’d be better off had I not sold any, but with as volatile as Etsy is, I was happy to route some of the winnings over to a bet on Nike.

    Live Nation: I saw a great talk from a Live Nation guy at DevOpsDays Rockies, and the company’s stock has paid off nicely since, nearly doubling. Live Nation gets it, and shows a passion for satisfying customers. Being Ticketmaster, it has had a risk of digital disruption knocking it down for years and has built up a strong innovation capacity—exactly what incumbents need to do.

    Netflix: DevOps skills? Check. Good at using data to delight customers? Check. Worth twice what I bought them for? Check. I wrote most of this analysis in early July. Since then, Netflix has had a bad earnings call. It’s still a massive winner so far.

    Nike: I loved Nike’s talk at DOES 2017. But what really struck me was DOES London. In the morning the company spoke about a one-team culture and engaging digitally—good stuff. In the evening a colleague complained his kid was spending $200 on sneakers. A week later, Nike’s stock spiked 10 percent. Yup.

    Target: Oh, Target. Target has done some great DevOps work, but word on the street is that too much of what it did at first lacked a connection back to the business. However, since the security fiasco with stolen credit cards, that has turned around. While its stock is right around where I bought it 2.5 years ago, the last year has shown strong momentum: Target is up 45 percent in the last 12 months.

    2018 Has Been Great

    Over the project’s first two years, I had a nagging worry: I was beating the market, but was I just picking riskier stocks and being rewarded in a bull market? So far the market has been flat in 2018, showing modest 1.7 percent growth through June 30. The DevOps Portfolio, however, is up 42.2 percent.

    Only the banks are trailing the S&P.

    So What Have We Learned?

    • It’s about customers and the business: There appears to be a moment of DevOps backlash when alignment to business outcomes isn’t quite strong enough. When the DevOps culture is strong but redirected back to catering to the business, things can go better. That’s one way to read Target and Etsy’s recent performance. When the transformation fizzles … see you, Nordstrom.
    • Banks may be different: This system really hasn’t worked out terribly well for me in the banking space. I suspect that is because most banks are undergoing similar transformations and may not be as able to differentiate as retailers do. At DOES London we heard similar stories from RBS and Barclays while Lloyd’s is winning DevOps awards at other conferences. I also lacked representation from the digital disruptors—PayPal would have been a good balance to CapOne or Barclays.
    • DORA should be a hedge fund: I hope they have a secret one.

    I’m thankful my that my wife was on board with this little project and I’m very happy that we can take our winnings here as we plot our second honeymoon.

    Of course, professionally I’ve been betting on DevOps a long time, working on UrbanCode continuous delivery tools the last 15 years. That worked out with an acquisition by IBM as it beefed up its DevOps solutions portfolio.

    — Eric Minick

  • Implementing DevSecOps in the Mainframe-Driven Enterprise

    Implementing DevSecOps in the Mainframe-Driven Enterprise

    DevSecOps is emerging as an important trend in corporate IT. It makes sense. With each passing day more applications serve a larger user base. Whereas in the past the typical business application was accessible only from within the confines of an enterprise’s internal network, today, the software-as-a-service (SaaS) paradigm enables millions of users work with a single application.

    In the SaaS paradigm, a single application will service a number of companies and give each user in the company access to data and functionality based on a given company’s subscription plan. Take Saleforce.com for example: There is but one Salesforce.com providing service to thousands of companies worldwide, each with one to thousands of employees. Each company and each employee within a company will have particular access rights to the application. A paradigm in which there is one application servicing millions, perhaps billions of users requires a comprehensive approach to security. The slightest breach can result in havoc. Imagine what would happen if a SaaS application contained a flaw that allowed a company to see the financial data of its competitor that also subscribed to the SaaS.

    Given that the internet is the de facto network for all worldwide, today’s security concerns go way beyond restricting network access. Keeping bad actors away is becoming more difficult all the time. The sad fact is that a seemingly good actor can turn into a bad actor instantly and wreak havoc not only on the servers with the network—as is the case of a DDos attack—but on the application layer as well. In fact, according to IBM, an enterprise’s network layer is half as vulnerable as the application layer, yet more money gets spent protecting the network.

    This is an eye-opening fact and one not on the minds of most application developers. But, it might be, if developers had the benefit of the expertise and ongoing guidance required to implement bulletproof security at the application level.

    Which leads us to the mainframe.

    In today’s world of modern, web-based cloud computing, the mainframe is a major player. Seventy percent of corporate data lives on a mainframe. Also, now that the Linux operating system is pervasive in the mainframe environment, enterprise-level application developers can—and do—write Java, Python and NodeJS code for the Big Iron just as they do for X86 commodity environments. Technologies such as IBM’s z/OS Connect EE and StrongLoop make it possible to use an industry-standard specification such as OpenAPI to expose mainframe services as REST API without a lot of low-level fiddling around.

    This is good news.

    The bad news that application developers are just not that adept at security best practices. They don’t have the experience of a CISSP professional who has spent years, if not decades, in the trenches battling the bad guys in cyberspace. But that was then and this is now. Today we have DevSecOps.

    DevSecOps is the next generation of IT transformation. The goal of DevOps is to create an IT culture that is unified, automated and self-correcting. DevOps combines development and operations into a single organization focused on creating and deploying quality software at ever-increasing rates. DevSecOps adds security into the mix. The scope of DevSecOps activity is not confined to software development for commodity-based X86 servers and mobile devices. DevSecOps is intended to apply across all facets of the enterprise, from mobile to mainframe.

    DevSecOps is about a lot of things. It’s about the adoption of tools such as IBM’s AppScan, a tool that allows an enterprise to implement and monitor a variety of tests (web, mobile, dynamic, static and interactive) in a unified dashboard. It can include leveraging Secure Service Containers to ensure external security and safety from insider threats.

    DevSecOps is about putting in place a set of policies, along with appropriate operational checks and balances, that ensure that the enterprise follows security best practices at all times. It’s about following practices that go beyond episodic security testing. This means continuously analyzing the IT infrastructure to identify vulnerabilities as well as defining ways to mitigate risks and prioritize prevention activities accordingly. It means making compliance to regulations such as GDPR, PCI-DSS, PA-DSS, ISO 27001 and ISO 27002, HIPAA, GLBA and Basel III  an enterprise-wide responsibility, not just something that’s siloed away to the Compliance Department.

    DevSecOps is about acting proactively by using automation to rigorously inspect all code to uncover potential hazards. It means using HTTPS as the default protocol for public-facing URLs. It means making sure that all third-party components are built from source code when possible—and, if building against source is not possible, ensuring third-party components and libraries are certified safe by an accepted authority.

    DevSecOps is about a lot of things, but there is one principle that overrides all others:

    When it comes to DevSecOps, the most important principle to follow is to make sure that a security expert is a starting member of any team involved with making software for the enterprise.

    It doesn’t matter if the company is 30 years old running on a mainframe or 30 days old using native cloud services, there must be security experts as part of its development work from the start.

    This may sound obvious, but it’s easier said than done.

    It’s not a new challenge. It took the enterprise a long time to get QA personnel involved at the start of development process. Before the DevOps/Agile sensibility took hold, QA personnel showed up at the end of the release cycle, well after code was hardened.

    The same is true of release personnel. Before DevOps, release management was given some code and told to just get it out as soon as possible. There was limited knowledge as to what the code was about or the potential impact it might have on the infrastructure. As a result, weekends were spent in war rooms struggling to deploy code that was sparsely documented and mysteriously tested. You can bet that once release management showed up at the first project planning meeting, things changed.

    Now, with the emergence of DevSecOps, it is security’s turn in the tumbler. Security has always been an important part of enterprise IT. The number of compliance regulations on the books attest to the fact. However, security was usually the responsibility of the Compliance Department more than part of the IT organization overall. For many companies, the only time security ever came to the forefront was during audit time. As a result, security practices were more reactive than proactive. And, for many companies, they still are—think back to reactions to the Equifax and Target breaches.

    However, the success of DevOps has not gone unnoticed. The standard features of DevOps—unifying groups toward a common purpose, implementing automation whenever possible and using sprints and retrospectives to facilitate fast releases and address shortcomings quickly—has had positive results. Forward-thinking companies understand that DevOps works, and its successor, DevSecOps, will work provided the essential principle is followed: Make sure security experts have a seat at the table from the beginning.

    For many companies this means transforming from a culture of isolated silos in which managers serve as gatekeepers and powerbrokers to one of unified open groups in which a manager’s job is to assemble self-directing groups and to make sure that all the right people are involved from the beginning of a project. It’s a fundamentally different way of doing business.

    When it comes to realizing the promise of DevSecOps, tools are important. So are processes. But, the most important thing is to make sure that security is built into the fabric of the development life cycle, from start to release.

    DevSecOps will fill the missing link in the software development chain. It has to. There is little choice otherwise. Adhering to the most important principle of DevSecOps—to have security involved as an equal player from the beginning of the process—will go a long way toward ensuring that all software, from mobile and IoT to native cloud installations and mainframe instances, will provide the degree of safety and reliability required to serve the needs of users and companies in the digital economy of the modern world responsibly.

    — Bob Reselman

  • A Right DevOps Approach: Assess Organizational Readiness

    A Right DevOps Approach: Assess Organizational Readiness

    Driving business in this fast-paced world is maddening as owners have to remember customer preferences, beat market competition and similarly cater to different things within the organization’s radius.

    How a business owner manages all this defines the business success, which is gauged through outcomes in the form of smart products, point-on services and almost-immediate feedback. Bank applications, the best smartphones and interactive technology are all proof of this.

    But what is it that stands at the heart of it all?

    The Right DevOps Approach

    When enough is done and businesses still find that there’s a missing piece that will complete “the successful business picture,” they go back to figuring out what and how they can fix the problem. They never come to realize that they will have to consider revamping their organizational structure to meet the growing demands of their influential business.

    How, then, do you assess your approach to DevOps?

    While most believe that it’s a technological approach that they should incorporate in their business, it’s more of a cultural approach. To implement DevOps into your existing organizational structure, you first must look at its current state of readiness.

    Doing this is important, as it helps decision-makers understand how they can embed the smart collaboration after a thorough consideration of the challenges that stand in the way of DevOps implementation. Once the initial assessment is done, business owners need to ask themselves three questions before assessing DevOps readiness:

    1. Is there a Management-Employee Agreement? A successful DevOps process not only relies on collaboration between Development and Operations, but also needs a top-down (management-employee) agreement. Once that’s in place, the company is already halfway through the success road.
    2. Is there a Plan in Place? Many firms just barge into technology like it’s all they need to reach their finish line. Stop! Wait! Think! Owners need to have a detailed strategy, equipped with process tools and goals clearly outlined and best practices chalked out. Once this is done, the culturally different teams need to collaborate and work ways to learn and equip themselves with the technologies and practices of each other’s processes. With all this in place, organizations will be ready to take the DevOps jump.
    3. Is the Organization Ready to Tread the Ocean? Now that the plan is in place, what’s next? Organizations, as mentioned earlier, are in hot pursuit to experiment with what they’ve learnt new. Anything new is fancy, but humbleness is the key! Starting small will set the new cultural shift to completely settle in its new mold. To run the boat in big waters, you first need to test it in small water. Similarly, to test the success of DevOps for a big business project, you first want to test its adaptability to a smaller one. Once you’ve cut off from the harbor, you are all set to wade the ocean.

    Conclusion

    Most business players underestimate the ability of DevOps with whatever industry rumors they hear and some of their own pre-conceived notions. Some other think that they know it all, but what matters is having a strategic approach to first considering DevOps and its tools, and then adapting it accordingly.

    Once the DevOps automation is in place, organizations will be busy reaping the benefits of its successful implementation.

    — Veritis

  • How Can DevOps Enable Your Software Testing efforts?

    How Can DevOps Enable Your Software Testing efforts?

    Changing market dynamics are pushing the need to include DevOps in your software testing exercise to help meet business objectives in providing a consistent and flawless user experience.

    Digital transformation is not an easy task for business enterprises. There are myriad issues to conquer, such as department silos, legacy systems and a well-entrenched work culture that often refuses to align with the business goals. Needless to say, the imperatives of reaching out to the market quickly and with quality products often are not achieved because of these issues. To eliminate the bottlenecks that end up blighting business enterprises, a growing number of organizations are adopting DevOps, which involves an end-to-end automation of processes, be it for development, testing or deployment.

    DevOps takes the Agile methodology a step further by involving all the stakeholders of an enterprise. The DevOps testing strategy encompasses continuous improvement of software products to address the changing customer preferences.

    In DevOps software testing, the aim is to detect and eliminate glitches proactively to reduce the cost and time to fix issues that can lead to a poor user experience. In the highly competitive digital market, a poor user experience can stymie a business’s market readiness.

    However, businesses should realize that the DevOps software testing approach is a journey and should be leveraged to enhance the user experience on a continuous basis.

    What’s the Key Value Expected from DevOps?

    Considering that the development and operations teams of an enterprise each have different work cultures, systems, goals, tools and approaches, the quality and delivery schedule of applications can be thrown off. Hence, the significance of DevOps testing strategy comes into play to bring synergy between the teams and to enhance the quality and delivery of applications consistently.

    DevOps calls for the integration of development and operations teams, wherein QA is made everyone’s responsibility. The synergy helps in breaking the departmental silos and posits the role of QA as an enabler of value addition and to achieve customer delight. This not only ensures quality, but also enables faster turnaround on application development process. Ultimately, enterprises are better equipped for the changing market dynamics and challenges with their business applications.

    Key Drivers to Adopt DevOps

    George Spafford, research director at Gartner, said:

    “A DevOps initiative must focus on business requirements and not on ‘doing DevOps for the sake of DevOps,’ wherein the methods and tools become more important than what customers need. Organizations must avoid the all-too-common mistake of launching a DevOps initiative before establishing that a business reason exists to do so. For example, instead of focusing on release rates and doing things faster, start with the business value by asking what that will enable.”

    Hence, it’s important to work with a DevOps strategy that resonates with the business objectives. These are some key drivers for considering DevOps.

    • Quick deployment of quality applications across devices, platforms, operating systems and networks.
    • Increasing competition necessitating the faster release of apps.
    • Emerging technological platforms whetting the appetite of customers for better products.
    • The emergence of complex applications with footprints in the physical and virtual world.

    How Does DevOps Enable Effective Quality Assurance?

    • It makes QA a collective responsibility rather than being assigned to a single department or organization.
    • It enables better collaboration between teams through a shift of culture.
    • It ensures faster identification and elimination of glitches.
    • It is responsible for accelerating the time to market and keeps a tab on the software quality through customer feedback.
    • It provides continuous improvement of software through timely releases.
    • It reduces cost due to the absence of rework.
    • It optimizes the utilization of resources and prevents waste.
    • It helps to cut down the software development life cycle (SDLC) by adopting quick sprints.
    • It ensures continuous development, testing, integration, deployment, monitoring and innovation of applications.

    The Need to Measure DevOps

    Digital transformation has necessitated the need for rapid innovation, development, testing and deployment of applications. Post deployment, appropriate customer feedback should be considered and absorbed into the product to improve its performance further. The success of DevOps QA depends on the level of automation, not to speak of the degree of collaboration among various stakeholders.

    In fact, enterprises should use a robust automation software to execute quality assurance across platforms and devices. The automation software should be able to test the code as part of the development sprint on a variety of devices and test environments. The DevOps QA approach should be measurable based on certain metrics to ensure its effectiveness. The measurement platform can include the following:

    • The QA team dealing with continuous integration should be able to work with all the tools to find out glitches.
    • The entire setup should be simple to facilitate quicker learning, adoption and execution.
    • The test data including dependencies should be easy to access.
    • The entire build, deploy, release, verify and rework processes should be streamlined.

    Conclusion

    In the fast-changing digital landscape, the objective of reaching out to the customers quickly and with better quality of products is paramount. This is where the DevOps specialists turn things around with continuous improvement, innovation and deployment.

    As Gartner’s Spafford rightly stated, “DevOps challenges conventional IT thinking with its lack of a standard definition and approach, its constant evolution, and its requirement for acceptance and management of risk.”

    — Komal Lopez

  • Accenture Aims to Infuse AI into App Testing

    Accenture Aims to Infuse AI into App Testing

    Accenture plans to infuse greater amounts of artificial intelligence into application development testing following its acquisition of Real Time Analytics Platform Inc., which provides tools that make use of machine learning algorithms, neural networks and natural language processing (NLP) to analyze every stage of the software development life cycle.

    Kishore Durg, senior managing director and growth and strategy lead for Accenture Technology, the IT services arm of Accenture, will incorporate the AI technologies developed by Real Rime Analytics Platform into the Accenture Touchless Testing Platform, which is a suite of open source and proprietary testing tools that Accenture has infused with advanced analytics and cognitive computing technologies.

    Durg said Accenture is committed to automating application testing using AI technologies to help organizations increase the productivity of application development teams. At a time when organizations are investing in a broad range of digital transformation projects, the rate at which applications can be built, tested and deployed has become a critical issue.

    Most organizations on their own won’t be able to aggregate enough data to drive machine learning algorithms and neural networks to drive a meaningful AI model. Those models require access to massive amounts of data to be trained to identify potential issues within any application. Because of the size and scope of the projects Accenture works on, organizations that employ its service can benefit from all the data that Accenture can bring to bear to train AI models, Durg noted.

    The quality of the data used to train those AI models is also as important as the amount of data, added Durg. Accenture has the resources required to cleanse data before it gets fed into an AI model, as well the expertise needed to eliminate any biases that might get built into any algorithm being applied to that data, he said.

    As AI continues to evolve, it won’t be long before every application incorporates some form of an AI model. Each of those models not only needs to be trained, but they also need to be updated continually—and eventually replaced by more sophisticated models as more data becomes available. In effect, that requirement will create a need to extend DevOps processes to how AI models are incorporated within an application.

    At the same time, it’s clear that large swaths of DevOps processes involving, for example, application testing can be increasingly automated using a variety of machine learning and network networks, also known as deep learning algorithms.

    In theory, that should accelerate the rate at which applications are developed and deployed, while testing processes that are augmented by AI technologies should result in applications that are more secure, as many more vulnerabilities will be discovered long before an application gets deployed in a production environment.

    In fact, the inclusion of advanced algorithms across a DevOps toolchain might accelerate adoption of DevOps processes. After all, most IT organizations today have embraced DevOps unevenly largely because of the complexity involved. AI technologies one day soon may eliminate that issue altogether.

    — Mike Vizard

  • The Software Testing Metrics That Make Or Break DevOps Success

    The Software Testing Metrics That Make Or Break DevOps Success

    Organizations today are racing to develop software at a breakneck pace through efficient DevOps processes. But it’s important for them to avoid losing sight of the forest for the trees. If too much of that speed comes with quality sacrifices that degrade the user experience, the rapid software iterations hurt the business more than they help it.

    “Organizations adopt DevOps to accelerate the delivery of innovative software that creates positive user experiences,” said Clark Golestani, former CIO at pharmaceuticals giant Merck and current managing director of C Sensei Group. “If you start accelerating delivery without also rethinking your approach to quality, you will end up rapidly delivering updates that drive your customers to competitors.”

    This is why continuous and automated testing is so essential to DevOps success. But instituting effective and streamlined testing is easier said than done. Organizations must continually tweak what, how and when they test their software to achieve the optimal test coverage while introducing as little friction as possible into the software delivery pipeline. It’s a delicate balance, and the only way to achieve it is to keep meticulous track of metrics that evaluate how well the testing process is improving quality throughout the development life cycle.

    “As the saying goes, ‘You can’t manage what you don’t measure,’” said Andrew Magarie, senior market impact consultant at Forrester Consulting. “So firms need to be able to define and track the right metrics that can help enable quality at speed while minimizing risk.”

    Magarie and his team at Forrester recently conducted research into 94 different quality metrics frequently measured by DevOps organizations across four development stages: build, functional validation, integration and end-to-end regression testing. The study showed that the most effective test metrics that bubbled up across all of stages tended to clump into at least one of three categories.

    Risk-Focused Metrics

    According to Magarie’s report, the most mature and effective organizations fundamentally chose testing metrics that best helped them understand business risk posed by the software throughout the development process.

    “For this study, we use the following definition of business risk: Any application shortcoming that impairs the end user’s (or customer’s) expected experience and ultimately erodes confidence in the business,” he explained.

    For example, during the build stage mature organizations consider measuring the number of automated tests prioritized by risk as one of the most important assessments.

    “Tracking ‘unit’ tests prioritized by risk is the key. As the code base evolves, developers and testers need immediate feedback about change impact. This feedback is significantly more actionable if prioritized by level of risk,” wrote Magarie.

    As he explained, business risk will be different for every application, and the complexity of an organization’s architecture and transaction dependencies adds more variables to the equation. However, organizations need to seek ways to measure ‘relative risk’ across the software development life cycle (SDLC) if they truly want to take a disciplined approach to incrementally improving quality in their software.

    Contextual Metrics

    Forrester found that simple “counting” metrics don’t offer QA nearly as much value as contextual metrics. So simply tracking the number of tests will not provide teams with as much actionable data as the measurement of the ratio of requirements covered by tests. Approximately 69 percent of mature organizations say running functional tests and checking against covered requirements is a top measurement and 75 percent say the same about API tests run against functional requirements.

    Holistic UX Metrics

    The most mature organizations recognize that while application-specific or team-specific QA metrics are important, the ultimate goal is ensure the quality of the user experience (UX) across their entire interaction with an application. This means measuring the thoroughness of end-to-end regression testing is crucial. Approximately 70 percent of leading DevOps organizations say they believe the percent of automated end-to-end test cases as a top metric.

    — Ericka Chickowski

  • HPE Brings Storage Deeper into DevOps Realm

    HPE Brings Storage Deeper into DevOps Realm

    Hewlett-Packard Enterprise (HPE) today moved to bring storage further into the realm of DevOps by integrating its 3PAR storage systems with VMware vRealize Orchestration software, open source Kubernetes container orchestration software and the Red Hat OpenShift platform-as-a-service (PaaS) environment built on top of Kubernetes. HPE 3PAR storage systems already support Docker containers and the DC/OS private cloud platform from Mesosphere.

    In addition, HPE is making available pre-built blueprints for Chef, Puppet and Ansible automation frameworks, as well as software development kits written in Ruby and Python that can be used to create custom integrations.

    Finally, HPE announced that HPE InfoSight, a cloud-based service that employs machine learning algorithms to predict when a drive might be about to fail or when application performance might be adversely impacted by I/O contention. HPE gained the core technology for that service when it acquired Nimble Storage last year.

    Vish Mulchand, senior director of product management and marketing for HPE Storage, said machine learning algorithms and other forms of artificial intelligence (AI) will soon be playing a much larger DevOps role. Research indicates that more than half of all support issues involve storage systems, and AI technologies will be able to identify most of those issues long before they impact applications, he says.

    Mulchand notes HPE has been adding integrations with various DevOps and container technologies to make it easier to scale applications as needed. The goal, he says, is to make storage management a more natural extension of any set of DevOps processes.

    In general, providers of storage systems have been investing heavily in automation frameworks designed to make it easier for storage administrators to manage ever increasing amounts of data. The next challenge facing IT organizations is to be able to provision storage resources in a way that doesn’t hamper the rate at which those applications might be deployed.

    It’s not clear to what degree storage administrators will be subsumed into DevOps teams. In most cases, storage administrators are looking to make available a pre-determined set of storage resources available to developers on a self-service basis. The amount of those resources is determined by the characteristics of the application, which storage administrators can gain earlier access into by participating in the DevOps process.

    Going forward, Mulchand says HPE expects competition between storage vendors increasingly will be defined by the quality of experience they provide IT organizations rather than the performance of the storage systems. Every storage vendor has embraced Flash storage systems that can address the performance requirements of just about any type of application workload, he says, so making it easier to access those storage resources and make sure they are constantly available is the next major opportunity.

    As more automation gets introduced into IT environments, there’s no doubt the role of the average storage administrator will change. Rather than manually provisioning resources, storage administrators will be able to develop policies for classes of applications that are automatically implemented whenever storage systems need to be provisioned. As storage administrators learn the characteristics of those application in a production environment, those policies will be further fine-tuned. The good news is that storage itself no longer needs to be seen as a bottleneck from either a performance or DevOps perspective.

    — Mike Vizard

  • Successfully Integrating DevOps while Deploying Cloud Applications

    Successfully Integrating DevOps while Deploying Cloud Applications

    Transforming to a high-performance DevOps environment can provide competitive advantages, but it requires change—and that doesn’t come easily to most organizations. DevOps requires cultural changes that are inherent to automating previously manual tasks: They are perhaps intimidating to those involved and they require flexibility and enterprisewide buy-in to get right. Furthering these people-side transformational complications are cloud application deployments, creating a need for enterprises to deliver innovative technologies and services with greater speed and quality—without hits to reliability and security.

    DevOps Blended with AWS Proficiency

    One approach to this problem is blending DevOps knowledge and Amazon Web Services (AWS) proficiency to guide development teams to better align the people, processes and technology needed to facilitate successful cloud initiatives.

    In transitioning to a more modern, DevOps-driven approach, companies often encounter a number of challenges, on both a technological and cultural level. The most successfully integrated DevOps occurs as a function of value analysis and process overview, addressing the individual needs of an enterprise rather than fitting them into a preset mold.

    Implemented correctly, DevOps blended with AWS proficiency allows organizations to maintain quality and configuration of their infrastructure environments, allowing application development teams to retain control over their processes and toolsets. AWS also allows the enterprise to maintain security: Rather than protocols that are standalone, they’re built into IT processes from the beginning, allowing customization with ease.

    AWS understands what is important to its partners when building tools, successfully addressing needs while staying ahead of the demand and, in turn, saving time. They accelerate the ability to deliver and allow an enterprise to focus on what’s most important during their journey to the cloud: value analysis.

    Fundamentally Designed to Refine Business Processes

    It is very important to approach projects first from a top-level view: Where does this piece of work fit into my broader organization?

    DevOps at its core is fundamentally about incorporating different disciplines of a business to create better practices than what are already in place. When an enterprise chooses to implement automation, it typically gains a better view of its business as a whole, incrementally increasing awareness at a birds-eye level. When complex business functions and operations are laid out in more mathematical terms and formulas, it suddenly becomes clear where applying automation can reduce waste.

    Getting these changes implemented quickly and with as little effort as possible naturally leads to successful automation. Enterprises remove such tasks that traditionally required an excess in resources by asking, “What value doe this process add? Is there a more efficient alternative?” With automation, these useless business practices are eliminated, freeing resources for more important initiatives.

    Increase Employee Awareness, Increase Productivity   

    One of the most important parts of the entire DevOps integration process is ensuring that everyone understands each other and their role. Properly embraced, a DevOps culture will be characterized by increased collaboration, shared responsibility and autonomous teams—leading to improved quality, valued feedback and the end goal of increased automation.

    People are naturally resistant to change. Members need to be aware of the business and how they—and will continue to—fit in.

    Ultimately, DevOps is not something that can simply be bought. Success during implementation requires the application of technologies, tools and products that are actually a fit between new processes and existing systems.

    — Ashley Stovall