devopsy.kinsta.cloud

Author: Mike Vizard

  • CodeLogic Toolkit Increases Visibility Into App Dependencies

    CodeLogic Toolkit Increases Visibility Into App Dependencies

    CodeLogic launched today a toolkit that enables developers to scan binaries, runtime application behavior and database connections and then leverage graph technology to identify connections and dependencies in real-time.

    Brian Pierce, CodeLogic CEO, said the goal is to make it simpler for developers to identify the relationship between application elements to increase overall productivity and simplify the addition of new members to an application development project.

    In general, most developers add code to applications without really having much visibility into how that code might impact other components. The toolkit created by CodeLogic is an extension of the company’s existing continuous software intelligence (CSI) platform that employs server software to store and process data collected via its agent software. The goal is to make it easier for developers to directly consume those insights via a toolkit they can access directly from within, for example, an integrated development environment (IDE), said Pierce.

    As applications become more complex in the age of microservices, it becomes more challenging to understand all the dependencies between application components. Developers require greater visibility into applications to better manage the break/fix process that inevitably occurs when new code is added to any environment. The CodeLogic CSI platform provides an automated impact score for methods, classes and the overall health of an application as code is developed to provide that visibility.

    That information also plays a critical role in enabling IT teams to understand the implications any newly discovered vulnerability might have on the application environment, added Pierce.

    Overall, the level of technical debt that organizations accumulate over time saps developer productivity, he noted. The more difficult it becomes to add code to an application environment the less likely it is that developers will enthusiastically make the effort, said Pierce. Before too long, the number of updates made to an application environment starts to decline, he noted.

    Developer productivity has become a major issue simply because the number of applications that organizations now want to build and deploy is exceeding the financial resources they have available to hire or contract developers. The more time developers spend studying how an application has been constructed the less time there is to write code and drive innovation. In fact, the more frustrating it becomes to add code the more likely it becomes developers will move on to a company with much less friction involved in building and deploying applications, said Pierce.

    There are many senior IT leaders that also need visibility into application environments before approving projects. Many IT teams discover that there are multiple projects or other teams writing duplicate code or replicating existing functions. Regardless of the reason, more developers are voting with their feet when they feel their time and effort is not fully appreciated.

  • Rezilion Launches Vulnerability Prioritization Platform

    Rezilion Launches Vulnerability Prioritization Platform

    Rezilion today announced general availability of a platform that enables DevOps teams to better prioritize remediation efforts by identifying which vulnerabilities both run in memory and actually impact a class or function that can be executed.

    Liran Tancman, Rezilion CEO, said the biggest DevSecOps challenge organizations face today is that the bulk of vulnerabilities that developers are tasked with remediating don’t constitute a significant cybersecurity threat.

    Rezilion has created a searchable proprietary next-generation vulnerability database (NGVDB) that identifies which issues impact specific classes and functions. That capability enables DevOps teams to de-prioritize close to 95% of software vulnerabilities, said Tancman.

    In addition, the Rezilion platform will surface remediation suggestions that lower the amount of disruption and/or cost, he said. A fully-automated remediation capability, for example, will automatically upgrade and test vulnerable software components and packages within a continuous integration (CI) pipeline that were found to be exploitable. In the longer term, Rezilion is also working toward surfacing remediation suggestions that might be addressed using an alternative to patching, said Tancman.

    The Rezlion platform is also integrated with IT service management platforms such as ServiceNow and project management tools such as Jira to make it easier to address vulnerabilities as part of existing workflows, he added.

    Most developers today are simply overwhelmed by the number of vulnerabilities that cybersecurity teams routinely ask them to patch, noted Tancman. The goal should be to enable developers to focus their limited time and effort on remediating the vulnerabilities that truly matter to ensure application security, he said.

    In addition, developers need to have more confidence in the fact that the patch they are being asked to make won’t break their existing applications, added Tancman.

    Vulnerability prioritization is, of course, at the heart of the long-standing divide that exists between DevOps and cybersecurity professionals. Spreadsheets filled with long lists of vulnerabilities are regularly created, but there is usually no context provided in terms of how severe a threat any given vulnerability poses. As a result, developers would allocate a small portion of their time to applying patches that are prioritized based on intuition and level of complexity rather than severity.

    Naturally, developers are going to allocate most of their time to creating new applications and features. For any DevSecOps initiative to succeed, it’s critical to ensure optimal use of the time allocated to remediation. Cybersecurity teams will continue to compile lists of vulnerabilities, but that list can now be triaged in a way that causes the least amount of friction.

    In the wake of a series of high-profile security breaches, there is now more focus than ever on securing software supply chains. The challenge is to find a way to better secure applications both before and after they are deployed in a production environment. There will always be vulnerabilities that are discovered after an application has been deployed. However, just because a vulnerability exists, that doesn’t mean it’s exploitable. The trouble with application security today is that, all too often, remediation efforts turn out to be a waste of time.

  • GitGuardian Tightens Integration With GitHub to Secure Secrets

    GitGuardian Tightens Integration With GitHub to Secure Secrets

    GitGuardian has expanded its ability to secure code repositories by providing deeper integration with GitHub.

    Ziad Ghalleb, product marketing manager for GitGuardian, said the results of security scans are now provided in the context of pull requests alongside suggestions for remediating issues.

    The company also expanded developer onboarding options by adding an application programming interface (API) key provisioning mechanism integrated with its command line interface (CLI) in addition to making it easier to configure that CLI.

    Finally, GitGuardian extended support for role-based access controls (RBAC) to its platform so that team members can be assigned different permissions levels for incidents based on their role.

    GitGuardian makes it possible to scan source code to detect API keys, passwords, certificates, encryption keys and other sensitive data in a code repository in real-time. Developers building an application often make secrets easily accessible as plain text for the sake of convenience. However, when those applications are deployed in a production environment, developers often forget to delete these secrets. Cybercriminals know to scan for these secrets to make compromising an application environment easier.

    A recent GitGuardian report found a typical company with 400 developers would discover 1,050 unique hardcoded secrets when scanning its entire codebase. Each secret had 13 different occurrences, which meant the effort required to remediate those associated vulnerabilities would be considerable, the report noted.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. GitGuardian makes it simpler to achieve that goal within the context of a set of DevSecOps best practices by integrating with GitHub with a single click, said Ghalleb.

    It’s still early days as far as adoption of DevSecOps best practices is concerned, but it’s clear more responsibility for application security is being shifted left toward developers. The challenge is many developers still lack the tools required to make sure applications are secure before they are deployed in production environments.

    Naturally, the earlier an application security issue is resolved the less costly it is to fix. The problem with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers there is an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have secrets management issues could be staggering.

    One way or another, it’s only a matter of time before more of those issues are surfaced. In the meantime, DevOps teams can reduce the number of applications that might have this issue by making it easier to discover secrets within applications before they are deployed in production environments. After all, the only thing worse than a secret being discovered by a cybersecurity team is having one uncovered by cybercriminals that use it to wreak havoc.

  • BMC Adds Support for DORA Metrics to Mainframe Tools Portfolio

    BMC Adds Support for DORA Metrics to Mainframe Tools Portfolio

    BMC this week announced it has added support for DevOps Research and Assessment (DORA) metrics within its portfolio of DevOps tools for mainframe environments.

    John McKenny, senior vice president and general manager for intelligent Z optimization and transformation at BMC, said the latest edition of BMC Compuware zAdviser now includes a DORA KPI Dashboard that aligns with the widely-adopted framework for measuring DevOps efficiency defined by an arm of Google.

    The DORA metrics track deployment frequency, failure rate, lead time for changes and mean-time-to-recovery (MTTR). Tracking those metrics is crucial for IT teams that have mainframes because they need to make sure applications continue to be deployed on the platform versus being usurped by another platform that is perceived to provide a faster alternative for builds and deployment, noted McKenny.

    BMC also added support for automated webhook notifications to its BMC Compuware Abend-AID offering. That includes diagnostic and root cause analysis to resolve defects in test and production faster. In addition, BMC provides a connector to the machine-identity management platform created by Venafi. That integration promises to eliminate certificate-related outages that can derail an application development initiative.

    In general, DORA metrics are being used to identify areas where DevOps teams can improve. It is up to each organization to determine to what degree those metrics will be used to coach teams versus enforce productivity mandates. However, given the overall shortage of available DevOps talent, few organizations are employing metrics to force DevOps teams to improve. In fact, there is no universal set of DevOps goals that every organization is trying to achieve. Rather, most organizations are trying to determine what set of DevOps best practices makes the most sense to implement given their own goals and internal culture. In the case of the mainframe, most organizations start with a few projects before they begin to employ DevOps more widely, noted McKenny.

    The metrics defined by DORA framework are, of course, only a subset of the total metrics that DevOps teams should track. BMC, for example, makes it possible to track tools usage to provide DevOps teams with insights into what tools may no longer be relevant or required, noted McKenny.

    Mainframe environments also have a long history of using waterfall-based approaches to building and deploying applications that many of them will continue to use alongside DevOps practices, depending on the type of application being built and deployed. In other instances, distributed applications built using DevOps practices are being integrated with mainframe applications that now need to be updated using the same workflow. The mainframe is no longer a platform that is managed in complete isolation from distributed computing environments.

    The major challenge is that many organizations using mainframes often overestimate how difficult it is to adopt DevOps  best practices, McKenny said. Regardless of the platform, there is no doubt the overall rate at which all applications are being built and deployed will continue to increase. The mainframe is proving to be no exception to that rule.

  • Planview Outlines VSM Strategy After Acquiring Tasktop

    Planview Outlines VSM Strategy After Acquiring Tasktop

    Planview this week announced it completed its acquisition of Tasktop, a provider of a value stream management (VSM) platform that enables DevOps teams to align their efforts more closely with strategic business goals.

    Louise Allen, chief product officer for Planview, said the goal is to tighten integration between the Tasktop VSM platform and the project management applications that Planview already provides to software development teams and business executives.

    It’s still early days as far as adoption of VSM within DevOps workflows is concerned, but as more organizations realize how dependent they are on software, they need to better align application development projects with their strategic business goals, said Allen. VSM platforms make it possible to analyze data collected from various DevOps tools and enable business and IT leaders to, for example, visualize how a delay to one project might impact revenue goals for an upcoming quarter.

    Given the current weakness in the overall economy, organizations are looking to more precisely understand the impact software development decisions will have on the business, she added. As part of an effort to address that requirement, Planview will also make it easier for its applications to consume data that was originally created in Tasktop, she explained.

    VSM enables more organizations to function like a software company—aligning application updates with revenue goals. As the number of digital business transformation initiatives being launched increases, organizations are finding they need to operate more like a software company that either manufactures something or provides a service.

    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 an automated process using DevOps best practices, there is growing appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business.

    At its core, a VSM platform will automatically convert metrics collected from a DevOps workflow to track a set of key performance indicators (KPIs) defined by the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to align the resources needed to achieve a strategic goal by, for example, devoting more developers to a specific project. The data collected via a VSM platform can also then be shared with business intelligence (BI) applications that business leaders typically use to manage the business.

    It’s not clear just how hard business leaders are looking for deeper insights into how software development initiatives are progressing, but at the very least, DevOps leaders need a simpler way to understand all the dependencies that exist between initiatives. Otherwise, they risk missing deadlines simply because no one realized a delay that occurred in one project had a cascading impact across multiple other initiatives. Regardless of who consumes the data generated by a VSM platform, the need to increase visibility across the software development life cycle had never been greater.

  • More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    A survey of 600 DevOps professionals conducted by strongDM, a platform for managing access to IT infrastructure, found nearly two-thirds (64%) had productivity impacted on a daily or weekly basis because of access issues.

    It’s not surprising that, as a result, DevOps teams created a number of workarounds to gain access, even though those methods don’t comply with cybersecurity best practices, according to the survey. More than half of respondents (55%) maintained backdoor access to systems, and 42% have embraced shadow IT to get access to tools and systems they needed for their roles, the survey found.

    Worse yet, the survey found that 53% of respondents admitted they are sharing credentials across teams.

    Well over half (57%) of respondents said it could take days or weeks for access requests to be approved, with 40% reporting it takes days to add tools to existing access solutions. Nearly three-quarters (73%) of respondents also noted it requires 15 minutes or more to gain access to infrastructure.

    More than half of respondents (52%) said they have missed deadlines due to issues with accessing infrastructure, with 53% of those respondents being held accountable for the missed deadline even if it was caused by their lack of access to infrastructure.

    Justin McCarthy, CTO for strongDM, said despite all the hype surrounding identity management and zero-trust IT, it’s clear many organizations are still struggling with the basics of access control. That issue has been further exacerbated by the need to enable more DevOps professionals to work from home since the start of the COVID-19 pandemic more than two years ago, he added.

    Many of those organizations are still relying on virtual private networks (VPNs) even though it’s been shown that stealing the credentials to access those VPNs is relatively trivial, McCarthy added.

    In place of those approaches to access IT infrastructure, strongDM is making a case for a dedicated infrastructure access platform that manages and audits access to databases, servers, clusters and web apps. It is based on local client software, a gateway intermediary and configuration tools that track roles and permissions.

    The benefits of that approach span everything from lower IT support costs to faster onboarding of new IT staff, noted McCarthy.

    Managing infrastructure access for DevOps teams is, of course, always going to be a challenge. DevOps teams are made up of engineers—among the most challenging types of end users to support. Many of them will use their own expertise to circumvent any process they deem to be inefficient. The trouble is, many of those end-runs would not pass muster with cybersecurity teams responsible for access management. The challenge each of those cybersecurity teams needs to come to terms with is the amount of time they want to spend time looking for these cybersecurity policy workarounds versus making it easier to securely access IT infrastructure.

    The sad truth is both DevOps and cybersecurity professionals are wasting a lot of time and effort trying to outwit each other when that time could be put to better use.

  • Survey Shows Increased Reliance on DORA Metrics

    Survey Shows Increased Reliance on DORA Metrics

    A new survey found just under a quarter (23%) of respondents are now tracking all four of the DevOps metrics defined by the DevOps Research and Assessment Team (DORA), with another 17% now tracking three.

    The State of Developer Experience survey polled 129 IT professionals that play a role in software development and was conducted by LeanIX, a provider of a platform for managing the building of enterprise applications.

    Dominick Rose, vice president of product management and strategy for LeanIX, said the ability to track DORA metrics such as deployment frequency (77%), failure rate (73%), lead time for changes (63%) and mean-time-to-recovery (MTTR) (55%) are leading indicators of DevOps maturity.

    DORA metrics, which are defined and maintained by a unit of Google, are being used most frequently to drive agile planning (69%) and optimize continuous integration/continuous delivery (CI/CD) platforms (58%), the survey found.

    Overall, the survey revealed just under half of the respondents (47%) said their organization had a high level of DevOps maturity, defined as having adopted three or more DevOps working methods. Those working methods are: Being flexible to changes in customer needs; having implemented a CI/CD platform; all engineers build, ship and own their own code; teams are organized around topologies and each team is free to choose its own technology stack.

    Of course, each individual organization will determine for itself what level of DevOps depth is required. For example, not every organization would see the need for teams to be organized around topologies or be free to choose its own technology stack. In fact, Rose said the survey made it clear that larger enterprise IT organizations tended to have a lower overall level of DevOps maturity. One reason for that is many larger organizations are still employing legacy processes to build and deploy software, noted Rose.

    Most developers are also further along in terms of embracing continuous integration (CI) than IT operations teams are in adopting continuous delivery (CD), added Rose. However, as the number of applications being developed using low-code and no-code tools continues to increase, it’s only a matter of time before application delivery needs to become more automated, he said. Achieving that goal will become easier as more artificial intelligence (AI) is incorporated into IT operations, Rose added.

    Nevertheless, the survey made it clear there is still a long way to go in terms of bridging the divide between DevOps teams and the rest of the business, with only 20% of respondents indicating that they use a value stream management (VSM) platform to track engineering efficiency to tie development activities to actual business results.

    A total of 71% of respondents, however, tracked open support tickets as a measure of customer value, followed by 66% that tracked monthly users and 45% that tracked feature adoption.

    It remains to be seen how DevOps will be further promulgated throughout organizations but as more organizations realize how dependent they are on software, it then becomes a question of how fully they embrace DevOps best practices as the pace at which applications are being built and deployed continues to accelerate.

  • TechStrongCon: Time to Build an Army of Citizen Developers

    TechStrongCon: Time to Build an Army of Citizen Developers

    DevOps teams need to start drafting a strategy to support what will soon become an army of citizen developers.

    Speaking at the virtual TechStrongCon event, JP Morgenthal, global director for modern applications development at DXC Technology, told conference attendees that the time to build an army of citizen developers is now.

    Citizen developers are typically end users that have developed enough expertise to build an application using low-code or no-code tools. Most organizations don’t have enough professional developers to address their application development backlogs, so it’s imperative that they enable end users to build applications, noted Morgenthal.

    Those citizen developers, however, need to be supported by DevOps teams to ensure guardrails are in place for building secure applications that scale. In addition, DevOps involvement also reduces the friction that a citizen developer will most certainly encounter when building an application, he added. “DevOps is fundamental, “ said Morgenthal. “We need to invest in it heavily.”

    Otherwise, citizen developers—who typically have other tasks that require their attention—will simply abandon their application development efforts, he noted. “This is not their primary task,” said Morgenthal. “They are going to need to be nurtured.”

    Most professional developers are focused on applications that are systems of record. The problem is that there simply are not enough of them to build necessary applications to drive systems of engagement, noted Morgenthal.

    That increased reliance on citizen developers is, in fact, part of a larger wave of democratization of IT in which individuals that don’t have advanced technology degrees take advantage of automation to build and deploy applications, he added.

    Organizations, however, run into issues when they fail to test those applications, make sure that configurations are not manually changed or don’t address the technical debt that inevitably accrues over time, said Morgenthal.

    Burnout can also become an issue, so Morgenthal said organizations need to make sure that agile development practices are used to first create a minimally viable product (MVP) and then plan development sprints to update and maintain it.

    Finally, there also needs to be a plan in place for shifting responsibility for the application to someone else when the individual that created it eventually leaves the organization, he added.

    Citizen developers, of course, are not the only ones using low-code and no-code tools. Many professional developers are using those same tools to build applications faster. In fact, it’s not clear how many end users have the skills required to successfully build applications, even though low-code and no-code tools automate much of the process. One way or another, many professional developers are now also collaborating more frequently with end users to build applications using low-code/no-code tools that make it easier for end users to, at the very least, describe the workflow of the application they want to build and deploy.

    Regardless of who builds the application, it’s a given that a lot more code will be moving through DevOps pipelines in the months and years ahead. DevOps teams, as a result, will inevitably need to revisit workflows and platforms to continuously update and maintain those applications at scale.

  • Buildkite Adds Analytics Tools to Identify Flaky App Tests

    Buildkite Adds Analytics Tools to Identify Flaky App Tests

    Buildkite has added an analytics tool to its continuous integration/continuous delivery (CI/CD) platform that identifies flaky tests.

    Buildkite’s co-CEO Keith Pitt said the company’s Test Analytics tool enables continuous performance monitoring and real-time insights for test suites that, when not properly written, only serve to waste DevOps teams’ time. Rather than eliminating those tests, most DevOps teams just opt to run them again on the assumption that the code they are testing will eventually pass because the test is poorly constructed, noted Pitt.

    Buildkite reports there are more than 800 million seconds—or the equivalent of 25 years—of flaky tests manually re-run on its platform by developers each month.

    In addition to being integrated with the Buildkite CI/CD platform, the Test Analytics tool can also be applied to tests residing in CI platforms such as CircleCI, GitHub Actions and Jenkins.

    Test Analytics includes a dashboard that identifies the slowest and least reliable tests to help prioritize test remediation efforts. Historical views and trend graphs are also available to provide further insight into recurring issues.

    DevOps teams can also take advantage of user-defined thresholds to define whether a test is slow or unreliable, which generate custom alerts when discovered. Finally, there are integrations with commonly used testing frameworks to determine where tests are, for example, wasting time running database queries against application programming interfaces (APIs) that have timed out.

    Pitt noted that most tests today are created by developers and software engineers rather than dedicated testing teams. As such, the chances there will be an issue with a test that is returning flaky results are high.

    Organizations are, of course, trying to determine how far left to shift application testing. Developers can write their own tests, but how thorough and objective those tests are is debatable. There are also certain tests that should be applied to all applications that organizations can embed within their DevOps workflows to make sure they are always run.

    Obviously, the more testing that occurs the fewer issues DevOps teams will encounter after an application is deployed. However, when tests are flaky, it becomes easier for developers to justify not running them even though that test might still surface an issue they should address. In addition to increasing confidence in the quality of those tests, knowing which tests are flaky allows a DevOps team to determine which tests should be run first. That’s critical at a time when more organizations are trying to increase developer productivity; that productivity is often adversely impacted by waiting for tests to be completed before more code can be written.

    Eventually, the overall quality of tests should improve as machine learning algorithms and other forms of data science are applied. In the meantime, however, the onus for improving application testing is clearly on the engineers that create them. The challenge is many of those engineers may not even be aware how flaky a test really is until someone shows them some empirical data that can’t be disputed.

  • Survey Reveals High Cost of Application Modernization

    Survey Reveals High Cost of Application Modernization

    A survey of 250 software developers and architects in the U.S. found nearly three-quarters of respondents (74%) reported that the average cost of an application modernization project is nearly $1.5 million, with 79% noting that at least one of these projects has failed.

    Conducted by Wakefield Research on behalf of vFunction, a provider of a platform that automatically converts monolithic applications into microservices, the survey polled developers and architects at organizations with 5,000 or more employees that have been in business for at least 15 years and are maintaining Java applications. The survey found that the primary reasons application modernization projects failed were expectations not being set correctly (43%) and the need for organizational structural changes (37%).

    Despite the cost and inherent risks, however, the survey also found a full 92% of respondents planned to or are currently modernizing applications. Nearly two-thirds (62%) said having the right resources and tools is the key to application modernization success.

    Well over half of the respondents (58%) also noted that, on average, it takes 16 months to complete these projects, with more than a quarter (27%) noting it takes two years or more. Not surprisingly, a full 97% said they expected someone in their organization would push back on a proposed project.

    Application modernization, of course, is something of a catch-all phrase that can involve everything from providing applications with a web frontend to lifting-and-shifting them into the cloud or completely refactoring them to run natively on a cloud platform.

    vFunction CEO Moti Rafalin said that regardless of the scope of the initiative, most organizations should first pick these projects based on what makes the most sense for the business. Once identified, it then becomes critical for IT teams to have a deliberate strategy in place to achieve that goal given the high cost of failure, he added.

    Organizations would also be well-advised to determine how job roles will evolve, because one of the biggest inhibitors to application modernization is concern over how any job might be impacted, noted Rafalin.

    It’s not clear how quickly organizations are opting to modernize existing applications versus replacing them outright. However, as more organizations opt to run applications in the cloud, the level of interest in using microservices to build applications has risen sharply. The goal is to employ microservices to make applications both more resilient and secure. The tradeoff is that microservices-based applications tend to have lots of dependencies that make them more challenging to manage and secure.

    Regardless of approach, it’s more a question of when an application will be modernized or retired versus if. The level of technical debt that accrues over time for each application eventually becomes unsustainable. The issue, of course, is that most organizations don’t have the resources required to modernize every application at once, so it may take a decade or more to work through an entire application portfolio—even as that portfolio continues to grow. In fact, as technologies continue to evolve, it may turn out that application modernization is not a task to be completed as much as it is a permanent state of IT affairs.