For years I hoarded notes the way I hoarded half-written blog drafts: plenty of capture, no system behind it. Then life got busy and things became too much to track in my head, with no note I trusted enough to track it for me.
That’s when I came across the concept of a second brain: a collection of notes with an agent sitting on top, giving a single user the features I’d expect from any platform - ingest, ownership, sync and a rollback plan. If I wouldn’t run production without those, why would I run my own knowledge that way?
My second brain is a folder of plain Markdown files edited in Obsidian and versioned in git. AI agents maintain it. Every part has a platform equivalent:
capture -> Inbox -> sort -> Notes (Markdown + metadata)
|-> skills (jobs) -> saved reports
|-> scheduled runs -> briefing, calendar
'-> git -> history, rollback
type, status, sensitivity, updated and sources, so confirmed facts stay apart from wishes and open questions.01 - Inbox/ quick captures
02 - Projects/ one folder per project
03 - Areas/ ongoing responsibilities
04 - Knowledge/ durable reference notes
06 - Journal/ briefings and saved reports
07 - Archives/ nothing is deleted, only archived
08 - System/ skills, templates, standards
A skill is a written workflow: purpose, trigger, what it reads, what it writes, steps and approval gates. A few I use:
/daily-briefing: Priorities, due and overdue tasks, project updates and deadlines on one page./inbox: Sorts quick captures into the right notes./new-project: Interviews me, then drafts a groomed project note./youtube-notes: A timestamped summary of a video, shown in chat and saved only if I ask./study-quiz: Quizzes me from a study note, explains misses and keeps the attempt history.Most follow the same pipeline: gather, draft, show, approve, write. This post went through it - ideas, an interview about what I actually did, a draft, and a file written only after my yes.
The boring parts run on cron:
0 7 * * * github-progress # project state, read-only on GitHub
30 7 * * * calendar-sync # dated tasks to my calendar
0 12 * * * daily-briefing
0 20 * * * evening-inbox # report only, nothing filed
0 18 * * 0 weekly-changes
0 23 * * 0 backup
0 9 1 * * monthly-audit
The calendar sync only creates events. It never edits or deletes one, and it skips anything already there.
Every run ends in a report, and each finding becomes a #review task tagged fix: auto or fix: ask. A /fix command applies the safe ones as one batch (links, stale dates), asks me about the rest one at a time and archives reports with nothing left open.
Scheduled agents write to my notes while I’m not looking, so each run is controlled:
lock -> snapshot -> agent run (scoped) -> scope guard -> logs
The lock keeps one writer in the vault at a time. A git snapshot comes first, so any automated change can be reverted. Then the agent may write only inside its job’s scope. Afterwards a script checks what changed, copies anything out of scope to quarantine and restores it from the snapshot. Nothing is deleted.
It’s also agent agnostic. The rules live in AGENTS.md, not in a tool. Claude Code runs my skills interactively through a thin CLAUDE.md pointer, another agent (Devin) runs the scheduled jobs, and the slash commands are wrappers that name the same skill file. Switching the scheduler is one variable:
AGENT=devin # or: AGENT=claude
The rules are the source of truth, and the agent is just the runtime.
Lectures are where a lot of my learning happens, and their PDFs are the raw material. The /ingest-pdf skill turns a dropped PDF into a linked study note:
The pieces compound. A course note keeps a week-by-week map, a quiz skill tests me on a study note and keeps the attempt history, and a prep skill builds each week’s cheatsheet from its deadlines. When a week needed two notes, I gave them letters (04a, 04b) so the order stayed clear.
The structure isn’t finished, and I don’t want it to be. Each new use case has pushed a change into the design, and the changes are visible in the vault’s own change log. A few examples:
Project.md note and any research beside it.Project.md, which made the graph view unreadable. Each note now takes its folder’s name.The rule I’ve settled on: when a new use case shows up, I change the structure in the open, log the change, and keep the old version in git history. The brain is a working document, not a finished product.
The brain has its own roadmap, split into Now, Next and Later, with one rule borrowed from Kanban: an item enters Now only when another one leaves, and Now holds at most three. Anything that connects a service or installs something needs my approval first. A few items I’m most interested in:
phone-inbox/ folder, and the inbox skill files them. The catch is that Syncthing doesn’t nest folders, and iOS suspends the app, so captures wait until both devices are connected. Real-time capture was never the goal.Now (max 3) in progress
Next picked, not started
Later ideas, with the open questions written down
The same habit applies to the roadmap as to production: write the constraint next to the feature, so the “why not yet” survives.
A platform serves many users. Mine serves one, and that user is me at 2 AM wanting a straight answer. That changes the rules. An agent can’t be trusted just because it’s capable, so the policy is strict: act freely on drafting and linking, act then report on small reversible edits, ask first for anything that deletes, publishes or leaves the vault. It never silently overwrites a fact, and it logs every change.
The other surprise: structure took longer than tooling. The tools were the easy part. Deciding the folders, the metadata and the rules took far more effort, and that’s where the value is.
One honest opinion: this is overkill for most people. If a plain notes app keeps you organized, use that. YMMV. I built mine because I had too much to track, and I’d rather maintain a system with proper tooling than trust my memory.
]]>The platform team created our NAT Gateway once in a base VPC module and never touched it again. Product teams generated a significant amount of egress every deploy, but never saw the cost because it landed on a shared infrastructure line. Everybody simply saw “EC2-Other” climbing on the monthly invoice without knowing what it meant.
A managed NAT Gateway charges an hourly uptime fee (~$0.045/hour in us-east-1, slightly higher in European regions like Frankfurt at ~$0.052/hour), plus an identical per-gigabyte data processing fee.
That doesn’t sound punishing until you look at what’s actually traversing it. Every time an ECS task pulls a container image from ECR, queries an S3 bucket, or pushes logs to CloudWatch from a private subnet, AWS treats that traffic as external egress through the NAT unless told otherwise. You end up paying a per-GB processing fee on your own internal data.
To see what is actually hitting the gateway, avoid guessing. Run a quick CloudWatch Logs Insights query over your VPC Flow Logs on the NAT’s Elastic Network Interface (ENI):
fields @timestamp, srcAddr, dstAddr, bytes
| stats sum(bytes) as totalBytes by dstAddr
| sort totalBytes desc
| limit 10
Nine times out of ten, the top talkers aren’t public third-party APIs. They are AWS service endpoints.
Fixing this isn’t about re-architecting your entire network. It’s simply about taking the traffic off the NAT’s payroll:
AWS provides Gateway Endpoints for S3 and DynamoDB completely free of charge. There is zero hourly fee and zero data processing charge. Adding one updates your subnet route tables so traffic to S3 stays on the AWS private network:
resource "aws_vpc_endpoint" "s3" {
vpc_id = aws_vpc.main.id
service_name = "com.amazonaws.${var.region}.s3"
vpc_endpoint_type = "Gateway"
route_table_ids = aws_route_table.private[*].id
}
If your applications read datasets, media, or run heavy data lifecycles against S3, this single block drops your NAT data volume immediately.
For ECR, CloudWatch, and Secrets Manager, AWS offers Interface Endpoints (PrivateLink). These are not free - they cost around $0.01 per AZ per hour plus ~$0.01 per GB processed.
Do the break-even math before spinning them up: if a service processes 1 TB of image pulls a month, routing that through PrivateLink ($10) is vastly cheaper than routing it through a NAT Gateway ($45-$52). For low-traffic APIs, the idle hourly cost of the endpoint might exceed the NAT savings.
Shrink your container images and take advantage of ECS pull-through caches so tasks aren’t constantly pulling multi-gigabyte layers on deploy.
Additionally, watch your Availability Zone alignment. If a task in eu-central-1a routes through a NAT Gateway in eu-central-1b, you get billed for cross-AZ data transfer and NAT processing. AWS’s Regional NAT Gateway mode simplifies management across AZs, but remember that it still bills hourly for each AZ it covers - it is an operational abstraction, not a cost cut.
The only way to keep this spend under control permanently is to give network egress an owner:
NatGateway-Bytes usage type to catch rogue egress spikes before the invoice arrives.When I started balancing my full-time DevOps work with a part-time Master’s in AI, my immediate instinct was just to push harder. I figured I could tackle a full day of work and then easily grind through coursework late into the night. That strategy soon felt like hitting a wall. I had to stop winging my schedule and start treating my time and energy with real discipline.
In operations, it’s easy to feel like you have to be responsive every second, and your day can easily fracture into dozens of tiny distractions. If you spend all day reacting to things as they pop up, you finish mentally exhausted, with your actual core tasks half-done. That inevitably forces your workday to bleed into your evenings.
I had to get comfortable checking Slack in deliberate blocks rather than watching it constantly. Most questions aren’t genuine production incidents; they are async conversations that can wait an hour or two. Giving yourself focused, uninterrupted stretches during the workday is the only way you get to log off on time without feeling guilty.
When you juggle work and school, the weekend is a trap. The instinct is to turn Saturday and Sunday into 12-hour cram sessions to catch up on everything you didn’t finish during the week. Do that twice, and Monday morning feels like a punishment!
Instead, I treat the weekend in two distinct modes. Saturday morning is reserved for a single deep-focus academic block—tackling math proofs or coding an assignment that requires three uninterrupted hours. By 13:00, the laptop closes.
The rest of the weekend is non-negotiable downtime. Whether that means going out, physical activity, or just unplugging completely, it forces my brain to drop the cognitive load entirely. If you don’t deliberately protect that space to reset, you start next week already running on empty.
]]>The core issue with managed tools like DataDog isn’t always the base pricing—it’s how they calculate custom metrics. A single metric is defined by the unique combination of the metric name, tags, and host. This means cardinality is multiplicative. If you have 50 microservices and you decide to add a request_id tag to a core metric processing millions of requests, you haven’t just added a label; you’ve instantly created millions of unique, billable time series.
When I architected our migration away from DataDog to a custom Loki, Grafana, and Prometheus stack hosted on AWS, the goal was cost reduction. We ended up slashing our monthly observability costs by roughly 90% across our cloud and on-premise infrastructure. But looking back, the most valuable part of that migration wasn’t swapping the infrastructure itself - it was the forced cleanup of what we were actually indexing.
Self-hosting Prometheus forces you to confront your cardinality directly because if you don’t, your own instances will simply run out of memory. You realize very quickly that a massive portion of ingested series are never actually used in any dashboard or alert.
To maintain that 90% cost reduction and keep our AWS backend running efficiently, we had to enforce strict lifecycle boundaries on our metrics.
Instead of ingesting every unique identifier, you drop high-churn, high-cardinality labels before they ever reach storage. In Prometheus, you handle this at scrape time using metric_relabel_configs.
Here is a realistic snippet of how you strip out expensive labels like pod_name or temporary revision hashes before they bloat your TSDB:
# prometheus.yml snippet
scrape_configs:
- job_name: "kubernetes-pods"
kubernetes_sd_configs:
- role: pod
# Drop high-cardinality labels before ingestion to save memory and storage
metric_relabel_configs:
- action: labeldrop
regex: "pod_name|replicaset|controller_revision_hash|request_id"
# Alternatively, drop entire metric families that nobody queries
- source_labels: [__name__]
regex: "go_memstats_.*_bytes"
action: drop
By explicitly dropping these labels, Prometheus aggregates the data, and your millions of unique series collapse back down into a manageable, queryable dataset. Observability should mean answering specific operational questions, not hoarding every possible data point.
]]>We spend endless cycles optimizing CI/CD pipelines to shave off two minutes of build time, but we completely ignore the fact that engineers spend hours fighting their own laptops just to boot the stack. This is the hidden tax of bad developer platform engineering.
Over time working in DevOps, it became blatantly obvious that raw cloud infrastructure efficiency means little if the local feedback loop is crawling. Every time a developer has to debug a local PostgreSQL version mismatch or untangle an undocumented environment variable, you lose momentum.
Cleaning up deployment platforms and standardizing the local stack is directly correlated with preserving developer sanity. A frictionless local setup compounds into massive productivity gains because developers are actually writing code, not playing sysadmin.
The solution is strict, reproducible environments. In my experience, migrating to fully containerized dev environments fundamentally changes the engineering culture. When we adopted docker compose dev setups, we managed to streamline onboarding and accelerate our deployment cycles significantly, just because “it works on my machine tho” stopped being a valid excuse.
Instead of a README bloated up with bash commands, a new engineer should just need this:
# docker-compose.dev.yml
services:
api:
build:
context: .
target: development
ports:
- "3000:3000"
volumes:
- ./src:/app/src
environment:
- NODE_ENV=development
- DATABASE_URL=postgres://user:pass@db:5432/localdb
depends_on:
- db
db:
image: postgres:15-alpine
ports:
- "5432:5432"
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:
One docker compose up and the entire stack is ready.
If you want to strip the friction out of your local setups, here are the tools actually worth your time:
devcontainer.json is basically magic. It spins up a container and mounts your editor directly inside it, pre-installing all the exact extensions, linters, and runtimes the project needs.direnv to auto-load environment variables the second you cd into a directory.Treat your local dev environments like production infrastructure. Automate it, document it, and get out of the developers’ way.
]]>Moving from Python to Rust feels less like learning a new language and more like unlearning bad habits. You don’t just swap out def for fn and carry on. You have to fundamentally change how you reason about memory boundaries, state mutations, and what actually constitutes a “safe” concurrent operation.
When I was working on migrating a legacy codebase from Python 2.7 to modern Python 3.8, the mental model was entirely runtime-dependent. You write the logic, write the tests, push to staging, and inevitably discover a handful of unhandled errors that slipped through.
Contrast that with my experience engineering high-throughput microservices from scratch with Rust. The strict, compiler-driven discipline of Rust forces you to confront every possible failure state before the code even compiles. It is a massive hurdle at first, but it completely changes your operational baseline long-term.
We all know Rust is incredibly fast. But when you are designing systems, raw compute speed is only one piece of the puzzle. The real game-changers for high-throughput cloud messaging are memory safety and predictable concurrency.
In Python, spinning up a thread pool to process an SQS queue is syntactically easy, but ensuring thread-safe state sharing is a constant battle against the Global Interpreter Lock and subtle race conditions. In Rust, if your concurrency model is flawed, the compiler simply refuses to build it.
Let’s look at a minimal example of polling an AWS SQS queue. In a traditional Python approach, you might wrap a boto3 call in a broad try/except block. Rust forces a much safer paradigm:
use aws_sdk_sqs::{Client, Error};
async fn poll_sqs_queue(client: &Client, queue_url: &str) -> Result<(), Error> {
let receive_message_output = client
.receive_message()
.queue_url(queue_url)
.max_number_of_messages(10)
.send()
.await?; // The '?' forces explicit error propagation
// messages() returns a slice in aws-sdk-sqs 1.x, so we check it directly.
if receive_message_output.messages().is_empty() {
println!("Queue empty, gracefully backing off.");
} else {
for msg in receive_message_output.messages() {
// Rust forces us to handle the Option explicitly. No implicit NoneTypes.
if let Some(body) = msg.body() {
println!("Processing message payload: {}", body);
// Pipeline logic goes here
}
}
}
Ok(())
}
Notice the heavy reliance on Result and Option types. There are no null pointers or runtime exceptions lurking in the pipeline. You are forced to explicitly acknowledge that the queue might be empty, that a message body might not exist, or that the network call might fail.
This shift from runtime hope to compile-time guarantees is a steep hill to climb. But once you rewire your mental model to satisfy the borrow checker, the anxiety of deploying asynchronous cloud infrastructure virtually disappears.
]]>Developers treat the AWS bill like a problem for the finance team, right up until a rogue Lambda function burns through the quarterly budget in a single weekend. The usual response is a panicked Slack thread, a quick patch, and a vague promise to “keep an eye on costs.”
That approach is fundamentally broken. You wouldn’t push code that degrades system latency by three seconds and tell the product team you’ll simply keep an eye on it. Cost shouldn’t be treated any differently. Shifting the conversation from “how to save money” to “how to build cost-aware systems” fundamentally changes the way you design architecture.
In my experience with AWS and Terraform, looking at infrastructure through this exact lens is how I managed to slash our core AWS infrastructure spend by 73%. When scaling the AWS backend architecture for our SaaS at adnymics, I realized that meaningful cost reduction was about enforcing strict lifecycle boundaries at the code level.
We executed comprehensive FinOps strategies by treating EC2 and RDS rightsizing and S3 lifecycle policies as core engineering patterns. If an asset doesn’t need to live in standard storage indefinitely, its transition to colder storage should be codified on day 1.
# Treating cost as a constraint: automated data archiving
resource "aws_s3_bucket_lifecycle_configuration" "cost_aware_storage" {
bucket = aws_s3_bucket.app_data.id
rule {
id = "archive-stale-data"
status = "Enabled"
transition {
days = 30
storage_class = "GLACIER"
}
expiration {
days = 365
}
}
}
Beyond storage, compute waste is almost always a symptom of operational friction. We implemented automated test-environment teardowns to guarantee that ephemeral resources actually stayed ephemeral. When you bake these constraints into your environments directly, cost management becomes an invisible byproduct of good engineering.
Treat your budget like an SLA. If you architect for it up front, the finance team will never ping you about a spiked cloud bill.
]]>Designing cloud-native backends teaches you a lot about fault tolerance and resource allocation. But ironically, the hardest scalability lessons I’ve learned didn’t come from configuring AWS - they came from trying to scale my own bandwidth as a mentor and community leader.
When I was designing containerized dev environments, the goal was strictly operational: reduce the local onboarding setup time for new engineers. Recently, I realized this exact platform engineering principle applies perfectly to navigating human bottlenecks.
In 2025, I founded Ilm Abroad Pakistan, an educational project to help students navigate the complex university and visa application processes for Germany. At first, I was doing what every junior engineer does with a new server: manually provisioning everything. I answered the same visa questions and reviewed the same application formatting over and over.
It didn’t scale. The manual onboarding was causing dropped packets (missed emails) and latency (delayed responses).
To fix it, I had to treat the mentorship program like developer platform engineering. I built out structured documentation and standardized “runbooks” for the students. Just like a good CI/CD pipeline removes friction from shipping code, creating self-serve guides removed the friction from the university application process.
Leading an 80+ member Google Developer Student Club during my Bachelor’s taught me that “human availability” is a finite, easily exhausted resource.
If you route all incoming traffic to a single node without a load balancer, that node will eventually crash. The same thing happens when every single community question, technical blocker, or event planning detail is routed directly to you. To maintain high availability in a community, you have to architect away single points of failure.
If I were to define this community management approach as infrastructure-as-code, it would look something like this:
# Mentorship Request Routing Pipeline
name: human-load-balancer
on:
incoming_request:
types: [visa_help, tech_blocker, general_advice]
jobs:
route_traffic:
runs-on: community-cluster
steps:
- name: Check Documentation Cache
run: |
if request in standard_faqs:
return docs.ilmAbroad.url
- name: Delegate to Peer Network
if: cache_miss == true
run: |
assign_to(available_senior_students)
- name: Escalate to Founder
if: complexity > threshold
run: |
alert(dorrabb)
schedule_async_meeting()
By caching the common answers (documentation) and delegating the initial routing (peer network), you reserve your active processing power for the highly complex edge cases that actually require your intervention. When you start viewing human burnout as a failure to implement proper queueing, the solutions become a lot more obvious.
]]>We spend years mastering our tech stack, but almost zero time learning how to talk about it. When you transition into a senior role, the bottleneck stops being your ability to write a Terraform module. The real bottleneck becomes your ability to explain why that module is necessary to a stakeholder who just wants the feature shipped, or a Board staring at a massive cloud bill.
When you talk to non-technical stakeholders, you have to completely drop the engineering jargon and focus exclusively on business impact: cost, risk, and speed.
For example, when I architected the migration of our observability stack away from DataDog to a custom Loki, Grafana, and Prometheus setup on AWS, I didn’t pitch the stakeholders on the technical elegance of PromQL. I pitched them on the fact that this move would slash our monthly observability costs by up to 90%.
To win technical arguments, frame them as business solutions. If you want to spend two sprints paying down technical debt, explain how it directly translates to faster feature delivery or a reduction in SLA breaches next quarter.
Over time, I also noticed that metaphors do a lot of the heavy lifting in these conversations. Stakeholders don’t need the precise mechanics; they need a mental model they can reason with. A well-chosen metaphor hands them that model in seconds, and once they have it, all the relevant technical details you present actually stick.
A good Architecture Decision Record (ADR) shouldn’t just be a log of what the engineering team decided to do. It needs to be a document that translates complex technical reality into clear business context.
Here is the straightforward ADR format I would recommend to ensure both developers and the business are aligned:
# ADR [004]: Migrating Observability Stack to Loki/Prometheus
**1. The Business Problem**
Our current SaaS monitoring costs are scaling linearly with our traffic, currently eating up X% of our monthly infrastructure budget and hurting product margins.
**2. The Technical Decision**
We will migrate our primary observability pipeline from DataDog to a self-hosted Loki, Grafana, and Prometheus stack on AWS.
**3. The Bottom-Line Impact**
- **Pros:** Projected 90% reduction in monthly observability costs. Total control over data retention policies.
- **Cons (Trade-offs):** Requires approximately 4 weeks of dedicated engineering time to build. Introduces minor ongoing maintenance overhead for the DevOps team.
**4. The Rollout Strategy**
Run both systems in parallel for 14 days to validate metrics, then tear down the legacy system.
By explicitly listing the business problem first and clearly defining the trade-offs (including engineering time), you eliminate the friction between engineering and management. You give the board exactly what they need to make an informed decision, and you give your team the air cover they need to actually do the work.
]]>Every time a new project spins up, someone reaches for a Helm chart. We’ve convinced ourselves that if we aren’t running a multi-node Kubernetes cluster from day one, we’re doing it wrong. The reality is that prematurely optimizing for scale just results in a bloated cloud bill and an unnecessarily complex deployment pipeline.
There is massive value in pushing simple microservice limits before introducing heavy orchestration. Boring architecture is predictable and doesn’t require a dedicated team to troubleshoot at 2 AM.
In my experience with ECS, you get the vast majority of container orchestration benefits without managing a control plane. Infrastructure spend is healthy, and deployment speed is vastly superior using straightforward CI/CD pipelines and Docker/Ansible for containerized dev environments.
Here is a simplified look at the kind of “boring” configuration that handles serious production traffic without a single kubectl command:
[Amazon Route 53]
|
v
[Application Load Balancer]
|
v
[AWS ECS (Fargate)]
(Stateless API Containers)
/ \
v v
[Amazon RDS] [Amazon S3]
(Database) (Static Assets)
With a setup like this, upgrading a node pool simply doesn’t exist. You push code, your pipeline triggers a rolling update, and traffic shifts gracefully.
So when do you actually need Kubernetes?
You need it when the “boring” stack genuinely breaks. If your service discovery between dozens of microservices has become an unmanageable web, it might be time.
Until you hit those very specific operational walls, stick to the simple stuff. Lean on managed services to do the heavy lifting. Give yourself a break on the operational overhead, and spend that engineering time actually building your product.
]]>Jekyll is a static site generator. There’s no database to patch, no server to maintain, and zero hosting costs via GitHub Pages. It’s entirely decoupled. I also wanted a frictionless developer experience for my writing, which is achieved completely via this setup.
My blog workflow relies entirely on standard Markdown front matter:
---
layout: post
title: "Keeping it Simple: Jekyll for a DevOps Blog"
date: 2026-02-03
---
I write a post, run git push, and GitHub Pages handles the rest.
Give yourself a break on your personal projects. Sometimes a folder full of Markdown files is all you need.
]]>Twelve posts by the end of December. Let’s see if keeping it simple actually keeps my blog active.
]]>