Exercise 1: Switching Tracing Backends — What Changes and What Doesn't — Possible Solution
====================================================================

Explanation:

-- What DOESN'T change --
--
-- The application's own instrumentation code stays exactly the same:
-- every tracer.start_as_current_span(...) call, every manually set
-- span attribute, and every auto-instrumented HTTP/database span
-- continues to be generated through the same OTel SDK, using the same
-- API, completely unaware of which backend the resulting spans will
-- eventually end up in. The application only ever talks to the OTel
-- SDK, which sends telemetry out via OTLP -- it has no direct
-- knowledge of Jaeger, or whatever backend replaces it, at all.

-- What DOES change --
--
-- The change happens entirely in the Collector's own exporters
-- configuration -- the receivers stage (OTLP, receiving telemetry
-- from applications) and the processors stage (batching, filtering)
-- are both completely unaffected, since neither of them cares where
-- the data eventually goes. Only the exporters list changes: the
-- entry currently pointing telemetry at Jaeger is replaced with an
-- entry pointing at the new backend instead. This is a configuration
-- change to one YAML file (or equivalent), deployed and restarted on
-- the Collector -- no application needs to be recompiled, redeployed,
-- or have a single line of its own instrumentation code touched.

WHY THIS WORKS AS AN ANSWER
------------------------------
This separates the pipeline into its own three stages (receivers,
processors, exporters) exactly as the chapter's own diagram shows,
and explicitly identifies the exporters stage as the only place a
backend swap requires a change, directly explaining why application
code is unaffected rather than just asserting it.