Can APM Really Handle Serverless? - Part 2
October 28, 2020

Chris Farrell
Instana

Share this

The "APM" solutions we've come to love over the last 2 decades can't handle Serverless Functions or deliver the same performance and operational details that they deliver for other architectural constructs — including App Servers, Frameworks, Cloud, even Containers. And the reason is that they're methodologies for collecting performance data simply won't operate with the same characteristics as it would in persistent code.

Start with: Can APM Really Handle Serverless? - Part 1

And Then There's "Observability"

There are three ways conventional tools deliver service performance data to your monitoring tools:

1. API built into the platform — the consummate example of this is Lambda and Xray. This at least provides some level of performance detail, but it's nowhere near the richness and depth DevOps teams are used to (or need). PLUS: X-Ray provides data about the specific instance, AND ONLY the specific instance; but applications are distributed connected things — getting information about a single service without any knowledge of connected systems doesn't help understand what is getting in the way of distributed performance issues.

2. Pre-instrument the code — Like the way that some application monitoring tools tackled the container incompatibility issue, you could always run the code through an instrumentation step. While this allows the APM solution to get its hooks into the code, it loses the benefit of years of technology advancement in real-time instrumentation which allows decisions to be made on how much (or how little) to measure.

3. Open Source Observability — one or more of the observability APIs could always be put into place — of course, this requires some, if not a ton of, developer time to put the API instrumentation into their code:

■ Deciding what to instrument

■ Selecting which metrics to provide

■ Coding it in

■ Identifying those metrics for the tool

■ Selecting a visualization (If possible)

■ Analyzing logs for serverless events

All three of these approaches actually run counter to the value and efficiency promise of using Serverless Functions in a distributed application.

Option (1) simply doesn't have the juice to provide the detailed information needed for complex applications — and ZERO information about distributed functions, their dependencies (upstream and downstream) with other services, and no context or understanding of traces or end users to examine performance against.

(2) and (3) have similar visibility problems, depending on how much instrumentation is turned on and how much time you're willing to invest in your developers writing performance monitoring instead of their functional code. However, even though those decision points aren't trivial, the real problem comes in the way of cost and performance overhead.

After all, regardless of whether you load code pre-instrumented with a tool or code that your developers added monitoring lines of code, you are essentially operating at 10, 20, even 50% more code, cycles, overhead and cost than just your functional code. Replicate that overhead enough times and not only are you impacting your user service levels, you're blowing through all your serverless "savings" by paying for additional non-functional code.

There Are Options

Look, all is not doom and gloom. There are methods and ways to get the performance data you need across your distributed application, without blowing your budget or your error budget. Look for non-traditional APM tools that don't rely on either legacy instrumentation methods OR open source observability (BONUS, though, if the tool can actually run its own monitoring AND support observability instrumentation).

The key to these tools is that they're more intricately connected with the serverless infrastructure than a legacy APM tool might have. Good news — this means that there are solutions out there that can instrument serverless on the fly, using their connections with the infrastructure. Bad news — if the tool and infrastructure don't match up, you're back to square one. Sometimes that means you may change your infrastructure choice — and sometimes, that means you have to go with the basic instance-based metrics — and use your EUM to the best of your ability.

Anyway, don't be discouraged by this. You can still effectively use Serverless functions to create a more cost effective and efficient multi-cloud application ... and you don't necessarily have to give up that application visibility you've become accustomed to seeing. You will have to check (up front, hopefully) that you have the right tools and right infrastructure to do both. Happy Serverlessing!!!!

Chris Farrell is Observability and APM Strategist at Instana
Share this

The Latest

February 25, 2021

Organizations use data to fuel their operations, make smart business decisions, improve customer relationships, and much more. Because so much value can be extracted from data its influence is generally positive, but it can also be detrimental to a business experiencing a serious disruption such as a cyberattack, insider threat, or storage platform-specific hack or bug ...

February 24, 2021

Previously siloed IT teams and technologies are converging as enterprises accelerate their modernization efforts in reaction to COVID-19, according to a study by LogicMonitor ...

February 23, 2021

You surf the internet, don't you? While all of us are at home due to Covid lock-down and accepting a new reality, the majority of the work is happening online. IT managers are looking for tools that can track the user digital experience. Executives are reading a report from Gartner or Forrester about some of the best networking monitoring solutions available on the market. Project managers are using Microsoft Teams online to communicate and ensure team members are meeting deliverables on time. Remote employees everywhere use OWA to check their office mails. No matter what, you can be quite sure that everyone is using their favorite browser and search engine for connecting online and accomplish tasks ...

February 22, 2021

With the right solutions, teams can move themselves out of the shadows of error resolution and into the light of innovation. Observability data, drawn from their systems and imbued with context from AI, lets teams automate the issues holding them back. Contextualized data and insights also give them the language to speak to the incremental, product-led approach and the direction to drive key innovations in customer experience improvement. Communicating value becomes a much easier proposition for DevOps practitioners — and they can take their seat at the company table as contributors to value ...

February 18, 2021

Prediction: Successful organizations will blur (or erase) the line between ITOps and DevOps. DevOps has to coexist with traditional IT operations ... So bring a little DevOps to every aspect of IT operations. You don't even have to call it DevOps ...

February 17, 2021

The use of unified communications and collaboration (UC&C) solutions has increased since the start of the pandemic, and this increased use has created challenges for IT teams, according to a survey commissioned by NETSCOUT SYSTEMS ...

February 16, 2021
The AI+ITOPS Podcast just hit the 10K + download mark early this month. Most people listen to entire episodes, and many engage with us by sending a note on LinkedIn, Twitter, a direct email asking questions, clarifications, strategy advice, product selection advice ...
February 11, 2021

Cloud-based innovations like microservices, containers and orchestration let developers code better, faster, but the underlying infrastructure becomes dynamic and ephemeral, and service-level interactions are hard to see. It’s a critical evolution, but the rapid change reduces visibility, predictability and control. Hence, observability ...

February 10, 2021

Companies love data. Aggregating data from multiple sources makes decision-making easier and brings a new depth of the conversation to business meetings. But all of this is at the management level. IT managers and administrators also search for data from multiple sources to ensure that the ecosystem works ...

February 09, 2021

The cost of poor software quality (CPSQ) in the US in 2020 was approximately $2.08 trillion, according to The Cost of Poor Software Quality In the US: A 2020 Report from the Consortium for Information & Software Quality (CISQ), co-sponsored by Synopsys. This includes poor software quality resulting from software failures, unsuccessful development projects, legacy system problems, technical debt and cybercrime enabled by exploitable weaknesses and vulnerabilities in software ...