Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Spear-phishing causes $540 million loss, a high severity bug in OpenSSL might be “worse than Heartbleed,” and Lennart Poettering is now working for Microsoft. (more…)
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.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Linus says next release will support Rust, FBI warns scammers are getting hired in deepfake interviews, and 80% of IBM staff stay at home. (more…)
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.
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.
Salesforce today announced that it is now using robotic process automation (RPA) to connect disparate data via a no-code tool developed by its MuleSoft unit.
Shaun Clowes, chief product officer for MuleSoft, said bots created using an RPA-infused integration platform can now automate much of the effort previously required to integrate data residing in different systems. Salesforce acquired MuleSoft in 2018 and, since then, has been working to make the platform for integrating application programming interfaces (APIs) a core element of its business process workflow tools.
The news was announced at the MuleSoft CONNECT 2022 conference. The overall goal is to employ RPA and no-code tools to accelerate digital business transformation initiatives without writing code, noted Clowes. Overall, Salesforce claimed its customers are running 4.8 billion MuleSoft transactions daily, resulting in a 74% decrease in operational costs and a reduction of more than 100 billion hours of work every month, using Salesforce Flow tools that are integrated with the MuleSoft integration platform.
In theory, no-code tools that integrate disparate data sources can be used by professional and so-called citizen developers alike. That capability should reduce the time and effort required to create those integrations. A recent survey conducted by Salesforce found nearly 96% of respondents said that modifying and rebuilding automation is a challenge as systems and business requirements change. In addition, four out of five respondents noted that restructuring existing application and data landscapes to support automation would likely compound their organization’s technical debt.
More than half of respondents (53%) said they are using integration and API management capabilities to some extent, with 44% employing those capabilities to drive business process automation initiatives. A full 80% said they are working toward putting hyperautomation on their technology roadmap within the next 24 months.
Of course, the MuleSoft platform can be employed beyond the portfolio of software-as-a-service (SaaS) applications provided by Salesforce. However, it’s also become apparent that more organizations are building and deploying custom applications on top of a range of SaaS applications in addition to building and deploying applications written in procedural code that might be running in the cloud or in an on-premises IT environment.
It will be up to each IT organization to determine how much they need no-code integrations as part of a larger DevOps workflow, but as it becomes easier to create integrations using RPA tools their numbers should increase. The impact all those integrations will have on DevOps pipelines remains to be seen, as well. Many organizations will need to revisit their DevOps workflows as the number of application development projects being simultaneously launched continues to increase.
In the meantime, it’s clear that no-code/low-code tools infused with RPA capabilities will empower more end users. That shift will have a profound impact on DevOps teams, as the sheer volume of code and associated integrations increases. The challenge, of course, will be finding a way to make sure that the integrations created are secure and that they can actually scale as more data sources are added.
The latest version of the GitLab continuous integration/continuous delivery (CI/CD) platform added a range of monitoring and visualization capabilities as part of an effort to embed a full set of observability capabilities in the core platform within the coming year.
As part of that effort, the latest version of GitLab, 15.1, has now added support for all the metrics defined by the DevOps Research and Assessment (DORA) team that is also part of Google.
In total, the 15.1 version of the GitLab platform has more than 30 updates. These include additional security capabilities in the form of support for the security assertion markup language (SAML) Group Sync and the Supply chain Levels for Software Artifacts (SLSA) framework defined by Google.
Finally, GitLab added links to all configuration files and templates included in the CI/CD platform to the pipeline editor to make it easier to manage large and complex pipelines.
Cindy Blake, director of product marketing for GitLab, said the monitoring, observability and security capabilities added to the platform are part of an ongoing effort to eliminate the ‘digital duct tape’ that many DevOps teams currently rely on to extend a CI/CD platform. In fact, as many DevOps teams look to better secure their software supply chains, many are now taking advantage of the moment to replace do-it-yourself (DIY) approaches with an integrated CI/CD platform based on a common codebase, noted Blake.
As part of that effort, Blake said GitLab is building its own dynamic application security testing (DAST) tools that are more tightly integrated with its CI/CD platform.
In general, there is now an expectation that the tools required to secure software supply chains should be made available within a CI/CD platform, but organizations are still working through the processes that will need to be implemented to achieve that goal, added Blake.
It’s not clear to what degree organizations are looking to replace legacy CI/CD platforms as they modernize application development and deployment. In many cases, however, the technical debt associated with maintaining custom integrations across their DevOps environment has become considerable. Many organizations are revisiting their DevOps workflows as part of an effort to increase overall developer productivity. The challenge, of course, is that migrating from one CI/CD platform to another requires considerable time and effort.
In the meantime, the number of organizations embracing DevOps best practices continues to grow. GitLab is betting that as the total size of the CI/CD market continues to expand, most of those organizations will prefer an integrated platform rather than writing and maintaining custom integrations themselves.
Regardless of approach, the ability to monitor and observe workflows is an essential element of any DevOps workflow. There is, of course, no shortage of observability platforms available. It’s not clear whether IT organizations will adopt one of those offerings versus taking advantage of observability and monitoring embedded within a CI/CD platform. One way or another, however, it’s getting easier to discover the root cause of any IT issue.
CodeSee today launched a free Open Source Hub (OSH) community through which developers can more easily analyze the codebase that makes up an open source software project.
Shanea Leven, CodeSee CEO, said that capability is crucial because making it easier to explore open source codebases reduces the level of effort required for developers to understand where to make contributions.
OSH is based on a namesake visualization tool that CodeSee created. The CodeSee tool makes it possible for developers to see how a codebase has been constructed using graph technologies that scan software repositories and identify components and their relationship to one another. Developers can also use CodeSee to better understand what impact changes to that codebase will have.
In addition to making it easier for developers to discover open source software projects, OSH also enables maintainers and contributors to create personal profiles through which other members of the open source community can see how their efforts have impacted various projects.
CodeSee, as part of OSH, is also providing integration with Discord, an online voice, video and text collaboration service, to make it simpler for maintainers and contributors of open source software projects to collaborate.
Leven said it simply takes too long today for most developers to pore over a codebase to understand where they might contribute. The larger a codebase becomes, the less likely it is a developer will want to take the time required to begin making a meaningful contribution, she noted.
OSH is arriving at a time when maintainers of open source projects are especially looking for help securing open source software. The core issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. Many of them simply don’t have the time to immediately provide a patch to an application when a zero-day vulnerability is discovered.
Unfortunately, many IT vendors and large enterprise IT organizations benefit from open source code without contributing anything meaningful back to the project—whether in terms of financing or helping open source maintainers find and remediate vulnerabilities. Not every contribution has to be in the form of code, either. Many open source projects simply need help with documentation which, once provided, should free up other contributors to focus more of their time and effort on application security.
It’s not clear to what degree business and IT leaders realize how dependent their organizations actually are on open source software. Even when they do, it’s not easy to onboard a developer to any software development project. It can take months before a developer is actually making meaningful contributions to a project.
Application development, by definition, is now a group effort. The days when a lone developer cared for an entire application are long over. The issue is finding a way for teams of developers to more easily collaborate when most of them have never actually met in person.
At its HasuraCon ’22 conference, Hasura today announced the early release of a software development kit (SDK) that extends the reach of its GraphQL platform to additional data sources.
In addition, Hasura is making generally available integrations with the GitHub repository, support for OpenTelemetry Traces within the Hasura Cloud Platform and Microsoft SQL event triggers.
Finally, Hasura Cloud can now be deployed on the Google Cloud Platform while the Hasura Cloud Enterprise edition is now available on the Amazon Web Services (AWS) marketplace.
Hasura CEO Tanmai Gopal said that while the company already provides support for widely used data sources such as the Postgres database, there are many data sources that organizations also want to be able to query via GraphQL application programming interfaces (APIs). Organizations want to be able to join data using GraphQL regardless of what repository it resides in, he added.
The open source Hasura engine at the core of the company’s offerings automatically generate a GraphQL schema from a data source. That can then be used to accelerate the development of APIs to make it easier for a wider range of developers to build applications that aggregate data across multiple sources.
That approach eliminates the backend complexity that IT teams encounter when adding GraphQL APIs to an application environment that already has a range of APIs for internal IT teams to support, noted Gopal.
GraphQL was originally created by Facebook, but it’s still not clear to what degree GraphQL APIs will supplant REST APIs. Developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited.
It’s not likely IT teams will replace REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. Overall, the number of APIs employed within IT environments is rapidly expanding as more microservices-based applications are deployed. Each microservice generates its own API. Over time, IT teams will find themselves managing a wider variety of types of APIs.
The challenge is that it’s not always clear who within IT organizations will manage those APIs. They are often created by developers and are left to IT operations teams to maintain. It’s not uncommon for IT teams to find themselves managing hundreds, perhaps thousands of APIs.
In addition, many of those organizations are now consuming data via APIs exposed by other organizations. Over time, the level of interdependency between APIs and applications will serve to make application environments much more complex to manage.
In the meantime, DevOps teams will need to extend existing DevOps workflows to both support and secure GraphQL-based APIs. The amount of sensitive data being accessed via those APIs is likely to accelerate the rate at which organizations are adopting DevSecOps best practices. Let’s hope this happens before they wake up to discover GraphQL APIs have already proliferated across the enterprise.
Dynatrace today extended the application release management capabilities it provides to include synthetic tests for validating and assuring user experiences.
Saif Gunja, director of product marketing for Dynatrace, said the user experience validation and user experience assurance (UXA) capability spans everything from application availability and performance to actual engagement with specific features based on the service level objectives (SLOs) defined by a DevOps team.
Dynatrace views application release management as an extension of its observability platform, said Gunja. While application release management has historically been viewed as an extension of a continuous delivery (CD) platform, Gunja said that observability platforms—such as the Dynatrace platform, which is infused with a Davis artificial intelligence (AI) engine—provide the visibility required to better automate the process.
In fact, as DevOps continues to evolve, it’s apparent that CD and continuous integration (CI) are becoming more loosely coupled as DevOps processes mature, said Gunja. Most organizations have yet to implement CD simply because it’s been too difficult to achieve. Each platform that applications have been deployed is unique. Dynatrace provides the foundation for automating application release management via the agent software it makes available to instrument applications, said Gunja.
It’s not clear whether DevOps teams are reevaluating their approach to application delivery, but Gunja noted that much of the interest in the Dynatrace approach is coming from organizations that have already installed the Jenkins CI/CD platform. The number of extensions that have been built and that need to be supported has created a level of technical debt that is unsustainable for many DevOps teams, he noted.
Many IT leaders concluded they would rather allocate more resources to building applications than maintaining DevOps platforms, added Gunja.
Most DevOps teams are committed to ruthlessly automating as many IT processes as possible. Observability has always been a core DevOps tenet in pursuit of that goal. Applications that are not instrumented can be programmatically managed. The issue is that providing observability isn’t enough—DevOps teams need to be able to take actions across the entire software development life cycle based on the data collected by the observability platform, said Gunja.
Obviously, it’s still early days as far as observability is concerned. While application performance management (APM) platforms have been employed for decades, it’s only recently that observability platforms capable of correlating application and IT infrastructure data have emerged. Thanks to the rise of open source agent software, it’s also becoming less costly to instrument IT environments. The challenge, of course, is, as always, deploying and maintaining all that agent software.
Regardless of the approach to observability and DevOps, it’s clear that IT teams will soon have a lot more visibility into their IT environments. The days when IT teams determined the root cause of an IT issue by process of elimination are finally coming to an end. Observability, however, is not an end in itself, but instead is the end of the beginning of a previous DevOps era.