devopsy.kinsta.cloud

Author: Mike Vizard

Survey Sees Little Progress in Drive to Shift Testing Left

It looks like the drive to shift testing left toward developers to accelerate the development and deployment of applications has stalled. A survey of 102 IT professionals involved in application testing published by Perforce, a provider of testing tools, finds only 18% of organizations test applications solely within their development feature teams. The rest continue to rely on a separate team in one form or another.

More troubling still, the survey conducted by Gateway Research finds more than half the respondents (56%) are automating less than a quarter of their test cases.

Eran Kinsbruner, chief evangelist for Perfecto by Perforce, a set of testing tools, said the survey results make it clear that when it comes to automating testing within a DevOps environment there is still a lot of reliance on manual testing. In fact, the survey finds the rate of test automation is less than 50% on average. Almost 40% of teams are automating fewer than a quarter of their test cases, while only 9% automate three-fourths of their test cases, the survey finds.

On average, only 14% of respondents said they are releasing code daily. Another 39% said they release code weekly, while 46% release code monthly.

Kinsbruner said it’s clear most organizations are still engaging in a “Big Bang” approach to testing that results in most testing being conducted after large amounts of code has been merged versus being conducted by developers concurrently as code is developed. A total of 66% said they test code after a development project is ready, while 54% said they test when each build is ready. That compares to 43% who test upon each code change and 41% that test at the start of a software sprint.

A major reason many organizations are not releasing code faster is clearly manual testing. The survey identifies manual testing as the most time-consuming element of the testing process (72%), followed by test environment setup (28%), script creation/maintenance (27%) and test cycle analysis (19%). In terms of biggest challenges organization face, achieving complete test automation (47%) tops the list, followed by test instability/false negatives (44%) and lack of scripting/coding skills (41%).

In terms of overall priorities, survey respondents placed reducing regression testing time (46%), reducing the number of escaped defects (43%) and automated testing (43%) at the top of the list.

It may not be possible to automate every part of the testing process, but Kinsbruner said it is clear many more organizations could be automating lower-level testing processes to accelerate application development and deployment. In fact, the survey notes 46% of respondents are looking to invest in test automation in 2020. Among organizations that are using testing tools, two-thirds are using open source software (68%), while 66% are using some type of automation framework.

Regardless of the approach to testing, Kinsbruner said it’s clear testing teams need more visibility into the DevOps pipeline. Organizations are clearly underestimating how long it takes to thoroughly test an application, so the sooner those teams can see what is being developed the faster they can develop test suites, he said.

Of course, there are still plenty of development teams that are giving short shrift to testing in the name of achieving delivery deadlines. The trouble with that approach, however, is the end customer all too often winds up being dissatisfied to the point where the application winds up being reject altogether. After the end of the day, nobody really wants more bad code faster.

— Mike Vizard

February 7, 2020
New Relic Adds Support for W3C Trace Context Spec

New Relic has begun adding support for the W3C Trace Context standard within the agent software it uses to collect metrics for its application performance management (APM) platform.

W3C Trace Context is a specification that defines the format for propagating distributed tracing context between services. Distributed tracing makes it simpler for DevOps teams to track events across multiple services. Each step of a trace is correlated through an ID that is passed between services, with the specification defining a standard for the context propagation headers.

The W3C Distributed Tracing working group moved the Trace Context specification to the point where it could be consumed by platform vendors late last year. TraceContext has since been adopted by the OpenTelemetry project, an open source observability framework being developed under the auspices of the Cloud Native Computing Foundation (CNCF), along with providers of APM platforms such as New Relic, LightStep and Dynatrace. Vic Soares, director of product management for New Relic, said many of the individuals working on the TraceContext and OpenTelemetry projects come from the same organizations.

The first phase of the Trace Context project has focused on HTTP. The members of the project are also working toward defining trace context propagation for other formats, starting with AMQP and MQTT for IoT. The project team is also working on providing context propagation from clients and web browsers.

That approach solves an issue that arises when using proprietary formats: As trace context headers move across boundaries such as proxies, service meshes and messaging systems, proprietary headers tend to be dropped, which often winds up breaking traces, said Soares.

Soares said DevOps teams will need to upgrade the agent software they have in place to take advantage of Trace Context to provide more context across distributed services. Distributed tracing, however, will not replace sampling. Rather, distributed tracing provides a mechanism for identifying the root cause of issues that may first be uncovered using sampling techniques.

New Relic APM agents for Java 5.1.0 and higher, Python 5.5 and higher, Go 3.1.0 and higher and the New Relic open source Elixir agent now support the standard. Support for Trace Context support in other New Relic agents, as well as the New Relic Browser agent, are expected to be available shortly. New Relic APM agents that support W3C Trace Context can accept and emit both the W3C Trace Context header format and the New Relic header format. The new agents are also backward-compatible to enable trace context and will be propagated between services with older and newer releases of New Relic agents. IT organizations can also opt to disable the New Relic proprietary trace format once they’ve upgraded all agents to a W3C-compliant version.

Given the complexity of microservices-based applications, many organizations that deploy these applications will be among the first DevOps teams to take advantage of distributed tracing to not just troubleshoot applications but also proactively manage their application environments. Going forward, a lot more of the DevOps focus needs to be on identifying potential issues long before they can become a bigger problem.

— Mike Vizard

February 7, 2020
Dynatrace Extends AI Reach of APM Platform

Dynatrace, at its Perform 2020 conference today, extended the reach of the Davis artificial intelligence (AI) engine it makes available via its application performance management (APM) platform to include deeper ties with mobile applications along with an ability to track key performance indicators (KPIs) such as revenue trends and customer churn.

In addition, Dynatrace has enabled one-click integration with web analytics tools such as Adobe Analytics.

Those capabilities are in addition to deeper integration between the Davis AI engine and Kubernetes that was announced earlier this week at the conference.

Mike Maciag, chief marketing officer for Dynatrace, said usage of APM platforms is expanding beyond IT teams to include business users at a time when organizations are building and deploying more digital business applications. Most of those emerging applications revolve around mobile computing devices so Dynatrace is also extending the reach of the Davis AI engine to provide digital experience management capabilities, including advanced analytics and segmentation of mobile app user sessions, auto-instrumentation for additional mobile platforms such as React Native and tvOS and insights into third-party mobile applications components, he said.

Specifically, Dynatrace multi-dimensional analytics now include crash reporting workflow and granular segmentation capabilities spanning health, performance and usage metrics across all app components and user actions. That capability will eliminate an APM blind spot most organizations have today, said Maciag.

With more than 200 billion mobile applications having been deployed at a cost of $120 billion in 2019, Maciag said it’s apparent the scope of the challenge requires additional help from an AI engine.

Coupled with an ability to now track how application performance is impacting KPIs, Maciag said there is now an opportunity to unlock a gold mine of business data that is locked up in observability platforms using modules such as the Dynatrace Digital Business Analytics.

To further enable that capability, the Davis AI engine within that module provides automatic, real-time alerts on anomalies that might impact the business now using a wider array of data sources.

It’s not clear to what degree business users might rely on APM platforms to surface events that could impact business outcomes. Most business users rely on either business intelligence (BI) applications or traditional spreadsheets to manage the business. However, as more processes become digitized using software APM platforms can surface events long before they are ever reflected in a BI application or spreadsheet. In fact, chances are good that business leaders are more likely to be able to affect the ultimate outcome sooner should they choose to analyze events in real-time via an APM platform.

In the meantime, as application environments become more complex, reliance on APM platforms continues to grow. Once used mainly to keep track of only the most mission-critical monolithic applications in the enterprise, organizations are now tasking DevOps teams to manage entire business processes end to end basis. The challenge, of course, is most of those business processes consist of a wide variety of front and back-office applications that more often than not were built using entirely different frameworks.

— Mike Vizard

February 6, 2020
Report Pins Cloud Security Woes on Flawed DevOps Processes

By now it’s become apparent that the bulk of security incidents involving cloud platforms revolve around some type of configuration issue. An analysis of those cloud configurations published today by the Unit 42 research arm of Palo Alto Networks suggests that the root cause of the issue is most likely the templates many developers and DevOps teams rely on to configure cloud infrastructure. In fact, according to Unit 42’s analysis, more than 199,000 templates have medium-to-high vulnerabilities in use on public clouds.

Matt Chiodi, chief security officer for public cloud for Palo Alto Networks, said the issue stems from the rate at which organizations now want to be able to deploy applications on public cloud. Templates greatly accelerate the process but very few of those templates have been vetted by a cybersecurity team.

According to the report, the most commonly used templates are created using YAML files on instances of Kubernetes (39%), Terraform and CloudFormation (24%). The most vulnerabilities were discovered in templates created using CloudFormation (42%), Terraform (22%) and YAML for Kubernetes (9%).

Chiodi noted most templates are created through a simple three-step DevOps process: design, code and deploy. Unfortunately, in the rush to deploy most DevOps teams forget to scan for vulnerability issues. As a result, Chiodi said cybercriminals have become very adept at siphoning off cloud resources to mine cryptocurrencies at low-enough consumption rates to go unnoticed by many IT organizations.

Other significant cloud security issues surfaced in the report include the fact that 43% of cloud databases are not encrypted and that 60% of cloud storage systems have logging disabled, which Chiodi noted makes it impossible to know whether those systems have been compromised. In addition, the report finds 76% of cloud workloads expose SSH (port 22), while 69% of organizations expose RDP (port 3389) and 27% are using outdated versions of Transport Layer Security.

Overall, the goal now needs to be to make it as simple as possible for DevOps teams to do the right cybersecurity thing going forward, said Chioti.

Unit 42 researchers employed a publicly available GitHub Searching application programming interface (API) to find AWS CloudFormation files, Kubernetes YAML files and HashiCorp Terraform files. Hundreds of thousands of templates were then downloaded and analyzed by the Prisma Cloud infrastructure-as-code (IaC) Scanner to identify the insecure configurations. Each IaC file was also sent to an IaC resource checker to analyze the cloud resources being used in the template. Researchers also used Palo Alto Network’s proprietary AutoFocus and Wildfire tools to identify and investigate cybercrime groups through their usage of custom toolsets (malware samples). Those samples were dynamically and statically analyzed to ensure indicators of compromise.

The Unit 42 research makes it clear there’s a lot of room for improvement when it comes to employing best DevSecOps processes in the age of the cloud. The challenge, however, may have little to do with the tools available. Rather, it’s the absence of a structured set of processes through which DevOps teams and cybersecurity professionals can collaborate that appears to be inflicting the most damage.

— Mike Vizard

February 5, 2020
Report Finds Faster DevOps Adoption in Retail

Conventional wisdom holds that when it comes to any IT advancement, technology companies lead the way followed by the financial service sector. However, Puppet has made available an industry scorecard based on the company’s 8th annual “State of DevOps” survey that suggests that when it comes to DevOps adoption, it’s the retail sector that is now the most advanced.

The survey finds 28% of respondents working in the retail sector said they are deploying on-demand, while 57% said they can deploy on-demand. That compares to 26% doing so in the technology sector and 49% that are capable. In contrast, only 17% of the respondents working in the financial services/insurance sector said they are deploying on-demand, versus 42% who said they are capable.

The retail sector is also able to resolve critical vulnerabilities the fastest, with 53% reporting they can remediate a vulnerability in less than one day. However, the retail sector also ranks dead last in terms of reported “significant” or “full” security integration (32%).

Alanna Brown, director of product marketing at Puppet, said the retail sector is embracing DevOps more aggressively largely because of the increased focus on digital transformation. Companies are differentiating themselves more by the quality of the application experience, she said.

It’s also fair to note that application environments in the financial/life insurance sector tend to be more complex, she noted.

Of course, DevOps expertise of any one organization in an industry sector is likely to vary widely. However, the Puppet survey makes it clear that the adoption of DevOps is becoming broader.

In fact, in terms of year-over-year growth, the survey finds the media/telecommunications sector has made the second most progress after retail. The percentage of highly evolved telecom organizations increased by nine points from 8% to 17%. The number of organizations that scored in the low category dropped to 5% from 13%. A large proportion of telecom organizations are embedding a designated security expert in teams while maintaining a centralized security function (41%). However, in terms of DevOps adoption, only 16% said they do deploy on-demand, while 31% said they can. At that rate, that’s even slower than government agencies. A fifth of government agencies (20%) said they deploy on-demand, while 41% said they can. However, only 3% said they are able to remediate vulnerabilities in less than one hour and 24% are able to remediate in less than one day.

Brown noted that while there is still a lot of room for improvement across all vertical industry sectors, when it comes to DevSecOps there is a definite shift to the left occurring. Many development teams are now designating a cybersecurity expert that advises the rest of the team on security issues versus waiting to engage with a cybersecurity expert from within the central IT organization who has little to no programming expertise.

It may still be a while before DevOps is adopted pervasively across all vertical industry sectors. In the meantime, however, it’s clear that DevOps progress is finally starting to accelerate.

— Mike Vizard

February 4, 2020
Survey Finds Much Room for APM Improvement

A survey of 317 application owners, developers and support team professionals in the U.S. and Canada published by SolarWinds finds that while reliance on application performance management (APM) tools is widespread, most IT teams are still relying on these tools to react to events rather than to proactively improve application experience and performance.

The survey finds 9 out of 10 IT professionals are making use of APM tools that are either deployed on-premises or accessed via a software-as-a-service (SaaS) platform. Nearly 8 in 10 respondents spend less than 10% of their time proactively optimizing their environments, according to the results.

In fact, the biggest APM challenges identified by survey respondents were lack of training for personnel (57%), followed by a lack of awareness of what APM solutions are currently offered (44%) and confusion over which APM solution best fits their needs (42%).

Jim Hansen, vice president of products for application management for SolarWinds, said some of those challenges stem from the fact that there are too many APM tools to deploy and master. Survey respondents are employing a mix of database monitoring (64%), application monitoring (63%) and infrastructure monitoring (61%).

IT management is further being complicated by the adoption of a wide variety of application architectures. According to the survey results, organizations are applying APM tools to manage monolithic (traditional on-prem) app development architectures (59%), N-tier service-oriented architectures (40%) and microservices-based applications (39%).

Hansen said as organizations increasingly move away from monolithic applications, the need for a more proactive approach to APM across the full stack will become more apparent. The level of dependencies between microservices especially will drive organizations toward APM platforms capable of correlating events across both applications and the underlying infrastructure on which they depend, he noted.

Less clear is to what degree IT teams are comfortable using the analytics surfaced by APM tools to automate the remediation of any given issue. According to the survey results 84% of respondents are confident in their ability to successfully manage application and infrastructure performance, with 40% reporting they are most comfortable from a confidence perspective to use APM tools to troubleshoot application performance issues. The top three insights survey respondents said they gain from APM tools are the ability to prevent application outages (73%), the ability to prevent app slowdown related to performance and/or capacity (63%) and the ability to improve user/customer experience (62%).

In terms of areas for improvement, survey respondents identified improving their current skillset/ability to track impact across key business metrics (31%), followed closely by the need to improve their current skillset/ability to troubleshoot application issues (30%). The ability to improve the performance of application code and manage/ensure/improve end-user performance tied at 29%, respectively.

Of course, troubleshooting an existing issue is one thing. Proactively using APM tools to prevent issues from occurring represents a more advanced approach to managing IT in keeping with best DevOps practices. It will be interesting to see how much the adoption of N-tier and microservices applications will foster further adoption of best DevOps practices.

Most organizations today have embraced DevOps practices to varying degrees. However, as IT becomes more complex to manage in the age of the hybrid cloud it’s now only a matter of time before legacy approaches to managing IT as simply no longer practical to employ.

— Mike Vizard

February 4, 2020
Datadog Sees Spike in AWS Lambda Serverless Adoption

Datadog published a report that shows nearly half of organizations using the company’s IT monitoring platform have embraced the AWS Lambda serverless computing framework.

Stephen Pinkerton, a product manager for Datadog, said that number shows serverless computing frameworks are being employed by mainstream IT organizations far more widely than initially might be thought, given the relative age of serverless computing frameworks.

The report finds the median Lambda function invoked by Datadog customers runs for about 800 milliseconds. Nearly one-fifth of functions execute within 100 milliseconds, while about one-third execute within 400 milliseconds. One-quarter of Lambda functions have an average execution time of more than three seconds, while 12% require 10 seconds or more. The duration of Lambda functions is notable because serverless latency impacts not just application performance but also costs. Lambda pricing is based on “GB-seconds” of compute time, which is the memory allocated to your function multiplied by the duration of its invocations.

Not surprisingly, the report notes 47% of functions are configured to run with the minimum memory setting of 128MB. By contrast, only 14% of functions have a memory allocation greater than 512MB, even though AWS will allow up to 3,008MB per function.

As part of an effort to further limit costs, most organizations are not employing a function to call another function and then waiting for a response, which would incur billable invocation time. Rather, serverless functions are making asynchronous calls via a message queue. Functions that are stateless most often read from or write to a separate persistent data store.

Amazon DynamoDB, a document database based on a key-value store architecture, is the most widely used persistent form of storage accessed, followed by an instance of the SQL databases provided by AWS as a service, and then the Amazon S3 cloud storage service.

The Amazon Simple Queue Service (SQS) is the top choice for a message queue for Lambda requests, followed by Amazon Kinesis and Amazon Simple Notification Service (SNS).

The report also notes each Lambda function has a configurable timeout setting, ranging from 1 second to 15 minutes. Two-thirds of configured timeouts are 60 seconds or less. By default, Lambda customers are also limited to 1,000 concurrent executions of all functions in any given region. Only 4.2% of all functions have a configured concurrency limit. A total of 88.6% of companies running Lambda make use of concurrency limits for at least one function in their environment.

In terms of programming languages employed, Python and JavaScript in the form of Node.js are the most widely used on Lambda, the report finds. Nearly half of Datadog customers running Lambda (47%) employ Python, while 39% run Node.js. Python 3 outweighs Python 2, which has reached end of life, by a factor of two to one.

Finally, the report notes there is a high correlation between organizations that have adopted containers and those employing serverless computing frameworks. Nearly 80% of organizations in AWS that are running containers have adopted Lambda. However, Pinkerton says that correlation at this point has more to do with the willingness of organizations to employ leading-edge technologies than it does any effort to weave together containers and serverless computing frameworks.

Pinkerton also surmises the primary reason organizations are employing Lambda is to accelerate application performance. However, it’s also worth noting serverless computing frameworks also tend to reduce to the size of an application by relying on external functions to run code that is not frequently invoked outside the core application.

Datadog plans to evaluate usage of serverless computing frameworks on other cloud platforms once they achieve enough critical mass. In the meantime, it’s clear serverless computing frameworks are rapidly becoming an extension of any DevOps pipeline.

— Mike Vizard

February 3, 2020
Atlassian Extends Road Mapping in Jira

Atlassian has updated its Jira project management software for managing software development initiatives to add more capabilities to road mapping tools that teams use to share plans and update progress.

Matt Ryall, head of product for Jira Software at Atlassian, said the road mapping tools first provided in Jira a year ago are now being employed by 45% of customers, making it the most rapidly adopted feature in 18 years the project management application has been around. Thus far, Atlassian reports end users have created more than 2 million road map items within Jira.

Additional capabilities added to the road mapping tools provided in the latest edition of Jira include a drag-and-drop dependency mapping feature, support for filters to track projects more easily, a progress bar that indicates macro-level progress of each road map item, an ability to set up hierarchy levels on the road map, and the ability to set up road maps inline with a single click.

In addition, a live Jira road map can now be integrated with Confluence, a complementary tool from Atlassian for managing projects spanning multiple teams.

Atlassian currently offers several road-mapping solutions, including a team-level option in Jira, a program-level road map known as Portfolio for Jira and an enterprise organization-level version dubbed Jira Align. Atlassian has committed to making all three of these offerings work better together in 2020.

In addition, Atlassian is committing to bringing together the various road-mapping capabilities is provides across its portfolio. The company plans to enable organizations to aggregate multiple road maps into a single consumable artifact and is exploring ways to make road-mapping functionality accessible beyond Jira users. As more organizations in the age of digital business realize how much their future success depends on timely delivery of software, the number of end users who want to be able to monitor the pace of application development projects continues to expand.

In general, Ryall said Atlassian is focused on modernizing the end user experience for a project management application that is employed by more than 65,000 customers to manage software development projects. Much of that effort is focused on adding a visualization layer that will make it easier to navigate software development projects that continue to become more complex as organizations embrace, for example, microservices-based architectures.

Competition across the project management category is intensifying as startups look to drive alternative approaches that they claim are designed to support, for example, a mobile-first user experience that makes it easy to visualize data. It’s not clear to what degree any of those offerings are gaining traction, but a significant amount of venture capital is starting to pour into the sector.

In the meantime, visualization tools that promise to make it easier to appreciate what project events will have the most impact on the business are always going to be welcome. The real challenge, of course, remains getting developers to share accurate assessments of their progress with project team leaders. The good news is, it’s becoming much easier to automatically gather that data from the various repositories developers now rely on to check code in and out of various systems without having to ask anyone for an actual update.

— Mike Vizard

January 31, 2020
SIOS Technology Automates Rebooting of AWS EC2 VM Instances

SIOS Technology Corp. this week launched SIOS AppKeeper, a tool that automatically reboots instances of EC2 virtual machines anytime they fail.

Michael Bilancieri, senior vice president of products and marketing for SIOS, said SIOS AppKeeper is an extension of the work SIOS has historically done to enable servers and clusters to failover. However, many organizations don’t require that level of availability, so SIOS developed AppKeeper to provide a way to automate the process of restarting virtual machines in the cloud, said Bilancieri.

SIOS AppKeeper also provides a dashboard through which DevOps teams can centrally manage the stream of alerts that are generated when there is an EC2 issue, he said. SIOS AppKeeper is a software-as-a-service (SaaS) application so there is no software to be installed. Instead, organizations log into their AWS account and select which instances and services to monitor and the level of protection they want SIOS AppKeeper to provide.

Pricing for SIOS AppKeeper starts at $40 per EC2 instance. Monitoring and alert capabilities are provided by default. Restart services, reboot instances and reboot instances only if a restart of services fails are all options. Organizations can opt to access SIOS AppKeeper either via the graphical user interface provided or via an application programming interface (API), Bilanieri said.

Previously, SIOS AppKeeper was only available in Japan. Based on data from those customers, the average customer with only three AWS EC2 instances experienced downtime at least once a month. With SIOS AppKeeper, customers were able to reduce downtime by 90%, Bilancieri noted.

SIOS will consider adding support for other public clouds based on customer demand, he said.

Cloud service providers, in keeping with the “pets versus cattle” ethos, tend to view virtual machines as being disposable. However, whenever there is an issue someone on the IT team still needs to take the time to restart a virtual machine, Bilancieri said.

Despite the drive to ruthlessly automate in the management of IT in the age of DevOps, there are still many tasks being performed manually. As the number of workloads in cloud computing environments continue to increase, those tasks conspire to slow IT operations. There are, of course, many ways to automate IT processes in the cloud. SIOS is making a case for a simpler approach to managing EC2 instances that doesn’t require IT teams to set up an entire IT automation framework.

Many IT teams will opt to create their own scripts to manage EC2 instances. However, it’s all too often the case that those scripts are poorly documented and don’t scale especially well over time. In addition, each time the IT professional who wrote a script that the organization depends on leaves the organization, there is no one left to update and maintain the script and new members of the IT team wind up writing yet another script to perform the same function.

There will always be some type of script floating around the IT environment. However, in the age of DevOps, the time to start reducing the number of those scripts that need to be supported might be at hand.

— Mike Vizard

January 30, 2020
LightStep Adds Regression Monitoring to APM Platform

LightStep this week announced it has added a Service Health for Deployments module to its namesake observability platform designed from the ground up for microservices and serverless computing frameworks.

Talia Moyal, senior product manager for LightStep, said Service Health for Deployments will make it possible for DevOps teams to monitor performance regressions both during and after an application is deployed.

DevOps teams can also take advantage of aggregate trace analysis functionality such as latency histogram comparisons, operations diagrams and an automated correlation engine for performing rapid root cause analysis to understand why a regression is occurring.

Finally, a built-in instrumentation scoring capability enables DevOps teams to compare performance before, during, and after a deployment; compare latency across instances to estimate the size and scope of a regression; correlate tags that have the biggest impact on latency; and map critical path latency for each operation or service.

As organizations embrace microservices and serverless computing frameworks, the overall IT environment becomes more complex to manage. As an application performance management (APM) platform, LightStep makes use of OpenTelemetry software to gather metrics that are then fed into a statistical engine to detect anomalies, which the APM can then record and replay. By employing OpenTelemetry, LightStep is able to employ distributed tracing to surface more context than traditional APM tools, said Moyal.

Given the costs involved in employing APM platforms, most IT organizations historically have limited their use to their most critical monolithic applications. However, the dependencies that exist between microservices and serverless computing frameworks that make up a modern cloud-native application are now requiring IT organizations to apply APM platforms more broadly. In fact, observability is a core principle of best DevOps practices that many organizations are embracing more widely as they build and deploy cloud-native applications. Many of those applications will run just fine when initially deployed, but over time performance can degrade for a whole host of reasons that span everything from increased storage access latency to too many calls being made to the same application programming interface (API).

Of course, there is no shortage of options when it comes to APM platforms. LightStep is making a case for OpenTelemetry because it provides a single set of open source APIs, libraries, agents and collector services to capture distributed traces and metrics. That approach makes it easier for developers to instrument their applications in a way that allows platforms such as LightStep to surface more insights into application performance. LightStep claims it has already employed that approach to analyze more than 1.4 trillion traces. OpenTelemetry is currently being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

It’s too early to say to what degree traces will supplant traditional sampling methods to analyze application performance. The one thing that is certain is as developers are held more accountable for application lifecycle management, many of them are demanding access to more sophisticated APM tools to provide the visibility they require to resolve application performance issues faster.

— Mike Vizard

January 30, 2020