Designs get validated before they touch you. The lab is how the practice does that: a set of reference workloads, instrumented end to end, that a coverage decision, a log rule or an agent layout can be tried against before it is ever recommended for a client estate.
The reference workloads
Web tier, application tier and database, representative of the estates most enterprises still run and still need to observe well.
A set of microservices with a service mesh, representative of the estates organisations are moving to, where the service is the unit and workloads move and vanish.
A retrieval pipeline and a simple agent, representative of the workloads arriving next, with failure modes traditional monitoring does not see.
Each is instrumented end to end and driven with synthetic traffic and deliberately introduced faults, so a design can be tried against something that behaves like the real thing.
What it is used for
What it is not
The lab is not a demonstration environment, a training service or a product. It exists to make the practice’s designs better. Where a design point is easier to show than to describe, we will show it.
Questions
It is how the practice validates a design before recommending it. Coverage decisions, log rules and agent layouts are tried against reference workloads first, so a flaw is found against something representative rather than in a client’s production estate.
Because observability designs fail in details that only show up when something real is instrumented: a gateway placed behind the wrong firewall rule, a sampling rule that drops the one log that mattered. Finding those against a reference workload is far cheaper than finding them in production.
An hour with the practice, no slides, no obligation. Bring your incident history and your tooling list. Leave with a plain view of where your observability is working, where it is not, and what to do first.
Book an observability sense check