Marcus, the platform engineer

Snapshot

A day in his life

Starts with the overnight alert review: what fired, what should not have, what stayed silent that should not have. The morning is tickets from product teams (a new service to onboard, a quota to raise, "why is my pod pending"); the afternoon is the actual project work: Terraform refactors, cost optimization, the migration that has been 80% done for a quarter. Interruptions are the job, which is why he automates with the persistence of someone who has been paged for the same thing twice. He maintains the internal wiki nobody else updates and the dashboards everybody else screenshots.

Stack and tools

Tool	The job it does
Go / Python / Bash	Go for tooling, Python for glue, Bash for everything he swears is temporary
AWS	In depth: Lambda, ECS, EKS, RDS, SQS, the works
Terraform	Everything as code, with opinions about state management
Kubernetes	EKS clusters, a service mesh he regrets
Helm / Argo CD	The deploy machinery
Docker	Still the unit of everything
Prometheus	Metrics he trusts because he runs them
Grafana	The dashboards everybody else screenshots
CloudWatch	The floor of observability
Datadog / Honeycomb	The paid tier of visibility
OpenTelemetry	The instrumentation standard he is slowly migrating everything to
Splunk	Inherited, resented, still running
PagerDuty	The pager, escalation policies tuned by hand
Vault	Secrets, properly
GitHub / GitLab	Heavy CI, runbooks in Markdown next to the code where they belong
Slack	The incident channel and the paging bot

The homelab mirrors production more than he admits: k3s on mini PCs, Proxmox, self-hosted everything, monitored better than some companies' production.

Goals and motivations

• Make pages rare, actionable, and evenly distributed. The rotation's health is his professional pride.
• One live topology across AWS, Kubernetes, and the edge platforms, with change history attached to every node.
• Detection that learns per-resource baselines instead of static thresholds, with cadence and cost he can control.
• Keep his existing stack: alarms and saved queries that feed the new system rather than being replaced by it.
• Strict, auditable autonomy boundaries. He does not object to automation; he objects to automation he cannot explain in a postmortem.

Where he hangs out

He reads incident postmortems recreationally, plus the engineering blogs of Cloudflare, fly.io, and Honeycomb, and Google's SRE books, which he quotes selectively and distrusts institutionally. In person: KubeCon or re:Invent when the company pays, SREcon or Monitorama when he pays attention, local meetups where he occasionally speaks about something that broke.

How to reach him

What fails: "AI-powered" as the headline (he has a bingo card), hiding the security model behind a sales call (if he cannot find the permissions before signup, he is gone), claiming to replace his stack (a tool that ingests his ten years of tuned alarms beats a tool that dismisses them), and any pressure tactic.

What he resonates with

• Least privilege as a worldview: read-only by default, every write gated and on the record, rollback only where explicitly enabled. "The line is reversible versus not" is a sentence he would write himself.
• Blameless postmortem culture, runbooks as code, boring technology, Terraform plans reviewed like PRs.
• Evidence over vibes: he trusts a system that shows the hypotheses it tested and what it ruled out, and distrusts any system that only shows conclusions.
• Tools that respect prior investment: CloudWatch alarms picked up and investigated on arrival, Datadog and Honeycomb saved queries becoming scheduled checks.
• Honest engineering marketing: published limitations, real numbers, changelogs that admit regressions.

What turns him off: magic, mandatory dashboards, vendors that call him a "DevOps" as a noun, per-host pricing, AI features that cannot cite their sources.

Hobbies and personality

• The homelab is the signature hobby: self-hosted services, a rack in the garage, DNS ad-blocking for the household, monitoring dashboards for the aquarium. He automates his home with the same rigor as production and twice the joy.
• 3D printing, hiking or long-distance cycling, homebrewing or serious coffee, board games with a rules-lawyer streak he keeps mostly in check.
• Mentors juniors patiently and maintains one small open-source tool with three hundred stars and his exacting standards.
• Personality: skeptical, thorough, dryly funny, allergic to hype but not to change. Slow to trust, permanent once converted, and the loudest internal advocate a vendor can have when the product earns it.

Journey through the product

He enters as the evaluator, not the discoverer, and the make-or-break moment happens on the docs site before he even creates an account: reading the connect model and the IAM policy.

The evaluation itself is a shadow run: the feed diffed against his own alarms, false positives counted, quiet resources checked for staying quiet. He ends up at home in the power surfaces most users never open: OTel ingest with his own telemetry tokens, scoped API keys, kubectl through the agent, investigation-depth tuning per tier.

Feature affinities

• The topology graph with cross-provider stitching: a DNS record in one provider linking to a service in another is the map he has been maintaining by hand in a wiki.
• Change intelligence on every sync: change records with impact levels, and a thread that watches the migrations he currently babysits personally.
• Per-resource baselines with the tier cadence dial (critical resources checked every 10 minutes, low-tier daily): detection cost he can reason about.
• Advisories as a free audit: configuration gaps, missing observability, reliability risks per resource.
• Enterprise controls: bring-your-own LLM key and gateway, volume credits, data-plane options.

Objections and friction

• Missing table stakes for his world: PagerDuty, Grafana, Splunk, GitLab, and Terraform-state-aware linking are not live yet. The repo-to-infrastructure linking reads platform config files, not Terraform, and he will notice within the first hour.
• Verdict trust: he will run the product in shadow mode against his own alarms and believe the comparison, not the marketing.
• Data governance: where telemetry lands, how long it is retained, who can query it, and what leaves his boundary. He asks these before the security team does.
• Unattended writes: not for a long time, and never globally. Per-account and per-action opt-ins are the only acceptable shape.

Money and plan behavior

• Does not hold the budget but holds the veto. His written evaluation is what turns a Team plan into an Enterprise conversation.
• Cares about cost mechanics more than cost level: predictable flat pricing with visible usage and a capped overage passes; anything that scales with hosts or ingested GB triggers the Datadog reflex.
• The Enterprise levers that move him: volume credits, bring-your-own gateway, deployment and data-residency options, and a support channel with engineers in it.

What success looks like

• The two-week shadow evaluation ends with a false-positive count that rounds to zero and at least one real regression caught with a correct diagnosis before his own alarms fired.
• The rotation's mean time to understanding drops because incidents arrive with the first hour of archaeology already done and shown.
• He retires a page of hand-tuned alert rules without losing coverage, writes it up for the internal wiki, and becomes the product's most credible advocate in the company.

In their own words

• "Read-only role, scoped token, or no deal."
• "I don't need it to be smart. I need it to be right, and to show its work."
• "Ingest my alarms before you tell me to delete them."
• "If it pages my team wrongly at 3am once, we're done. If it saves them once, I'll defend it in the budget meeting myself."