Category: Features

  • RapidAPI Adds Library to Invoke Kafka via API

    RapidAPI Adds Library to Invoke Kafka via API

    RapidAPI announced it has added support for the open source Kafka messaging software as another type of application programming interface (API) that DevOps teams can centrally access.

    An open source library provided by RapidAPI, available in beta, makes it possible to discover Kafka clusters and topics, view schemas and test and consume records from a browser via either the RapidAPI Marketplace or the RapidAPI Enterprise Hub. The library is based on Apache Avro and Confluent wire formats found in the open source confluent-schema-registry library. RapidAPI extended that library to add support for JSON and a protocol buffer, which is now being shared with the open source Kafka community.

    RapidAPI CEO Iddo Gino said DevOps teams can now discover all available Kafka clusters and instances in the same location where they find, test and connect to microservices based on REST, SOAP and GraphQL APIs. That effort is designed to complement initiatives, such as the AsyncAPI specification, that is now being advanced under the auspices of the Linux Foundation, Gino noted.

    RapidAPI is adding this capability because usage of Kafka to enable asynchronous communication across event-driven applications has significantly increased, Gino said. As the number of digital business transformation initiatives increased in the wake of the COVID-19 pandemic, Gino said reliance on asynchronous messaging platforms such as Kafka became a requirement. In many cases, synchronous communications across highly distributed applications simply isn’t feasible, Gino added.

    That doesn’t mean asynchronous requirements will replace the need for traditional synchronous APIs. Rather, developers will find themselves incorporating a greater mix of both as enterprise IT environments become more distributed, noted Gino. Applications are increasingly become one large puzzle that developers need to construct using various classes of APIs, added Gino.

    The library created by RapidAPI is expected to be generally available in the third quarter. In the meantime, adoption of Kafka continues to accelerate. The open source community that oversees development of Kafka, under the auspices of the Apache Software Foundation, claims more than 80% of all Fortune 100 companies are using the platform for everything from constructing data pipelines to running streaming analytics applications. In some cases, data is being queried directly while in transit versus waiting for it to be stored on-premises or in the cloud.

    Regardless of how Kafka is employed, developers are rediscovering event-driven architectures, that can trace their lineage to the 1980s, for building applications. The difference now is there an open source framework for handling the asynchronous communications required to build and deploy those applications at scale.

    It’s not quite clear how the rise of event-driven applications will impact DevOps workflows, as event-driven applications become more commonly built and deployed. However, as the APIs become more widely employed within the context of these applications, it should become simpler to incorporate them.

    The challenge is event-driven architectures typically requires developers to think differently about how their applications are structured, so it might be a while before Kafka – and other similar platforms – are pervasively employed across the enterprise.

  • Okta Adds Free Developer Edition to AppSec Service

    Okta Adds Free Developer Edition to AppSec Service

    Okta this week lowered the barrier to adoption of DevSecOps best practices by making available an Okta Starter Developer Edition to enable developers to embed Okta authentication, authorization and user management capabilities into applications at no cost for up to 15,000 monthly active users.

    Randall Degges, head of developer advocacy for Okta, said interest in identity management among developers is rising as a method for implementing zero-trust initiatives that better secure application environments. Rather than having to embed and maintain authentication and authorization themselves Okta is making a case for developers to invoke an application programming interface (API) to access a service that provides those capabilities on demand, noted Degges.

    The Okta Starter Developer Edition, announced at an online Oktane21 event, reduces the friction developers encounter as they look to embed identity management capabilities, such as multifactor authentication, into their applications, Degges said. Developers can, for example, access enhanced documentation and sample applications as well as new integrations with Kong, Heroku and Terraform platforms and tools, alongside integrations with multiple continuous integration and continuous delivery (CI/CD) platforms.

    In general, Degges said, the shifting of responsibility left toward developers is happening at a much faster rate because the level of appreciation for security among developers is now a lot higher. Identity management capabilities are simply another API that developers can now invoke as part of a DevOps workflow, noted Degges.

    The Okta Starter Developer Edition comes on the heels of the announcement of the acquisition of Auth0, a provider of authentication and authorization services that can be easily embedded within an application. That $6.5 billion deal, however, is not expected to close until summer.

    In the meantime, Okta is moving forward with the Okta Starter Developer Edition that could eventually create a large pool of applications that will one day consume Okta services for a fee as they scale. The more applications an organization deploys, the more likely it becomes that they will have more than 15,000 active users per month.

    In the meantime, the level of experimentation involving digital business transformation initiatives is likely to increase. Developers will be able to demonstrate to their often skeptical cybersecurity counterparts that their concerns have been addressed before an application is deployed in a production environment.

    It’s not clear what impact access to initially free identity management services might have on the adoption of DevSecOps best practices. In many cases, developers will take advantage of a service like Okta simply to address a requirement. Their appreciation for how that service fits within the context of a larger DevSecOps workflow might not be all that high.

    Nevertheless, the state of application security should improve in the months and years ahead. In fact, some developers may opt to update existing applications that, at present, do not meet zero-trust requirements to take advantage of identity management services that can be invoked via an API. Alternatively, the may also decide to replace authentication capabilities that are challenging for them to maintain and update with an API that calls a service. Regardless of the path forward, the historic divide between developers and cybersecurity teams appears to be finally narrowing.

  • Gitpod Revamps Dev Automation Tool

    Gitpod Revamps Dev Automation Tool

    Gitpod announced today it refreshed the dashboard for its namesake open source tool for automating the deployment of development environments, in addition to making Microsoft VS Code its default tool for editing code.

    In addition, Gitpod has included support for sudo privileges and Docker images using an advanced user namespace to map and limit access to workloads using a built-in Supervisor capability.

    Fresh off raising an additional $13 million in funding, Gitpod CEO Sven Efftinge said now that it’s clear developers will be working from anywhere for the foreseeable future, the need for a tool to automate setting up a developer environment on a local machine outside of an office has become more apparent.

    Gitpod claims there are now more than 350,000 developers using its tool that creates a Kubernetes pod on each developer machine to deploy a complete application development environment, including the integrated development environment (IDE), plugins, compilers, build tools, code generators, databases and application servers. Gitpod makes use of the version control systems provided within, for example, a continuous integration/continuous delivery (CI/CD) platform as the single source of truth for configuring an application development environment.

    The overall goal is to eliminate the time developers waste setting up application development environments so they can write code on their own machines. That approach also makes it simpler for developers to collaborate around the same application development environment regardless of where they happen to be physically located.

    Efftinge said Gitpod provides DevOps teams with a tool to automate setting up development environments across any Git repository that is the equivalent of the Codespaces tool that GitHub recently made available. Rather than having that capability for only one repository, Efftinge noted that most developers work on projects that span multiple types of repositories.

    Automating that process also makes it simpler to align development environments with production environments. One of the reasons why code doesn’t work in a production environment when it is first deployed is because the local development environment has been manually configured in a way that doesn’t accurately reflect the production environment. That issue can become even more problematic when developers are working on multiple projects involving, for example, separate microservices constructed using different repositories.

    In the wake of the COVID-19 pandemic and the acceleration of multiple digital business transformation initiatives there’s naturally a lot more focus on automation and developer productivity. Most developers will be working outside the office for the foreseeable future. Of course, most developers have been writing code outside the office for years. The challenge now is enabling teams of developers to develop applications as efficiently as possible, no matter where they are in the world. In fact, now that development teams have become more distributed, organizations are becoming more comfortable hiring developers wherever they find them.

    Eliminating inefficient manual tasks, such as maintaining development environments, is, of course, going to be a prerequisite for making it possible for those developers to, over time, navigate multiple application development projects without ever having met their colleagues in person.

  • Survey Sees Application Testing Shifting Further Left

    Survey Sees Application Testing Shifting Further Left

    PractiTest, a test management platform provider, published a report today that suggests professional application testers have become more adept at working within DevOps workflows.

    The annual survey of more than 1,000 application testing professionals finds that 80% of all application testing within organizations is being done by test engineers, test leads, testers and automation testers. A full 92% of survey respondents also noted they are working within the context of an agile methodology, while 42% cited DevOps specifically. Half of respondents said they work within the framework of a continuous integration/continuous delivery (CI/CD) platform.

    Significantly, more than half of respondents (59%) said testing is shifting left within their organization, but only a third (33%) said programmers participate in the testing process.

    PractiTest CEO Yaniv Iny said that level of DevOps inclusion suggests that, rather than shifting testing completely left on to the shoulders of application developers, a more nuanced approach to application testing is taking hold as professional testers learn to work within the sprints that make up a DevOps workflow. A full 90% of respondents said testing has become more automated within their quality assurance (QA) processes.

    By now, most application testers have come to terms with automation and, increasingly, AI, said Iny. The assumption now is that large swaths of the testing process will be automated, Iny added. A full 97% of respondents said that functional testing automation was either important or very important for them to succeed, while 96% said test automation patterns, principles and practices are also critical.

    Usage of behavior-driven development (BDD) as a testing model has also increased, with 27% of organizations now employing it to go beyond simply testing functions.

    However, the survey also found that, instead of automation decreasing the size of testing teams, those teams are getting larger. The number of organizations with 16 or more testers increased by 10% to 34% compared to a year ago. That suggests organizations are launching either more complex application development projects or launching multiple projects at the same time as they embrace digital business transformation initiatives, Iny said.

    The survey found nearly 70% of respondents have at least five years of experience. Nearly three-quarters (71%) of respondents reported that their income was not affected by the economic downturn brought on by the COVID-19 pandemic. However, nearly half of respondents (54%) reported that they were concerned about job stability, an increase of more than 30% from a year ago.

    The pandemic did change the way testers acquire new skills. The number of testers reporting that they attended online conferences, meetups and seminars increased to just under half (49.5%), up from 40.5% in 2019. Participation in online communities and forums grew to 44%, while only a third of respondents receiving any kind of formal training.

    Testing professionals with five to 10 years of experience earned an average salary of $89,000 in North America, which compares to $76,000 in Australia/New Zealand, the survey also found.

    Application testing as a distinct discipline doesn’t appear to be fading away anytime soon. Rather, organizations appear to be investing even more in testing to deliver higher-quality applications.

  • Tasktop Adds Dashboard to Surface VSM Insights

    Tasktop Adds Dashboard to Surface VSM Insights

    Tasktop today unveiled a dashboard that it promises will simplify tracking of key performance indicators (KPIs) spanning multiple projects.

    In addition, the value stream management (VSM) platform provider revealed it has garnered an additional $100 million in funding.

    Tasktop CEO Mik Kersten said the Tasktop Viz VSM Portfolio Insights dashboard makes it simpler to surface the insights that the company’s VSM platform aggregates as it collects metrics and analytic data from the tools and platforms that make up a DevOps workflow.

    Organizations are then better able to determine the impact any change to the rate at which an application is being developed will have on the business, noted Kersten. IT and business leaders can also more easily identify how constrained resources or persistent quality control issues might be adversely impacting those business goals, added Kersten.

    As a DevOps discipline, VSM is still relatively new. However, Tasktop claims more than half of the Fortune 100 employ its VSM platform. Customers include BMW, CGI, E*Trade and T-Mobile. Despite the economic downturn brought on by the COVID-19 pandemic, the company reports it saw a 30% increase in revenues driven mainly by organizations that have accelerated multiple digital business transformation initiatives. A recent Forrester Consulting Total Economic Impact Study indicated organizations realize a potential 640% return on investment over a three period after implementing the Tasktop VSM platform.

    Tasktop is also a founding member of the Value Stream Management Consortium, which is seeking to promote adoption of VSM platforms to close the divide that often exists between individual DevOps projects and the strategic business goals of an organization.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is automated as much as possible using DevOps best practices, the need to monitor the impact of, for example, missed software development deadlines on the business has become more acute as organizations appreciate just how dependent they are on software.

    VSM platforms automatically take technical metrics, gathered via a DevOps process, and match them to a set of key performance indicators (KPIs) defined by business leaders. The challenge many organizations still face is, first, making sure they have the tools in place to collect the appropriate technical metrics and then identifying the KPIs that truly matter to the business. Once those metrics are gathered and KPIs established, organizations are able to apply advanced analytics to optimize allocation of resources that include people, platforms and processes, noted Kersten.

    It may be a while before VSM becomes pervasively applied with organizations. However, those organizations that find a way to consistently deliver quality applications, on time, that have a greater impact on the business will inevitably start to outperform rivals. The challenge and the opportunity is to bring a level of discipline to bear that ensures that goal is always achieved.

  • 4 Ways to Overcome Agile Transformation Obstacles

    4 Ways to Overcome Agile Transformation Obstacles

    If an organization desires a successful Agile transformation, the first step is to shift its thinking from ‘doing Agile’ to ‘being agile.’ Unfortunately, a commonly shared belief that Agile is just a software development methodology keeps too many companies stuck in the ‘doing Agile’ mindset.

    This belief ties back to the principles of Agile thinking from frameworks like Scrum or Lean. Most of these methodologies were focused on teams of developers. Naturally, the vocabulary and tools derived from these methods are unique to software development. While development has evolved away from waterfall approaches, the rest of the organization tends to run into cultural challenges downstream because the vocabulary and ways of working are foreign.

    When an organization begins to lose progress downstream, it is too focused ‘doing Agile’ rather than ‘being agile.’ In order to shift the mindset toward ‘being agile,’ a new mindset must be adopted across the organization. These four insights offer ways to overcome obstacles along the way:

    Instill Agile Thinking Across the Organization

    The first step toward instilling agile thinking is to establish common vocabulary and define what it means to be agile. A common vocabulary and understanding of agility helps teams across the organization understand and see that agility is more than doing sprints.

    As an organizational strategy, agility equates to flexibility – the ability to adapt to changing business requirements. It also means being collaborative and making complex processes more lightweight. Instilling this type of agile thinking into everyone at the organization leads to success. DevOps, for example, successfully instills this type of thinking through value stream management.

    Essentially, this hurdle boils down to setting common goals and creating a common understanding of what ‘agile’ means across the organization.

    Achieve Autonomy Through Self-Organization

    Agile frameworks encourage self-organization. When teams self-organize they are given a task to do. However, no one tells them how they’re going to accomplish it. A self-organizing team gains a certain amount of autonomy, which leads to empowerment.

    With self-organization also comes risk. The organization must learn how to embrace risk, how to look at failure as an opportunity to improve and how to empower teams in a more self-regulating way. When teams self-regulate and self-organize, it’s a team win when they are successful. This develops a sense of communal pride.

    When breaches or too many failures do happen in a self-regulating system, the policies and consequences naturally occur. However, the key differentiator is that these environments are not driven by the policies. Rather, the objectives drive the behavior. When objectives are being met, empowerment stands.

    Agile software development, DevOps and site reliability engineering (SRE) are intended to be self-regulating systems, but all first require leadership to create psychologically safe environments, blameless postmortems and more. There is no room for a blame culture in a self-regulating system, and the organization must be agile enough to meet the demands of the system.

    Leverage Intelligent Lightweight Process

    Agility does not equate to a complete absence of process. It means there is enough process in place to ensure consistency, improve flow between people and teams and that automation replicates the process simply and effectively.

    IT organizations must understand that it is possible to move away from complex and authority-based processes and continue to leverage an element of process.

    Intelligent Process Means Intelligent Automation

    Although humans are the driving force behind agility, automation helps them go faster with more consistency. However, there is no such thing as ‘being agile’ with automation alone. Agile cannot be bought, and it’s important to get teams thinking that way. Automation should complement Agile, but not define it.

    When investing in automation, a cost/benefit analysis is critical. When considering automation, think in terms of two key metrics: time and quality. With two equally important metrics, the organization cannot become dependent on one aspect or another.

    For example, you can’t go faster with a manual process. You also can’t go faster with only automation, because the automation alone doesn’t replicate your intelligent lightweight process. And, you can’t go faster just by having a process, because the process can become very bureaucratic.

    Process is just a means of getting there, but it needs people and automation to make the processes come alive. People, process and automation all play an essential role in creating an intelligent process.

    Successful Agile transformation is more a way of thinking and behaving than simply following a framework. From a human perspective, an organization that experiences true agility, as we’ve defined it today, allows humans to exercise their competencies, grow skills, collaboratively celebrate success and learn from failures.

    If you’d like to learn more about Agile Transformation, especially in regards to Agile Testing, you can register for the next SKILup Day on April 22. Please register for SKILup Day: Agile Test Management for the Enterprise here.

  • How lulu Became a Lemon: A Digital Transformation Fail

    How lulu Became a Lemon: A Digital Transformation Fail

    Many people sometimes have a tough time figuring out what exactly digital transformation is and why it’s so important. I want to tell you a real-life story of how a once-respected brand, lululemon, has failed the digital transformation journey and, as a result, may fail in a new retail landscape.

    The story starts innocently enough with my desire to get my wife a lululemon gift card for her birthday. She has gotten her vaccines and is returning to the gym, so I figured it was a great time to get new workout clothes. I purchased a gift card on March 15 to be delivered via email a few weeks later on her birthday. It was a simple digital transaction that for any company that has its digital transformation act together would be a no-brainer. Well, this is where lulu turns off the tracks and turns into a digital lemon.

    On the day of my wife’s birthday, I had planned that she would wake up and see how thoughtful I was in getting her the gift card. She didn’t say anything about the card, though, so I finally asked if she received the gift card. She didn’t know what I was talking about. I had her check her spam folder, nothing. Nope, no gift card.

    Thus began a day that would see me reach out and communicate with the lulu team no fewer than six times. It seems that lulu uses a third party for digital gift cards. Each time I reached out to a lululemon “educator” (that is what they call them, and did I get an education), I was told a different story:

    1.  A simple apology and card being emailed, give it an hour.
    2. Sorry, it must be that email address, do you have another email address? Give it an hour.
    3. Hmm, seems our third-party gift card provider is having problems today.
    4. We located your card, it was sent to: tlaynguyen@gmail.com  could I check that email? (I would love to, but that isn’t an email address I have.)
    5. Well, we have no control over when the third party sends emails.
    6. Digital gift cards are non-refundable, even if you didn’t receive it. Sorry, can’t help you.
    7. You have blocked our emails from your computer.

    At this point I realized that lululemon, while maybe making great workout gear, is analog to the core. A simple digital transaction like this had them tied in knots, wasted hours of my time and so turned off my wife that she is looking elsewhere for her new workout gear.

    This past year has taught us that retailers that can’t hop on the digital transformation train are heading for the precipice. It seems as though lululemon may have already gone over the deep end. The company better hope the malls fill up quickly because in a digital world, lulu is truly a lemon.

  • DevOps Skills Increasing Among Salesforce Developers

    DevOps Skills Increasing Among Salesforce Developers

    A survey of 521 attendees at a recent online Future of Salesforce DevOps Summit event hosted by Gearset, a provider of a continuous integration/continuous delivery (CI/CD) platform for Salesforce developers, found just under half (47%) of respondents now release software at least multiple times a week, with another 29% releasing software weekly or biweekly.

    More than half of respondents (52%) also noted they now can deploy software in less than an hour.

    Gearset CEO Kevin Boyle said the survey suggested the level of DevOps maturity among developers building applications on top of the Salesforce software-as-a-service (SaaS) platform is increasing rapidly. In the wake of the COVID-19 pandemic, many organizations embraced SaaS platforms to accelerate their digital business transformation initiatives rather than building entire applications from scratch.

    However, the biggest benefit cited by survey respondents was not the ability to release applications faster, but rather the improvements to application quality (77%), followed by increased productivity (69%) and enhanced collaboration (46%). Other benefits cited included reduced complexity thanks to automation; increased agility; more reliable releases and time and cost savings.

    Overall, the survey identifies source code control, CI/CD, unit testing, change monitoring and backups of metadata and data as being the most widely implemented DevOps capabilities that have been adopted. Over the next 12 months, capabilities that will see the most increased adoption among survey respondents include CI/CD, static code analysis and sandbox seeding with data.

    Survey respondents said their top obstacles to adoption of DevOps are ramp-up time, followed by difficulties adopting source control and a perceived steep learning curve. For many organizations that have adopted Salesforce, the intimidation factor when it comes to adopting DevOps best practices is still fairly high, Boyle noted.

    Most recently, Gearset added a free training platform, dubbed DevOps Launchpad, that employs gamification techniques to make DevOps more accessible to developers. Topics covered include version control fundamentals, Git branching strategies and Salesforce backups.

    Gearset counts McKesson, Zillow, Traction on Demand, Intercom, Accenture, IBM and Johnson & Johnson among its customers. It’s not clear to what degree appreciation for DevOps has risen among smaller companies. However, as the number of custom applications deployed as extensions to the Salesforce platform increases, it is apparent that manual processes for building and deploying applications will not scale. The Salesforce platform itself is uniquely constructed using a set of objects and tables that generally lead organizations to adopt a DevOps platform built for that environment. However, it is possible to build and deploy applications using a DevOps platform designed for building and deploying applications that might need to span multiple platforms. Those applications would be integrated with the Salesforce platform at an application programming interface (API) level.

    Regardless of how custom applications are built and deployed, it’s clear Salesforce platforms are becoming more widely used in enterprise IT environments. Each DevOps team will need to determine how best to integrate those platforms within the context of their overall DevOps strategy.

  • Apollo GraphQL Makes Federated Server More Accessible

    Apollo GraphQL Makes Federated Server More Accessible

    In advance of its online GraphQL Summit this week, Apollo GraphQL announced today it has updated its Apollo Federation offering that enables a GraphQL Server to span multiple platforms, making it more accessible to a wider range of developers using different tools.

    Apollo Federation is now integrated with both Apollo Studio, a web-based tool for navigating GraphQL application programming interfaces (APIs), and Apollo Workbench, a plugin for Microsoft Visual Studio.

    At the same time, Apollo GraphQL is making available a command line interface (CLI), dubbed Rover, that makes it simpler to integrate Apollo Federation within a DevOps workflow.

    Matt DeBergalis, CTO, Apollo GraphQL, said GraphQL is continuing to gain traction as an alternative to more rigid REST APIs as more organizations begin to appreciate how dependent they have become on software. REST APIs may be simpler for developers to create, but APIs based on GraphQL are easier to update and manage, DeBergalis noted.

    Apollo GraphQL

    The challenge organizations encounter is that a GraphQL Server can become too large to easily navigate. Apollo Federation provides a mechanism that enables of subset of those APIs to be managed on multiple platforms that make up a federated instance of a GraphQL server, DeBergalis explained.

    DeBergalis also noted that IT vendors that have embraced GraphQL are also starting to add support for Apollo Federation. DataStax, a provider of a curated instance of the open source Cassandra database, has added Apollo Federation to the open source data gateway Stargate it provides to access data stored in a Cassandra database.

    At its core, QraphQL provides an open source data query and manipulation language for APIs along with a runtime for fulfilling queries. Originally developed by Facebook, the GraphQL Foundation is now an arm of the Linux Foundation. As more organizations embrace APIs to construct applications based on microservices, GraphQL adoption has steadily increased. It’s not likely GraphQL will completely replace REST APIs any time soon, however, given how pervasively deployed REST APIs already are.

    However, DeBergalis said that organizations that require a more agile approach to building and deploying software are voting with their feet for GraphQL APIs that are easier to update. As the rate of change in software environments continues to increase, the need for a more flexible approach to deploying and updating APIs becomes that much more apparent, added DeBergalis.

    GraphQL is also more efficient than REST APIs in terms how much data is shipped back and forth between a client and a server. At a time when the amount of data that is being consumed is steadily increasing, the need to give clients more control over how data is returned from a server has become more pressing. Apollo GraphQL claims more than two billion queries per day are now being launched against instances of its GraphQL Server.

    Regardless of what types of APIs are employed there are more of them with each passing day. As the number of digital business transformation initiatives increased in the wake of the COVID-19 pandemic, so too did the number of internal and external facing APIs. Developers may have their own individual preference for the type of API they want to use, but as developers are increasingly being tasked with both building and managing APIs after they are deployed, the appeal of GraphQL becomes harder to ignore.

  • Report: The State of DevOps Automation

    Report: The State of DevOps Automation

    In the race to accelerate digital transformation initiatives, organizations are encountering more incidents, more downtime, and longer resolution times. In fact, 90.4% of organizations saw an increase in incidents since the pandemic began, according to a recent Transposit report.

    In a completely digital economy, service downtime takes a higher toll. For ITOps teams, working remotely also requires new strategies to organize a team’s response to issues. Amid rising incidents, 94.1% of organizations have increased their focus on service reliability engineering (SRE) practices.

    Transposit just released their 2021 State of DevOps Automation report, which surveyed over 500 IT, DevOps, and SRE professionals across the U.S. The report sheds light on the state of remote work as it relates to incident response processes, reveals increased demand for SREs and highlights the automation they’re using to narrow the resolution time gap. Below, we’ll explore the report’s key takeaways and discover what sort of DevOps automation is trending.

    Remote Work Slows Incident Response

    Try as they might, videoconferencing and group chat solutions like Zoom and Slack just can’t compete with in-person collaboration. According to the survey, 93.6% of ITOps and software teams reported it takes longer to resolve incidents while working remotely.

    Since the pandemic began, 97% of teams have adopted remote work, and 90.4% have experienced increased service incidents. It doesn’t bode well that incidents are increasing as incident response time lags.

    The report findings frame remote work as a top hurdle to resolving issues — 46.1% reported that not being physically in the same room to collaborate on fixing issues was a top concern. But remote work is only one element; others cite changing processes and a lack of visibility into who’s responsible for maintaining code as another challenge.

    Incident Response Hangups

    To make up for these concerns, organizations are investing in incident response strategies. The report found that 56.4% of companies are adopting communication and collaboration tools, with automation tools at 52.3% and integration tools at 43.9%.

    Though the report showed greater investment in those tools, it also identified a persistent communication gap. When conducting postmortems, it can be challenging to correlate human action to incident responses. More than half (57.4%) of respondents felt it’s hard to piece together human actions and team communication during incidents. This context is essential to make sense of mean-time-to-response (MTTR) metrics.

    Interestingly, the report found 96.4% of respondents believe mining insights from human data, like Slack channels or group emails, could help improve incident responses. It appears that having a clearer way to harvest and query incident-related data throughout the entire response process is a universal concern.

    SRE Goes Mainstream

    As I previously reported, the SRE role continues to evolve and gain favor. The report similarly hypothesizes that, based on the survey results, the SRE title is going mainstream. Out of 295 respondents surveyed, 98% said they increased SRE practices in the last 12 months, and 62.4% said they would be expanding SRE efforts in 2021.

    In 2021, SREs will likely remain a hot commodity in hiring. However, these individuals will face mounting complexity in addressing real-time incidents for complex distributed systems. They will also likely be tasked with automating manual processes, as 51.7% of respondents reported that a lack of automation is the top cause of slow incident resolution.

    Automation Goals and Barriers

    40% of companies surveyed now have at least one dedicated full-time staff member working to create in-house tools or bots to automate incident responses. So, what sort of automation is common in the SRE field? The report shows SREs constructing custom scripts to automate things like:

    • Customer communication
    • Recording MTTR metrics
    • Automating infrastructure
    • Corporate communication
    • Auto-generating runbooks
    • Creating or updating tickets

    But, automating these processes is not all that easy. As a top barrier to automation, DevOps professionals collectively cite a lack of documentation. It seems by replacing tribal knowledge with up-to-date, shared documentation, teams could quickly unlock some gains. So, make documentation accessible, and provide copy-and-paste abilities for sample scripts.

    SRE and Automation to the Rescue

    The study demonstrates how the remote economy has increased both the number of incidents and the mean response times to address them. To fill this gap, organizations increasingly turn to site reliability engineering practices to automate incident responses. By leveling up DevOps with SRE, teams could reduce errors and improve overall availability as development teams progressively deliver new features.