jakacky.dev / projects

Projects

Open source, infrastructure work, and selected engineering projects.

Cloud Infrastructure

Selected infrastructure work across production Kubernetes, cloud platforms, automation, and reliability engineering.

Most of this work has focused on systems that need to remain understandable and operable after they have accumulated real production history: clusters, deployment workflows, traffic routing, identity, data services, observability, and incident response.

Focus areas

  • Production Kubernetes operations
  • GitOps and infrastructure as code
  • Azure and AWS cloud infrastructure
  • Cross-region traffic management
  • Platform automation
  • Observability and incident response
  • Operational documentation and repeatability

Selected work

  • Operated production Kubernetes infrastructure across multiple clusters and regions.
  • Improved cross-region traffic management by moving away from DNS-based failover behavior where corporate resolver caching created operational risk.
  • Built automation around infrastructure setup, service bootstrapping, and operational workflows.
  • Supported data and platform services across MongoDB, PostgreSQL/TimescaleDB, InfluxDB, and related observability systems.

Notes

This page is intentionally a high-level summary. More detailed writeups belong under writing.

Servekit

Servekit is a Go HTTP service toolkit for building production-ready microservices without adopting a heavyweight framework.

It focuses on the operational baseline most services need from the beginning: timeouts, request limits, panic recovery, access logging, request and correlation IDs, health endpoints, readiness checks, graceful shutdown, and optional observability.

Why it exists

Most Go services start small and accumulate production concerns later. Servekit tries to make the boring operational parts explicit early, while staying close to net/http.

Workerkit

Workerkit is a Go runtime toolkit for long-running workers.

It focuses on the lifecycle concerns that show up once background processes need to behave like production services: startup, shutdown, draining, health, readiness, error handling, and operational control.

Why it exists

Long-running workers often begin as simple loops and eventually accumulate production behavior around cancellation, retries, concurrency, observability, and shutdown semantics.

Workerkit is intended to make those concerns explicit and testable without turning the worker into a large framework.