Edwin Jonathan — Engineering Platform on Edwin Jonathan — Platform, Cloud & DevOps Engineering

A Public Delivery Record

Sun, 11 Oct 2026 00:00:00 +0000

This is an independently inspectable example from my own engineering-platform repository. It is not a customer project, anonymous client case study, testimonial or claim about customer satisfaction. The evidence is public, so a technical reviewer can follow the change without receiving private client information.

1. The defect

The editorial redesign introduced article covers with remotely hosted publication images. Browser screenshots taken during the release review showed that a missing or not-yet-loaded external image could leave a visually empty dark cover. The original fallback typography existed in the design but was not always rendered under the remote image.

Consequential Execution Runtime

Sun, 11 Oct 2026 00:00:00 +0000

Why the project exists

An agent can issue individually valid requests across multiple systems while the overall outcome remains unsafe, stale or unrecoverable. Consequential Execution Runtime (CER) investigates how a runtime can bind an approval to one exact operation and make ambiguous external side effects explicit.

Implemented foundation

The public repository describes a Rust execution kernel with canonical action identity, strict JSON ingress, effect contracts, provider-aware retry decisions and explicit IN_DOUBT handling when reconciliation cannot establish an outcome.

InfraGuard

Sun, 11 Oct 2026 00:00:00 +0000

What this workstream is

InfraGuard refers here to the Security Hub remediation hardening workstream under the existing InfraGuard Agent repository, not a separate source repository or a second deployed product. The distinction matters: the Agent’s released prototype and the newer hardened AWS path have different evidence boundaries.

Problem and trust boundary

An alert is not adequate authority to change infrastructure. The proposed hardening flow validates a supported Security Hub event, independently checks live EC2 security-group rules, binds account, region and resource identity, and requires evidence that Terraform owns the resource before a proposed change can proceed.

Warden

Sun, 11 Oct 2026 00:00:00 +0000

The engineering problem

A policy violation detected by Kyverno does not automatically establish which source change is safe to make. Directly mutating a live workload can also bypass the GitOps review boundary. Warden investigates a remediation path that keeps Git as the intended authority and enforces a policy-defined ceiling on automation.

Repository-backed implementation

The public repository contains a Go controller, policy-tier classification, resource-limit patch generation, Kubernetes client dependencies and GitHub pull-request integration. The source README documents tests for the manual approval boundary and deterministic remediation. The controller’s PR integration is dry-run by default.

When an AWS inventory failure looks like Terraform drift

Sat, 10 Oct 2026 00:00:00 +0000

Infrastructure drift detection sounds straightforward: read the desired Terraform state, collect live cloud resources, and compare the two. The difficult part is establishing whether the live observation is complete enough to justify a conclusion.

I examined this problem in DriftGuard, an AWS-focused drift detection project that proposes remediation through reviewable GitHub pull requests rather than applying changes automatically. The original defect has since been addressed in merged PR #3. This article records both the failure mode and what the current source actually verifies; it is not a claim of production-scale validation.

ARCHNET

Sat, 26 Sep 2026 00:00:00 +0000

Scope

ARCHNET explores the infrastructure and delivery path for a small Kubernetes platform: AWS networking and compute, k3s bootstrap, ArgoCD reconciliation, an example workload and Prometheus alert configuration.

The repository README calls the system a production-grade zero-trust internal developer platform. The checked-in implementation does not yet justify that description, so this case study uses the narrower term platform prototype.

Implemented architecture

The repository contains Terraform for an AWS VPC, public subnet, internet gateway, route table, security group and EC2 instance; a k3s/ArgoCD bootstrap shell script; an ArgoCD Application manifest with automated prune and self-heal enabled; an nginx Deployment and ClusterIP Service; Prometheus scrape configuration and two alert rules; and a GitHub Actions workflow for structural checks and a Trivy filesystem scan.

DriftGuard

Sat, 26 Sep 2026 00:00:00 +0000

Problem

Terraform state records the infrastructure Terraform knows about. Operational changes can still happen outside the intended workflow. DriftGuard is built to compare Terraform state with live AWS state and turn detected discrepancies into reviewable engineering evidence rather than silently changing infrastructure.

System boundary

The current implementation is AWS-specific. It parses Terraform state, collects live AWS resource state, analyzes differences, maps supported findings to security context, stores scan results, and can generate a proposed HCL remediation in a GitHub pull request.

InfraGuard Agent

Sat, 26 Sep 2026 00:00:00 +0000

Scope

InfraGuard explores a constrained agentic security workflow: accept a cloud-security finding, map it to known security context, produce a proposed Terraform remediation and deliver that proposal through GitHub for human review.

The important boundary is that proposal generation and infrastructure mutation are different operations. The implementation on the main branch creates a Git branch, commits a Terraform artifact and opens a pull request; it does not call Terraform apply or directly mutate AWS resources.

Optimization Evidence

Sat, 26 Sep 2026 00:00:00 +0000

Problem

An infrastructure optimization recommendation is not the same thing as realized savings.

A Kubernetes request reduction can release schedulable capacity without removing a billable node. A lower cloud bill can also occur for reasons unrelated to an optimization. Optimization Evidence is an engineering research project built around that distinction.

The causal chain under investigation crosses the change itself, runtime capacity, billable resources, provider billing evidence and attribution. Operational safety is evaluated separately.

SENTINEL

Sat, 26 Sep 2026 00:00:00 +0000

Scope

SENTINEL is a Kubernetes security-scanning lab. Its repository contains Trivy and Kubescape scan artifacts, a scheduled GitHub Actions workflow, a small report aggregator and Terraform for local Kubernetes namespaces.

This case study deliberately uses a narrower description than the repository README. The checked-in implementation does not currently establish the full production security-platform architecture described there.

Implemented evidence

The repository contains persisted Trivy and Kubescape JSON reports. It also contains a GitHub Actions workflow that runs on pushes to the main branch and on a daily schedule.

Building Production AI Observability on Kubernetes: OpenTelemetry, Langfuse, Prometheus & Grafana From Zero to Scale

Fri, 24 Jul 2026 00:00:00 +0000

Building Production-Grade AI Observability on Kubernetes

Most AI teams are solving the wrong problem.

Everyone is benchmarking models.

Very few teams are benchmarking infrastructure.

Production failures rarely happen because GPT-5, Claude or Gemini suddenly become “less intelligent.”

They happen because nobody knows:

why latency suddenly doubled
which prompt caused hallucinations
which deployment increased token usage
why costs exploded overnight
which customer experienced degraded responses
where requests failed across twenty microservices

Why Most GitOps Migrations Fail After Six Months

Tue, 21 Jul 2026 00:00:00 +0000

The Problem

Before discussing why GitOps projects fail, it’s useful to understand the production architecture this article refers to.

Everyone talks about GitOps as if installing ArgoCD is the finish line.

It isn’t.

Most GitOps migrations succeed during the first few weeks. Deployments become automated, clusters synchronize from Git, and teams celebrate moving away from manual releases.

Then production happens.

New services appear. Different teams adopt different deployment patterns. Security requirements grow. Kubernetes versions change. Infrastructure evolves. Suddenly the Git repository that once looked clean becomes difficult to manage, deployments become slower, and engineers begin bypassing the GitOps workflow “just this once.”

Building an Agentic Operations Assistant on AWS with Amazon Bedrock and Amazon S3

Tue, 14 Jul 2026 00:00:00 +0000

Every few months, a new AI demo appears.

It writes code.
It summarizes documents.
It answers questions.

Most of those demos fail the moment they’re introduced to a real production environment.

Operations teams don’t need another chatbot.

They need a system that can answer questions using infrastructure they already trust.

CloudTrail logs.

Terraform plans.

Architecture decisions.

Incident reports.

Compliance evidence.

Runbooks.

Those documents already exist. The challenge isn’t generating text—it’s retrieving the right information without exposing data that shouldn’t leave the organization.

The Open-Source Collapse: Why AI Is Quietly Killing the People Who Built the Internet

Wed, 01 Jul 2026 00:00:00 +0000

Every time someone says AI will replace developers, I know they don’t understand where AI came from.

And honestly?

A lot of senior engineers don’t either.

The entire AI boom is standing on top of 20 years of free labor.

Millions of blog posts.

Stack Overflow answers.

GitHub repositories.

Open-source maintainers fixing bugs at 2 AM.

Random engineers writing tutorials after work because they wanted to help somebody else.

That’s the training data.

Your Terraform State Is Lying to You. I Built the Tool That Proves It.

Sun, 21 Jun 2026 00:00:00 +0000

The Quiet Failure Mode Every AWS Team Pretends Doesn’t Exist I Found the Gap Every DevOps Tool Stopped Short Of Closing Nobody Finished This Tool. So I Did

 Open your AWS console right now and compare it to your Terraform state file, line by line. I'll save you the trouble. They don't match.

Not because you did anything wrong. Because someone — you, a teammate, a contractor with console access nobody revoked — made a change outside the pipeline. A security group rule got loosened during an incident and never got tightened back. An S3 bucket lost its encryption config mid-debug. A database got flagged publicly accessible for twenty minutes of convenience and stayed that way for three months because nobody was watching.

Junior Engineers Are Learning AI Faster Than They Are Learning Systems

Thu, 18 Jun 2026 00:00:00 +0000

The most important engineering gap nobody seems interested in talking about

A few months ago, I noticed something strange.

Everywhere I looked, people were learning AI.

People were building agents. People were generating code. People were creating AI startups. People were posting AI projects.

Yet when basic infrastructure questions appeared, many of the same people struggled.

Questions about networking.

Questions about Linux.

Questions about containers.

Questions about DNS.

Questions about how applications actually move from a laptop to production.

DRIFTGUARD

Thu, 11 Jun 2026 00:00:00 +0000

Hey DEV.to 👋

I’m Edwin, a self-taught Cloud & DevOps Engineer from Lagos, Nigeria.

I built DriftGuard because I kept watching the same thing happen: engineers write perfect Terraform, apply it, and then someone clicks around in the AWS console three weeks later. Security group opened. S3 encryption disabled. RDS made publicly accessible. Nobody knows until something breaks or gets breached.

Driftctl is abandoned. Checkov only scans. Infracost only costs. Nothing combined all three with auto-remediation.

Deployment Isn't the Hard Part. Recovery Is.

Fri, 05 Jun 2026 00:00:00 +0000

When I first started learning DevOps, I thought deployment was the destination.

Build the application.

Push the code.

Deploy to production.

Repeat.

Simple.

At least that’s what most tutorials make it look like.

The deeper I went into cloud engineering, the more I realized that production systems don’t care how beautiful your CI/CD pipeline is.

Production only cares about one thing:

Can the system survive when something goes wrong?

That question completely changed how I think about engineering.

The Day I Realized Backups Aren't Disaster Recovery: Lessons From Building an AWS Recovery Strategy

Wed, 03 Jun 2026 00:00:00 +0000

One of the biggest misconceptions in cloud engineering is believing that backups automatically mean you’re prepared for a disaster.

I used to think the same thing.

As long as snapshots existed, backups were running, and databases were stored somewhere safe, everything felt secure.

Then I worked on a disaster recovery project.

And I learned very quickly that recovery is a completely different problem from backup.

A backup answers:

“Can we restore the data?”

I’m 17, Building in Cloud & DevOps From Nigeria — and No, My Journey Isn’t “AI Generated”

Sat, 30 May 2026 00:00:00 +0000

People assume my work is fake because they cannot imagine someone my age writing with this level of clarity, structure, and technical direction. This is the truth behind my journey.

There’s something strange happening in tech culture lately.

The moment a young person sounds too polished, too intentional, or too technically aware, people immediately assume it’s fake.

“AI wrote this.”

“This experience isn’t real.”

“He’s just posting motivational content.”

“He’s too young to actually understand DevOps.”

Why Most “Senior” DevOps Engineers Are Building Fragile Infrastructure — And Why the Industry Rewards It

Sat, 23 May 2026 00:00:00 +0000

For years, the tech industry has sold an illusion.

The illusion is that more tools automatically mean better engineering.

More Kubernetes operators. More CI/CD layers. More observability stacks. More Terraform modules. More dashboards. More YAML. More abstraction.

And somewhere in the middle of this chaos, the industry quietly stopped valuing one thing:

Infrastructure that actually survives pressure.

Modern DevOps culture has become dangerously addicted to complexity disguised as innovation.

A shocking number of “production-grade” systems today are nothing more than fragile towers of automation held together by copied GitHub repositories, AI-generated scripts, and engineers who have never experienced real infrastructure failure under pressure.

IAM Least Privilege in Practice — What Most Tutorials Get Wrong

Sun, 17 May 2026 00:00:00 +0000

Introduction

Every AWS tutorial tells you to use least privilege. Almost none of them show you what it actually looks like. Most examples online attach AdministratorAccess to a role “for simplicity” and move on.

That’s not simplicity. That’s a breach waiting to happen. Here’s what real IAM discipline looks like.

The Most Common Mistakes

Mistake 1 — Wildcard actions on wildcard resources

{
 "Effect": "Allow",
 "Action": "*",
 "Resource": "*"
}

This is AdministratorAccess. Never use it outside break-glass emergency scenarios.

How I Secured an ECS Fargate Deployment With OIDC and ECR — No Static Keys

Sat, 16 May 2026 00:00:00 +0000

Introduction

Most AWS CI/CD tutorials hand you a AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY and call it a day. That’s a security failure waiting to happen. Static keys get leaked in logs, committed to repos, and rotated too late.

I built a full deployment pipeline for a real DevOps challenge — GitHub Actions → ECR → ECS Fargate — with zero static credentials. Here’s exactly how.

The Problem With Static Keys

When you store AWS credentials as GitHub secrets and reference them in your pipeline, you’re creating long-lived credentials that:

AI Agents in DevOps: Building Autonomous Cloud Infrastructure That Operates Itself

Sun, 10 May 2026 00:00:00 +0000

The traditional DevOps pipeline is breaking under modern infrastructure scale.

Cloud environments have become too dynamic for human-centered operations alone. Containers spin up and disappear in seconds. Multi-cloud systems generate terabytes of telemetry daily. Incidents cascade faster than engineers can respond manually.

Most teams are still operating infrastructure reactively:Humans investigate alerts

**.**Humans scale workloads

.Humans restart failed services

**.**Humans patch vulnerabilities

**.**Humans approve repetitive deployments

**.**Humans correlate logs during outages

Securing AWS deployments with GitHub Actions OIDC — a production walkthrough

Fri, 08 May 2026 00:00:00 +0000

The Problem Nobody Talks About Enough

Every tutorial shows you how to deploy to AWS from GitHub Actions using `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` stored as repository secrets.

That is a liability. Static keys don’t expire. If your repo is compromised, your AWS account goes with it. If a team member leaves and you forget to rotate, the key still works. At scale, this becomes a ticking clock.

The production answer is OIDC — and most engineers using it don’t fully understand how the trust chain works. This article fixes that.

AI Agents in DevOps Engineering: The Death of Manual Operations Has Already Started

Thu, 07 May 2026 00:00:00 +0000

Most engineers still think AI in DevOps means “Copilot autocomplete.”

That is beginner-level thinking.

The real shift is happening deeper in infrastructure, incident response, platform engineering, observability, CI/CD orchestration, and autonomous operations.

We are entering the era of Agentic DevOps — where AI systems do not just assist engineers, but actively reason, execute, recover, optimize, and coordinate infrastructure operations across cloud environments.

The engineers who understand this transition early will dominate the next decade of infrastructure engineering.

How I Used OIDC to Eliminate Static AWS Keys from GitHub Actions (Real Pipeline Walkthrough)

Wed, 06 May 2026 00:00:00 +0000

Static AWS access keys in GitHub Actions secrets is how production environments get breached.

Here’s how I replaced every static key with OIDC federation for the Damolak Technologies DevOps challenge — and why you should too.

The Problem With Static Keys

When you do this: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} You have a long-lived credential sitting in GitHub that:

Never rotates automatically
Has blast radius if the repo is compromised
Violates least-privilege by existing at all

The Fix: OIDC

I Built a Production-Grade Internal Developer Platform at 17 — Full Architecture

Sun, 03 May 2026 00:00:00 +0000

The Problem

Most engineers deploy to Kubernetes by clicking buttons in a UI. That’s not DevOps. That’s manual labor with extra steps.

I built Archnet — a fully automated Internal Developer Platform that handles deployments, secrets, observability, and self-healing with zero human intervention after setup.

What is an Internal Developer Platform?

An IDP is the infrastructure layer that sits between your code and your cloud. It handles:

How code gets deployed
How secrets are managed
How the system monitors itself
How failures get detected and fixed

Most companies pay Humanitec or Backstage $50k+/month for this. I built it from scratch.

How I Built a Production GitOps Pipeline on AWS at 17 — K3s + ArgoCD + GitHub Actions from Scratch

Mon, 27 Apr 2026 00:00:00 +0000

-–

The Problem With “Learning” DevOps

Most people learning DevOps are watching tutorials, copying commands they don’t understand, and calling it experience.

I decided to build instead.

This is the exact breakdown of how I built **DevShelf** — a real Internal Developer Platform running on AWS with a full GitOps CI/CD pipeline. No shortcuts. No cloud sandboxes. Real infrastructure, real AWS costs, real engineering decisions.

-–

What is GitOps and Why It Matters

GitOps is a deployment model where your Git repository is the single source of truth for infrastructure state. You don’t manually deploy. You push code, and the system reconciles itself to match what’s in Git.