Exercise 3: Arguing for Direct Export on a Small Three-Service Project — Possible Solution
====================================================================

Argument for direct export (no Collector):

For a small, three-service side project, running a Collector means
taking on real, additional operational responsibility for a piece of
infrastructure whose entire value proposition -- one centralized
place to route telemetry to potentially many different backends, or
to switch backends without touching application code -- mostly
matters at a scale this project doesn't have. The chapter's own
warn-box is explicit that the Collector is real infrastructure, with
its own scaling needs and its own failure mode, not a free
abstraction layer that costs nothing to add.

With only three services, having each one export directly to
Prometheus, Loki, and Jaeger is a small, fixed, one-time integration
cost per service -- entirely manageable at this scale, and arguably
simpler to reason about than adding a fourth moving piece (the
Collector itself) that now also needs to be deployed, monitored for
its own health, and kept from becoming a single point of failure for
ALL of the project's telemetry at once. If this project genuinely
grows later -- more services, a real need to swap backends without
touching every service's own code -- introducing a Collector at that
point is a reasonable, deliberate decision to make then, once the
Collector's own benefits actually outweigh its operational cost. For
right now, at three services, direct export keeps the system simpler
with no real loss of capability.

WHY THIS WORKS AS AN ANSWER
------------------------------
This builds a genuine argument for the simpler option by directly
invoking the chapter's own warn-box (the Collector is real
infrastructure, not free), and reasons about scale explicitly rather
than treating "add the Collector" as a default best practice
regardless of project size.