James Maradiaga

Problem

Cloud accounts that grew organically end up with resources nobody can account for, environments that disagree with each other, and a change process that depends on who remembers which console page to open.

Approach

• Model the whole environment in Terraform — network, compute, IAM and data services — with one module per concern and explicit inputs instead of long-lived forks per environment.
• Promote the same modules from staging to production so a path that has never been exercised cannot reach production for the first time.
• Run the plan in CI, review it as a diff, and apply through a pipeline with remote state and locking so two people cannot race the same change.
• Treat cost as a design constraint: right-sized instances, lifecycle rules on storage, and a tagging standard that makes spend attributable to a team.

Scope

Ongoing across current and previous roles

Problem

A cluster is easy to start and hard to own. Without guardrails it becomes a shared machine where a single unbounded workload can take down services owned by three other teams.

Approach

• Provision the cluster declaratively and keep cluster configuration in the same repository as the workloads that depend on it.
• Apply namespace-scoped guardrails: resource requests and limits, quotas, pod security standards, default-deny network policies and least-privilege RBAC.
• Instrument the platform itself — control plane, nodes, ingress and the workloads on top — before instrumenting the applications.
• Plan versions and node rotation as routine maintenance, not as an incident, with capacity headroom for the drain.

Scope

Niuro · Banco Industrial Guatemala

Problem

Deployments that depend on one person's shell history do not scale, cannot be audited, and fail differently every time. Manual releases also make rollback a separate, improvised project.

Approach

• Pipeline as code, with reusable workflows instead of copy-pasted jobs, so a fix lands once and applies everywhere.
• Authentication through short-lived OIDC credentials instead of long-lived cloud keys stored as secrets.
• Build once, promote the same artifact through environments — never rebuild per environment.
• Automate the routine operational work too: scheduled jobs, dependency updates, drift detection and the small scripts that remove repeated manual steps.

Scope

Across all engineering roles

Problem

Live media is unforgiving: a pipeline that works in testing can still fall apart under real network conditions, and by the time a problem is visible to viewers it has already been broadcast.

Approach

• Run the media toolchain in containers on Linux hosts so encoding and packaging versions are pinned and reproducible.
• Treat the network as part of the system: bitrate, buffering and segment duration are design parameters, not defaults.
• Monitor the stream itself — continuity, segment health, latency and host resource pressure — instead of only the host it runs on.
• Automate host provisioning and service restarts so recovery does not require waiting for a person to log in.

Scope

Toolbox

Problem

AI prototypes tend to live on one laptop with an unpinned environment. The moment they need to run reliably — for a team, on a schedule, on real data — none of that work transfers.

Approach

• Run models and tooling locally first, on hardware I control, to understand memory, latency and cost behaviour before renting it in the cloud.
• Treat environments as infrastructure: pinned dependencies, container images and reproducible setups instead of a working directory that only exists on one machine.
• Wrap model work in Python automation with explicit inputs and outputs, so a pipeline stage can retry safely and be observed like any other service.
• Keep the serving path conventional — containers, health checks, resource limits — because a model endpoint is still a production service.

Scope

Ongoing personal work