# James Maradiaga — Lead DevOps Engineer

> Building reliable infrastructure for software that matters.

Lead DevOps Engineer focused on cloud infrastructure, Kubernetes, automation, reliability, and AI/MLOps.

## Facts

- **Name:** James Maradiaga (GitHub handle: `Ancordss`)
- **Role:** Lead DevOps Engineer at Niuro (2025 — Present)
- **Location:** Guatemala (time zone America/Guatemala)
- **Email:** maradiaga.l.james@gmail.com
- **LinkedIn:** https://www.linkedin.com/in/jamesmaradiaga
- **GitHub:** https://github.com/Ancordss
- **Technical blog:** https://blog.ancordss.me.uk
- **Focus areas:** Cloud infrastructure, Kubernetes, Infrastructure as Code, CI/CD, automation, reliability engineering, observability, cloud cost optimization, security, Python and Go engineering, MLOps
- **Public repositories:** 43

## Working languages

- English (site default)
- Spanish — the site is fully bilingual; switch with the EN/ES control in the navigation.

## About

Most of my work happens where software meets the machine: Linux hosts, cloud accounts, container runtimes and the pipelines that move changes between them.

I build and operate platforms — the provisioning, the cluster, the delivery path, the dashboards someone opens at 03:00 when something is off. The goal is never tooling for its own sake: it is infrastructure that other engineers can reason about without needing me in the room.

Day to day that means writing Terraform instead of clicking consoles, designing CI/CD that gives fast and honest feedback, hardening Kubernetes, and automating the operational work that would otherwise be done by hand at the wrong moment. I program in Python and Go, mostly to delete repetition.

I work across Linux, cloud infrastructure, containers, Kubernetes, automation and programming. I care about the unglamorous parts: idempotency, least privilege, cost visibility, and knowing exactly what happens when a node disappears.

### Engineering philosophy

- **Automate.** Reduce manual work and make systems reproducible. If a task needs to be done twice, it belongs in code.
- **Engineer for reliability.** Design infrastructure that is observable, scalable and resilient — and assume the failure will happen during the worst possible change window.
- **Keep it simple.** Prefer understandable systems over unnecessary complexity. Boring infrastructure that everyone can read beats clever infrastructure only one person understands.

### Currently

- Leading cloud infrastructure and DevOps practice at Niuro
- Kubernetes platforms, Infrastructure as Code and delivery pipelines
- Observability, security hardening and cost awareness
- Local AI infrastructure and production-oriented MLOps

## Experience

Ten years ago I was fixing workstations. Today I lead the infrastructure other engineers ship on. The through-line is the same: understand the system, then remove the parts that hurt.

### Lead DevOps Engineer — Niuro

2025 — Present (current)

Leading the design, implementation and operation of scalable cloud infrastructure and DevOps practice — Kubernetes platforms, Infrastructure as Code, delivery pipelines, observability, security and engineering enablement.

Focus: Cloud infrastructure, Kubernetes, Infrastructure as Code, CI/CD, Observability, Security, Automation, Engineering leadership

### DevOps Engineer — Toolbox

2024 — 2026

Linux infrastructure and production operations, including streaming infrastructure — packaging, networking and monitoring of live media pipelines running on Linux hosts.

Focus: Linux infrastructure, Streaming infrastructure, Automation, Docker, Monitoring, Networking, Production operations

### DevOps Engineer — Banco Industrial Guatemala

2024

DevOps engineering in a regulated environment: containerized workloads, cluster operations and infrastructure automation for internal platforms.

Focus: Kubernetes, DevOps, Infrastructure, Automation

### DevOps Engineer — Data Buddies

2022 — 2024

AWS and Linux administration, cloud infrastructure build-out with Infrastructure as Code, and automation of routine operational work.

Focus: AWS, Linux, Cloud infrastructure, Infrastructure as Code, Automation

### IT Support — Municipalidad de Ciudad Vieja

2019

IT support and systems administration — the starting point where I learned how machines actually fail in the hands of the people using them.

Focus: Systems support, Networking, Linux

## Projects

These are the problem spaces I work in. Each one is written as an engineering case study — context, architecture and approach. Anything I cannot verify publicly is left out or marked accordingly.

### 01. Cloud infrastructure

AWS · Azure · GCP · Ongoing across current and previous roles

Designing scalable cloud infrastructure with Infrastructure as Code.

**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:**

1. 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.
2. Promote the same modules from staging to production so a path that has never been exercised cannot reach production for the first time.
3. 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.
4. Treat cost as a design constraint: right-sized instances, lifecycle rules on storage, and a tagging standard that makes spend attributable to a team.

**Outcome:** Environments that can be rebuilt from the repository, changes that are reviewed before they are applied, and infrastructure that a new engineer can read as code on their first week.

**Technology:** Terraform, AWS, Azure, GCP, CloudFormation, IAM

- Related code: https://github.com/Ancordss/vault-on-aws

### 02. Kubernetes platform

Platform · SRE · Niuro · Banco Industrial Guatemala

Building and operating Kubernetes environments with automation, security and observability.

**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:**

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

**Outcome:** A shared cluster where workloads are bounded, failures are visible before users report them, and upgrades happen on a schedule rather than under pressure.

**Technology:** Kubernetes, Docker, Helm, Linux, RBAC, NetworkPolicy

- Related code: https://github.com/Ancordss/mongodb-k8s

### 03. CI/CD & automation

Delivery · Tooling · Across all engineering roles

Reducing manual operational work through automated pipelines and engineering tooling.

**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:**

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

**Outcome:** Deployments that are boring: the same steps every time, a visible history of what changed, and a rollback that is one action rather than one incident.

**Technology:** GitHub Actions, Docker, Python, Go, OIDC, Bash

- Related code: https://github.com/Ancordss/Docker_cicd

### 04. Streaming infrastructure

Media · Linux · Toolbox

Production-oriented video streaming infrastructure involving Linux, FFmpeg, packaging, networking and monitoring.

**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:**

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

**Outcome:** Media pipelines that are observable while they are running, and recoverable without a human opening a terminal at the worst possible moment.

**Technology:** Linux, FFmpeg, Docker, Networking, Monitoring, Bash

- Related code: https://github.com/Ancordss/ffmpeg

### 05. AI / MLOps

Infrastructure for machine learning · Ongoing personal work

Exploring local AI infrastructure, LLM tooling, Python automation and production-oriented AI systems.

**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:**

1. Run models and tooling locally first, on hardware I control, to understand memory, latency and cost behaviour before renting it in the cloud.
2. Treat environments as infrastructure: pinned dependencies, container images and reproducible setups instead of a working directory that only exists on one machine.
3. 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.
4. Keep the serving path conventional — containers, health checks, resource limits — because a model endpoint is still a production service.

**Outcome:** Working notes and tooling rather than claims: this is an area I am actively building depth in, applied to the same reliability standards as the rest of the stack.

**Technology:** Python, Docker, Linux, Local inference, Automation, SQL

- Related code: https://github.com/Ancordss/basic-ml-agent

## Skills

Where each technology sits in the systems I build. Grouped by engineering domain, not by logo count.

### Cloud

- **AWS** — The cloud I reach for most: compute, networking, managed data services and IAM treated as code rather than as a console session.
- **Azure** — Cloud infrastructure for teams already standardized on the Microsoft ecosystem, wired into the same pipeline and IaC conventions.
- **GCP** — Workloads where GKE and the data tooling justify the platform — provisioned declaratively like everything else.

### Platform

- **Kubernetes** — Cluster design and day-two operations: workloads, networking, storage, upgrades, RBAC and the guardrails that keep a shared cluster safe.
- **Docker** — Container images as a build artifact: minimal bases, reproducible builds, non-root by default, small enough to pull quickly.
- **Linux** — The foundation everything else sits on — systemd, networking, storage, processes, permissions, and reading logs properly under pressure.

### Infrastructure as Code

- **Terraform** — My default for provisioning: reviewed plans, small modules with real interfaces, remote state and a clear story for drift.
- **CloudFormation** — Where a stack belongs inside AWS: native change sets, stack policies and no extra state to manage.

### Programming

- **Python** — The language I automate with: operators, API clients, data pipelines, tooling, and the glue around AI/ML workloads.
- **Go** — For the things that should be one static binary: CLI tools, small services and controllers that do not need a runtime.
- **C++** — Foundational systems programming knowledge that makes performance and memory behaviour legible instead of magical.

### DevOps

- **GitHub Actions** — Delivery pipelines as code: reusable workflows, caching, least-privilege tokens and OIDC instead of long-lived cloud keys.
- **CI/CD** — Designed so a broken change fails fast and honestly, and a good one reaches production without a human babysitting it.
- **Automation** — The whole point. Anything done by hand twice becomes a script, then a pipeline, then something nobody has to think about.

### Observability

- **Monitoring** — Metrics that answer a question, with alerts tied to user-visible symptoms instead of to every CPU spike.
- **Logging** — Structured logs, retained on purpose, cheap enough to keep and searchable during the ten minutes that matter.
- **Reliability Engineering** — SLO thinking, blast-radius reduction, capacity headroom and post-incident work that actually changes the system.

### Data

- **SQL** — Relational modelling, indexing and the query plans behind a slow endpoint — plus backups and restores that have been tested.
- **NoSQL** — Document and key-value stores where access patterns matter more than normalization, operated as managed infrastructure.

## Typical operational workflow

Commands representative of the work: infrastructure changes are planned and
reviewed before they are applied, and rollouts are watched to completion.

```bash
# Plan an infrastructure change and review it as a diff
terraform plan -out=release.tfplan
# Plan: 14 to add, 2 to change, 0 to destroy.

# Follow a rollout to completion
kubectl rollout status deploy/platform-api
# deployment "platform-api" successfully rolled out

# Check the service-level objective, then the cost report
./scripts/check-slo.sh
make cost-report
```

```yaml
# Representative workload guardrails: bounded, least-privilege, observable
apiVersion: apps/v1
kind: Deployment
metadata:
  name: platform-api
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
      containers:
        - name: api
          resources:
            requests: { cpu: 250m, memory: 256Mi }
            limits: { cpu: '1', memory: 512Mi }
```

## How I think about infrastructure

These are not skills, they are constraints I design against. Each one changes the others — that tension is what makes infrastructure work.

- **Infrastructure as Code.** If it is not in the repository it does not exist. That single rule makes everything else auditable, reviewable and rebuildable after a bad day.
- **Automation.** Automation removes the human from the path where humans are least reliable: repeated steps under time pressure.
- **Observability.** You cannot operate what you cannot see. Instrumentation is part of the build, not a follow-up ticket.
- **Security.** Least privilege, short-lived credentials and a small attack surface. Defaults matter more than intentions.
- **Reliability.** Designed for the failure, not for the demo: bounded blast radius, tested restores and capacity headroom for the worst day.
- **Cost awareness.** Every architectural decision has a monthly price. Visibility turns cost from a surprise into a design input.
- **Developer experience.** Platforms are products. Fast, honest feedback and self-service paths are what make good practices actually get adopted.

## Open source

GitHub profile: https://github.com/Ancordss (43 public repositories, 95 contributions in the last year).

Selected public repositories:

- [vault-on-aws](https://github.com/Ancordss/vault-on-aws): HashiCorp Vault on AWS, deployed with Terraform.
- [ffmpeg](https://github.com/Ancordss/ffmpeg): Docker builds for FFmpeg (Ubuntu, Alpine, CentOS, Scratch, NVIDIA, VAAPI).
- [mongodb-k8s](https://github.com/Ancordss/mongodb-k8s): Running MongoDB on Kubernetes.
- [Docker_cicd](https://github.com/Ancordss/Docker_cicd): Container build and delivery practice.
- [gcp-project](https://github.com/Ancordss/gcp-project): Google Cloud infrastructure described with Terraform.

## Contact

Have an infrastructure problem worth solving?

I'm interested in building reliable platforms, automating complex systems and solving difficult infrastructure problems.

- Email: maradiaga.l.james@gmail.com
- LinkedIn: https://www.linkedin.com/in/jamesmaradiaga
- GitHub: https://github.com/Ancordss

### Topics open to discussion

- Kubernetes platform design and operations
- Infrastructure as Code at team scale
- CI/CD that engineers actually trust
- Observability and incident response
- Cloud cost reduction without losing reliability
- MLOps and AI infrastructure

## About this document

Generated from the same content modules that render the website, so it stays in sync.
Anything not verifiable from a public source is explicitly marked on the site and is
not asserted here. Architecture diagrams on the site are labelled as illustrative.

- Canonical site: https://ancordss.me.uk
- Content index for agents: https://ancordss.me.uk/llms.txt
- Sitemap: https://ancordss.me.uk/sitemap.xml