Abstract:
=======
I started my own Observability journey a little over a year ago, when I managed the Observability Practices team at Tucows/Wavelo. As part of my journey, I learned about Observability and OpenTelemetry, and dove into what it takes to achieve Observability greatness at an organization-wide scale. Part of that involved understanding my Observability Landscape, and how it can be codified to ensure consistency, maintainability, and reproducibility.

Summary:
========
Observability is about good practices. Good practices are useless unless you have a consistent landscape. In order to support these practices, there are a number of setup-type things that are required to enable teams to truly unlock Observability’s powers.

With so many integrations and moving parts, it can be hard to keep track of all the things that you need in order to achieve Observability greatness. This is where Observability-Landscape-as-Code (OLaC) can help. OLaC means supporting Observability by codifying your Observability landscape to ensure:
* Consistency
* Maintainability
* Reproducibility
* Reliability

The Observability Landscape is made up of the following:
* Application instrumentation
* Collecting and storing application telemetry
* An Observability back-end
* A set of meaningful SLOs
* An Incident Response system for alerting on-call Engineers

Observability-Landscape-as-Code makes this possible, through the following practices:
1. Instrumenting your code with OpenTelemetry
2. Codifying the deployment of the OTel Collector
3. Using a Terraform Provider to configure your Observability back-end
4. Codifying SLOs using the vendor-neutral OpenSLO specification
5. Using APIs to configure your Incident Management systems

This talk digs into the above practices that support OLaC as part of my personal Observability journey (see journey details below).