DEV Community: Edwin Jonathan

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

Edwin Jonathan — Sun, 21 Jun 2026 17:14:46 +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.

Terraform doesn't know any of this happened. It still believes the world looks like what you declared. The gap between that belief and reality is called drift, and it is the quietest liability in cloud infrastructure — not because it's rare, but because nothing alerts on it. It doesn't throw an error. It waits for an audit, or an attacker, whichever comes first.

I went looking for the tool that closes that gap properly. I found pieces of one, scattered across three dead-ends.

Driftctl detected drift competently — until Snyk acquired it, extracted whatever value they wanted, and let the repository go silent. No commits in over a year, still recommended on every "top drift detection tools" roundup that nobody bothered to update. Checkov scans your Terraform code before you apply it, which is useful and also irrelevant to what's already running in production. Infracost will price a resource down to the cent and say nothing about the fact that the resource shouldn't be publicly exposed in the first place.

Three tools, three lanes, none of them talking to each other. Nobody had built the version that watches your real infrastructure, tells you precisely how dangerous a discrepancy is using frameworks security teams actually trust, prices what it's costing you, and hands you the fix instead of a report you'll skim once and forget.

So I built it. DriftGuard is live, it's running against real AWS accounts, and it doesn't soften what it finds.

What It Does, Without the Marketing Language
DriftGuard reads your terraform.tfstate and queries your live AWS account directly — EC2, security groups, S3, RDS, IAM — and checks whether the two still agree.

When they don't, it doesn't hand you a raw diff and call it done. Every discrepancy runs through a rules engine mapped to CIS AWS Benchmark controls and MITRE ATT&CK technique IDs. A security group that opened SSH to the entire internet isn't logged as "rule modified." It's flagged as a direct CIS 4.1 violation, tied to the exact attack technique it enables, and weighted with a severity that makes it impossible to quietly skip in a backlog review.

It also does the arithmetic nobody else runs. An EC2 instance quietly bumped from t3.micro to t3.large isn't just a config change — it's an unapproved $53 a month, compounding silently across however many times that pattern repeats across your fleet before finance notices the bill moved.

Then it closes the loop entirely. DriftGuard writes the exact Terraform HCL needed to restore the declared state, commits it to a branch, and opens a pull request on your repository with the severity, the specific compliance violation, the cost impact, and the fix sitting together in one place. You don't investigate. You review and merge.

That's the entire premise: stop generating reports nobody reads, and start generating fixes someone can act on in under a minute.

What Actually Happened Behind the Scenes
I won't pretend this was a clean build, because the clean version of any engineering story is usually the fictional one.

The core engine — parsing state, pulling live AWS data through boto3, diffing the two, scoring severity against compliance frameworks — came together quickly. That part is just structured logic: compare, flag, weight, output. Algorithms cooperate. Infrastructure doesn't.

Deployment is where I actually got tested.

Railway rejected the first build outright: "railpack could not determine how to build the app." No requirements.txt in the path it expected, no signal telling it what kind of project this even was. I fixed it. It failed again on a different missing piece. By the time I got a deployment that actually held, I'd burned through my entire Railway trial — watched the credits disappear before I'd shipped anything real, which is its own particular kind of frustrating.

I moved to Render. Free tier, no countdown clock. First build failed there too — a pydantic-core metadata error, because I'd pinned exact dependency versions with no prebuilt wheel for the Python runtime underneath. I stripped every version pin, let pip resolve compatible versions on its own, redeployed, and watched the logs finally turn green.

That sequence — dead platform, burned credits, stripped config, second platform, second failure, fix, green build — is the actual build log. Not a straight line. A series of corrections until something held. That's what shipping looks like, regardless of who's doing the shipping or how old they are.

On the Matter of My Age
I'm seventeen. I don't have a degree, and I stopped waiting for one to certify what I already knew how to do. Linux, Docker, Kubernetes, Terraform, AWS — learned from documentation and broken builds, the way most of this industry actually gets learned, with no cohort and no professor softening the parts that didn't make sense the first time.

Before DriftGuard, I'd already built a Zero-Trust Kubernetes platform end to end. I'd already shipped a security posture engine scoring live clusters against MITRE ATT&CK using real scan data, not staged examples. I'd already stood up AWS pipelines authenticated entirely through OIDC — zero static credentials anywhere in the chain, the way the documentation says it should be done and the way most teams still aren't doing it.

DriftGuard is the first project I'm putting directly in front of an industry that hasn't had a reason to look yet. It solves a problem real infrastructure teams actually have. Test it against your own AWS account. Try to break it. File an issue — I read every one, and I close them fast, because a maintainer who goes quiet is the fastest way to lose trust in a tool.

Live API: https://driftguard-endm.onrender.com/docs
GitHub: https://github.com/EdwinJdevops/driftguard

Closing
I didn't write this to introduce myself. The repository is public, the API is live, and the commit history will tell you more about how I work than any paragraph here could.

What I'll say instead is this: most people wait for permission before they consider themselves ready. A title, a degree, an interview that grants them the right to call their work serious. I skipped that part. I built the tool, deployed it, broke it, fixed it, and put it where anyone can verify every claim I just made.

The work is the introduction. Everything else is just confirmation.

I'm Edwin Jonathan — a 17-year-old self-taught DevOps Engineer building from Lagos, Nigeria. No degree, no shortcuts — just real infrastructure, real pipelines, and real results. Follow the journey: 🔗 GitHub: github.com/EdwinJdevops ✍️ Hashnode: edwinjonathand-devops.hashnode.dev 💼 Open to remote DevOps/Cloud roles globally

Junior Engineers Are Learning AI Faster Than They Are Learning Systems

Edwin Jonathan — Thu, 18 Jun 2026 16:11:47 +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.

The more I observed, the more I realized this might become one of the biggest engineering gaps of the next decade.

We are producing people who can use intelligence without understanding the systems that deliver it.

That is not necessarily their fault.

The industry is rewarding AI skills aggressively.

A teenager can build something impressive with modern AI tools in a weekend.

A startup can launch faster than ever.

A founder can prototype an idea without hiring a team.

The barrier to building software has dropped dramatically.

But there is a hidden problem.

The easier software becomes to create, the easier it becomes to ignore the foundations underneath it.

Nobody notices networking until production breaks.

Nobody cares about DNS until customers cannot access the application.

Nobody thinks about observability until incidents start costing money.

Nobody thinks about infrastructure until infrastructure becomes the bottleneck.

For years, engineering careers followed a predictable path.

People learned operating systems.

Then networking.

Then servers.

Then automation.

Then cloud.

Then architecture.

Today, many people are entering through AI.

That is not bad.

What concerns me is when AI becomes the entire foundation rather than another layer on top of it.

An engineer who understands systems can learn AI.

An engineer who only understands AI may eventually struggle to understand systems.

Those are very different positions to be in.

I think this creates an unusual opportunity.

While thousands of people are racing toward the newest AI framework, there is a smaller group quietly developing deeper infrastructure knowledge.

They are learning Linux.

They are learning Kubernetes.

They are learning cloud architecture.

They are learning reliability engineering.

They are learning how large-scale systems actually behave.

Ironically, these skills may become more valuable as AI adoption increases.

Because every AI application still runs somewhere.

Every AI service still depends on infrastructure.

Every AI platform still needs security.

Every AI product still needs monitoring.

Every AI company still needs engineers who understand systems.

The future probably does not belong to engineers who reject AI.

It also probably does not belong to engineers who depend entirely on AI.

The future belongs to engineers who understand both.

People who can build with AI while still understanding what happens underneath the interface.

As a 17-year-old cloud and DevOps engineer, this is one reason I continue spending time learning infrastructure fundamentals.

Not because they are trendy.

Not because they generate viral posts.

But because every major technology shift in history eventually rewards people who understand the layers beneath the excitement.

AI may be changing software.

But systems still run the world.

And right now, I think too many future engineers are forgetting that.

Maybe I am wrong.

Maybe AI will abstract away most of the complexity.

Maybe future engineers will never need to understand networking, Linux, infrastructure, or distributed systems at a deep level.

But history suggests otherwise.

Every major technology shift creates a rush toward new tools and new opportunities. Yet the people who create lasting careers are usually the ones who understand what exists beneath the surface.

Today, everyone is racing toward AI.

I am paying attention to AI too.

But I am also learning Linux, cloud architecture, containers, automation, observability, and distributed systems.

Because when the hype cycle moves on, the fundamentals remain.

And when production breaks at 3 AM, infrastructure still matters.

I am 17 years old, building from Lagos, Nigeria.

I do not have decades of experience.

I do not have a large engineering team behind me.

What I do have is curiosity, access to knowledge, and a belief that world-class engineering talent can emerge from anywhere.

The real question is not whether AI will replace engineers.

The real question is whether future engineers will still understand the systems that AI depends on.

The next generation of engineers should not have to choose between AI and systems.

They should master both.

Because the engineers who understand intelligence and infrastructure at the same time may end up building the future everyone else talks about.

DRIFTGUARD

Edwin Jonathan — Thu, 11 Jun 2026 15:11:36 +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.

So I built it.

DriftGuard detects drift, scores it against CIS AWS
Benchmarks and MITRE ATT&CK, calculates the monthly cost
delta, and opens a GitHub PR with the exact Terraform HCL
fix — automatically.

Live API: https://driftguard-endm.onrender.com/docs
GitHub: github.com/EdwinJdevops/driftguard

No VC funding. No team. Built in Lagos.
Brutal feedback welcome — that's why I'm here.

Deployment Isn't the Hard Part. Recovery Is.

Edwin Jonathan — Fri, 05 Jun 2026 13:30:31 +0000

Deployment Isn't the Hard Part. Recovery Is.

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 Problem With Most Learning Paths

Most people learning DevOps spend countless hours understanding deployment.

How to automate builds.

How to create pipelines.

How to deploy containers.

How to provision infrastructure.

All of those things matter.

But very few conversations focus on what happens after deployment.

What happens if a release introduces a bug?

What happens if a database migration fails?

What happens if a configuration change breaks production?

What happens if users start seeing errors five minutes after a successful deployment?

The reality is that deployment is only the beginning of the story.

The real story starts when systems encounter failure.

A Deployment Pipeline Is Not a Reliability Strategy

One lesson that stood out to me is that a successful deployment doesn't automatically mean a successful release.

Code can reach production perfectly and still create problems.

I've seen examples where:

Deployments completed successfully.
Infrastructure passed validation.
Monitoring showed healthy services.

Yet users still experienced issues.

That's because reliability is bigger than deployment.

Reliable systems require:

Observability
Monitoring
Rollback strategies
Feature flags
Incident response procedures
Recovery planning

Without those pieces, a deployment pipeline is simply moving risk faster.

The Question That Changed My Perspective

Whenever I look at an architecture now, I ask a different question.

Not:

"How do we deploy this?"

But:

"What happens at 2 AM if this breaks?"

That single question exposes weaknesses very quickly.

Suddenly you're thinking about:

Can we roll back safely?

Do we know when something fails?

How quickly can we recover?

Will customers notice?

Do we have enough visibility to investigate the issue?

The answers to those questions often matter more than the deployment itself.

Why Observability Matters

One of the most underrated parts of modern engineering is observability.

Many teams invest heavily in deployment automation.

Far fewer invest the same energy into understanding system behavior.

Metrics tell you what happened.

Logs tell you where it happened.

Tracing helps explain why it happened.

Without visibility, troubleshooting becomes guesswork.

And guesswork becomes expensive when production is involved.

The best engineers I've learned from don't just build systems.

They build systems they can understand.

Recovery Is a Feature

As engineers, we often think about features from a user perspective.

New dashboard.

New API.

New functionality.

But some of the most valuable features are invisible.

Rollback mechanisms.

Automated backups.

Disaster recovery plans.

Health checks.

Incident runbooks.

Users rarely see these things.

But they benefit from them every day.

Because when failure occurs, those systems quietly protect the experience.

What I'm Learning as a Young Engineer

Being 17 and learning DevOps has given me an interesting perspective.

The more I learn, the less I believe engineering is about knowing every tool.

Tools change.

Platforms evolve.

Technologies come and go.

The principles remain.

Reliability.

Resilience.

Recovery.

Observability.

Those concepts will still matter long after today's tools are replaced by tomorrow's tools.

And that realization has probably been one of the most valuable lessons in my journey so far.

Closing Thoughts

I'm a 17-year-old DevOps and Cloud Engineer building from Lagos, Nigeria.

I don't have decades of experience.

I don't have stories from hundreds of production incidents.

But every project, every deployment, every architecture diagram, and every lesson learned reinforces the same idea:

Engineering isn't measured by how often things work.

It's measured by how teams respond when things don't.

The engineers I admire most aren't the ones who never encounter failure.

They're the ones who design systems with failure in mind and build the discipline to recover quickly when it arrives.

So while many people focus on shipping faster, I'm learning to focus on something different:

Building systems that remain trustworthy when things go wrong.

Because in the end, the goal isn't simply to deploy.

The goal is to build with enough care, enough foresight, and enough responsibility that when failure eventually appears—as it always does—we're ready for it.

And that's the kind of engineer I'm working to become.

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

Edwin Jonathan — Wed, 03 Jun 2026 15:51:43 +0000

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

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?"

Disaster recovery answers:

"Can the business survive the outage?"

Those are not the same question.

The Challenge

The environment contained critical workloads that depended heavily on database availability.

The concern wasn't only data loss.

The real concern was operational downtime.

What happens if an AWS Region experiences an outage?

What happens if a database becomes corrupted?

What happens if someone accidentally deletes production data?

What happens if backups exist but recovery takes several hours?

Those questions completely changed how I approached the project.

The focus shifted from storage to resilience.

The First Reality Check

One lesson became obvious almost immediately:

Everyone talks about backups.

Very few people talk about recovery objectives.

Before designing anything, I had to understand two critical metrics:

Recovery Time Objective (RTO)

How quickly must systems recover?

Recovery Point Objective (RPO)

How much data loss is acceptable?

At first these sounded like business terms.

In reality they became engineering constraints that influenced every architectural decision.

A recovery requirement of fifteen minutes creates a completely different architecture from a recovery requirement of four hours.

The infrastructure must reflect those expectations.

Database Resilience Is More Complex Than It Looks

The project involved evaluating how databases could remain available during unexpected failures.

The assumption was simple:

"If the database fails, restore it."

The reality was much more complicated.

Database recovery introduces challenges such as:

Replication lag
Data consistency
Failover timing
Connection management
Recovery validation
Application dependencies

A database can technically recover while the application remains completely unusable.

That distinction matters.

Engineering success isn't measured by whether the database comes online.

It's measured by whether users can continue using the platform.

The AWS Services That Changed My Thinking

Several AWS services became central to the strategy.

Amazon RDS automated much of the operational burden associated with database management.

Multi-AZ deployments improved availability by maintaining standby infrastructure.

AWS Backup introduced centralized backup governance.

Amazon CloudWatch provided visibility into operational health.

What stood out wasn't the services themselves.

It was how they worked together.

Cloud engineering is rarely about individual tools.

It's about building systems where multiple services cooperate under failure conditions.

The Problem Nobody Talks About

The hardest part of disaster recovery isn't creating backups.

The hardest part is testing recovery.

Many organizations confidently claim they have disaster recovery plans.

Very few execute them regularly.

A recovery plan that has never been tested is closer to a theory than a strategy.

During the project, one of the most valuable exercises was validating assumptions.

Would the recovery process actually work?

Would access controls still function?

Would applications reconnect correctly?

Would dependencies fail unexpectedly?

These questions revealed weaknesses that documentation alone could never expose.

What Failure Taught Me

The project wasn't perfect.

Several assumptions turned out to be incorrect.

Some recovery procedures took longer than expected.

Certain dependencies behaved differently under simulated failure conditions.

But those moments became the most valuable learning experiences.

Cloud engineering isn't about avoiding failure.

It's about understanding failure before it happens.

The best engineers don't simply build systems.

They design for the day those systems break.

What This Experience Changed For Me

Before this project, I viewed cloud infrastructure primarily through the lens of deployment and scalability.

Afterward, I started viewing infrastructure through the lens of resilience.

Anyone can build a system that works.

Exceptional engineers build systems that continue working when things go wrong.

That mindset shift changed how I think about architecture, automation, observability, and operational excellence.

Final Thoughts

As a 17-year-old building a career in DevOps and Cloud Engineering, this project reinforced something important:

Technology isn't tested on good days.

Technology is tested on bad days.

The true measure of infrastructure isn't how it performs during normal operations.

It's how quickly, safely, and reliably it recovers when the unexpected happens.

And if there's one lesson I'll carry forward from this experience, it's this:

Backups create confidence.

Disaster recovery creates resilience.

The difference between those two concepts is where some of the most important engineering decisions are made.

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

Edwin Jonathan — Sat, 30 May 2026 09:31:53 +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.

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

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.”

I’ve heard all of it.

And honestly, I understand why people think that way.

The internet is flooded with fake builders, fake founders, fake engineers, fake screenshots, fake lifestyles, and AI-generated expertise. Everyone wants to look senior before they’ve actually built anything meaningful.

So when people see a 17-year-old from Nigeria talking seriously about Cloud Engineering, Infrastructure, DevOps culture, automation, systems thinking, and modern engineering problems, their first instinct is skepticism.

Not curiosity.

Skepticism.

But here’s the part people don’t see.

I didn’t randomly wake up one day and decide to “become a tech influencer.”

I grew up around technology.

Not the aesthetic version of tech.
The real version.

My parents are certified AWS developers.
My siblings work in cybersecurity.
Technical conversations existed around me long before I understood what DevOps even meant.

While some people discovered cloud computing through trends on social media, I was already exposed to engineering environments early. I was watching how technical professionals think, communicate, solve problems, and approach systems.

That exposure changes you.

It changes how you write.
It changes how you think.
It changes how early you begin understanding technical concepts.

People assume age automatically determines technical awareness.

It doesn’t.

Environment matters.
Exposure matters.
Consistency matters.

And most importantly: obsession matters.

I’ve wanted to become a developer since I was young.
Not because it looked cool online.
Because I genuinely loved technology.

What people call “too polished” is actually years of observation, curiosity, and immersion.

Now let me clear something else up.

Being young in tech is not some magical advantage.

In many ways, it’s a disadvantage.

People rarely take you seriously.
Recruiters assume you’re inexperienced before speaking to you.
Some professionals automatically dismiss your opinions because of your age.
And when your communication is strong, they assume AI is carrying you.

Ironically, if my writing was worse, people would probably believe me more.

But I refuse to intentionally sound smaller just to make people comfortable.

I take writing seriously because communication is part of engineering.

A lot of engineers underestimate this.

You can be technically skilled and still become invisible because you cannot communicate clearly.

Documentation matters.
Architecture discussions matter.
Writing matters.
Technical storytelling matters.

The best engineers are not just builders.
They are translators of complexity.

That’s something I’m intentionally developing early.

And no, that doesn’t mean I know everything.

Far from it.

I’m still learning.
Still studying.
Still building.
Still failing.
Still figuring things out one step at a time.

I am not a “senior engineer.”
I don’t pretend to be one.

What I am is focused.

I spend time studying cloud infrastructure, DevOps workflows, automation culture, system reliability, CI/CD concepts, and engineering communication because I genuinely care about this path.

Not for clout.
Not for aesthetics.
Not because “tech is paying.”

Because I want to become exceptional.

There’s also a deeper issue underneath all this.

A lot of people are uncomfortable seeing young Africans think globally.

Especially when the presentation doesn’t match the stereotype they expect.

People are used to seeing teenagers online joke around, chase trends, or seek attention.

So when someone from a Nigerian background starts discussing infrastructure resilience, engineering culture, cloud systems, and technical growth with seriousness, it breaks the mental model they already had.

And when people cannot explain something quickly, they often dismiss it.

But none of that changes reality.

I know where I’m starting from.
I know what I’m building toward.
And I know this journey is real.

Not perfected.
Not finished.
Real.

I’m still at the beginning.

But beginnings matter.

One thing I’ve learned already is this:

The tech industry respects visible execution over explanations.

So instead of arguing endlessly with doubters, I’d rather continue building.

Continue learning.
Continue writing.
Continue improving.
Continue documenting the process honestly.

Because over time, consistency exposes what is real.

Not noise.
Not hype.
Not performance.

Consistency.

And maybe this article isn’t even about defending myself.

Maybe it’s about documenting a reality many young builders experience but rarely talk about openly.

Being underestimated.
Being doubted.
Being questioned before being understood.

Especially when you are young.
Especially when you are African.
Especially when your ambition sounds “too big” for your environment.

But ambition is not delusion.

Sometimes it is simply vision arriving earlier than validation.

And for anyone young, overlooked, underestimated, or constantly accused of “trying too hard” because they care deeply about their future:

Keep building anyway.

One day the same things people mocked will become the exact reasons they respect you.

And when that day comes, let your work speak louder than your frustration ever did.
I am not writing this as a senior engineer.

I am writing this as a 17-year-old Nigerian building toward that future every single day.

I do not have decades of experience.
I do not have a long list of enterprise projects behind my name.
And I do not claim to have all the answers.

What I do have is curiosity, discipline, access to an environment that exposed me to technology early, and a commitment to keep learning long after the excitement fades.

The goal was never to impress people with my age.

The goal was always to become the kind of engineer whose work, thinking, and consistency speak for themselves.

If there is one thing I hope people take away from this article, it is that potential should never be measured only by age, location, or background.

Great engineers are not built overnight.

They are built through years of learning, failing, improving, and showing up when nobody is watching.

This is only the beginning of my journey.

And years from now, when I look back at this article, I hope it serves as proof that every accomplished engineer once started as a beginner with a vision that others could not yet see.

Until then, I'll keep learning, keep building, and keep earning every opportunity that comes my way.

One system.
One project.
One lesson at a time.
I'm Edwin Jonathan — a 17-year-old self-taught DevOps Engineer building from Lagos, Nigeria. No degree, no shortcuts — just real infrastructure, real pipelines, and real results. Follow the journey: 🔗 GitHub: github.com/EdwinJdevops ✍️ Hashnode: edwinjonathand-devops.hashnode.dev 💼 Open to remote DevOps/Cloud roles globally

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

Edwin Jonathan — Sat, 23 May 2026 09:30:23 +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.

And the uncomfortable truth is this:

The industry rewards it.

Tech companies reward engineers for shipping fast, not for building systems that survive long-term operational stress.

Recruiters reward keyword stacking over systems thinking.

Startups reward velocity over resilience.

Cloud providers reward increased consumption, not simplicity.

The result?

An entire generation of infrastructure engineers building systems they themselves cannot manually recover if automation fails.

That is not engineering.

That is dependency.

And eventually, dependency becomes fragility.

The Kubernetes Illusion

Kubernetes is one of the greatest engineering platforms ever built.

It is also one of the most abused.

Thousands of engineers deploy Kubernetes clusters they do not fully understand because the industry convinced them that using Kubernetes automatically makes infrastructure “advanced.”

It does not.

A badly engineered Kubernetes cluster is infinitely more dangerous than a well-designed VM architecture.

But saying this publicly almost feels illegal in DevOps spaces.

Why?

Because modern engineering culture is heavily tied to optics.

Companies want to appear “cloud-native.”

Engineers want to appear “senior.”

Recruiters want resumes filled with buzzwords.

So organizations deploy infrastructure complexity they do not operationally deserve yet.

Then incidents happen.

Then engineers panic.

Then Slack channels explode.

Then companies realize their infrastructure documentation was never truly written.

Then they discover their production environment depends on one engineer who just resigned.

This is happening far more often than the industry admits publicly.

The Real Skill Gap Nobody Talks About

The biggest gap in DevOps is not Kubernetes.

It is operational maturity.

Most engineers today know how to deploy.

Far fewer know how to recover.

And recovery is the true test of engineering.

Can you restore production manually if CI/CD dies?

Can you recover infrastructure if Terraform state becomes corrupted?

Can you operate during DNS failure?

Can your monitoring survive partial outages?

Can your systems degrade gracefully instead of collapsing entirely?

Most companies never test these scenarios seriously.

Because resilience engineering is not glamorous on LinkedIn.

Failure testing does not go viral.

But during real incidents, none of the fancy dashboards matter.

Only architecture quality matters.

The AI Problem Nobody Wants to Say Out Loud

AI is making junior engineers faster.

But it is also making weak engineers look temporarily competent.

This is creating a dangerous new category inside tech:

Engineers who can generate infrastructure, but cannot reason about infrastructure.

There is a massive difference.

The future elite engineers will not be the people who generate the most YAML with AI.

They will be the engineers who understand systems deeply enough to detect when AI-generated infrastructure is architecturally dangerous.

Because AI can produce syntactically correct disaster at scale.

And many companies are already merging generated configurations into production environments with minimal review.

That should concern everyone.

What Actually Makes an Elite Infrastructure Engineer

**
Not certificates.

Not buzzwords.

Not posting “Day 47 of Learning Kubernetes.”

Not collecting tools like Pokémon cards.

Elite engineers think differently.

They optimize for:

Survivability
Simplicity
Recovery
Operational clarity
Failure containment
Observability with purpose
Low cognitive load
Long-term maintainability

The best infrastructures often look deceptively simple.

Because true engineering maturity removes unnecessary complexity.

Immature engineering adds complexity to appear intelligent.

Senior engineering removes it.

What Young Engineers Should Understand Early

The industry will constantly pressure you to perform intelligence instead of building competence.

Resist that pressure.

Do not become addicted to surface-level engineering.

Most people are chasing titles.
Very few are studying systems deeply.

If you truly want to stand out globally as an engineer:

Study failures.

Study outages.

Study architecture tradeoffs.

Study why systems collapse.

Study why recovery processes fail.

Study why supposedly “highly available” systems still go down.

That knowledge separates infrastructure operators from infrastructure engineers.

My Own Shift in Thinking

At 17, I started realizing something uncomfortable:

Many infrastructures online looked impressive visually but weak operationally.

Beautiful dashboards.
Terrible resilience.

Massive cloud bills.
Poor architecture decisions.

Complex pipelines.
Weak recovery strategy.

So I stopped obsessing over looking advanced.

I started obsessing over understanding systems pressure.

That mindset changed how I approached automation, cloud engineering, security tooling, Kubernetes, and infrastructure design.

I became less interested in “more tooling.”

And more interested in:

“What happens when everything fails?”

**
That single question changes how you engineer permanently.
**

Final Thought

**
The next generation of elite DevOps engineers will not win because they know the most tools.

They will win because they understand infrastructure deeply enough to reduce fragility in an industry addicted to complexity.

And when the industry finally realizes that reliability matters more than hype, a lot of “senior” engineers are going to look extremely unprepared.

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

Edwin Jonathan — Wed, 06 May 2026 11:45:58 +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

GitHub Actions supports OIDC token exchange with AWS.
Your pipeline requests a short-lived token. AWS validates it
against a trust policy. No stored credentials.

Step 1 — IAM OIDC Provider


hcl
resource "aws_iam_openid_connect_provider" "github" {
  url             = "https://token.actions.githubusercontent.com"
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]
}

Step 2 — Trust Policy (scoped to YOUR repo):
{
  "Condition": {
    "StringLike": {
      "token.actions.githubusercontent.com:sub": 
        "repo:EdwinJdevops/damolak-challenge:ref:refs/heads/main"
    }
  }
}

This means ONLY your main branch can assume this role.
A fork cannot. A PR branch cannot. Exact scope.

Step 3 — GitHub Actions Workflow
permissions:
  id-token: write
  contents: read

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::ACCOUNT_ID:role/github-actions-role
    aws-region: us-east-1
That's it. No secrets stored. Token lives for 15 minutes.

**The Full Pipeline I Shipped
**
OIDC auth → ECR login → Docker build + push →
ECS Fargate rolling deploy → ALB health check
33 AWS resources provisioned by Terraform.
Live endpoint behind ALB.
Zero static credentials anywhere in the stack.
Full repo: github.com/EdwinJdevops/damolak-challenge.

Connect:https://hashnode.com/@jonathandevops
Connect:https://www.linkedin.com/in/edwin-jonathan-1094093b0
Connect:https://x.com/TheCloudDeveng

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

Edwin Jonathan — Sun, 03 May 2026 15:23:10 +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.

The Architecture:

Developer pushes code to GitHub
↓
GitHub Actions builds + scans the image
↓
Docker image pushed to registry
↓
ArgoCD detects manifest change in Git
↓
ArgoCD syncs to k3s Kubernetes cluster
↓
Prometheus scrapes metrics from all pods
↓
Grafana visualizes — AlertManager fires on anomalies
↓
Loki aggregates all logs

Tech Stack & Why

k3s over kubeadm
Single binary. Boots in under 5 minutes.
Full Kubernetes API. Production-proven by Rancher.

ArgoCD over Flux
Better UI for drift visibility. Multi-cluster support.
Stronger RBAC controls. Built-in auto-remediation.

Sealed-Secrets over HashiCorp Vault
No external dependencies. Secrets live encrypted in Git.
Only the cluster can decrypt. Zero operational overhead.

Prometheus + Grafana over Datadog
Full data ownership. No per-host billing.
Custom retention. Industry standard.

GitHub Actions over Jenkins
No server to maintain. Native Git integration.
YAML pipelines. Free for public repos.

The GitOps Model

Everything is declarative. No imperative commands in production.

You commit a change to Git
ArgoCD detects the drift between Git and cluster state
ArgoCD automatically syncs — no human needed
If a pod crashes, ArgoCD detects and resyncs
Prometheus fires an alert, Grafana shows the anomaly

This is self-healing infrastructure.

Security Hardening

Network policies: default deny all, explicit allow per service
RBAC: least-privilege service accounts per workload
Sealed-Secrets: no plaintext secrets anywhere
Trivy: scans every image before it touches the cluster
Audit logging: every API call recorded

Observability Stack

Three pillars:

Metrics — Prometheus collects from every pod
Logs — Loki aggregates from every container
Alerts — AlertManager fires to Slack on anomalies

Dashboards track: cluster health, pod restarts,
deployment status, ArgoCD sync state, node memory/CPU.

What I Learned

Real DevOps is not about knowing commands.
It's about designing systems that run themselves.

Observability is not optional — if you can't see it,
you can't fix it.

Security must be designed in from day one.
Not bolted on after.

Git is not just version control.
In GitOps, Git is your deployment engine.

The Repo

Full open source: github.com/EdwinJdevops/ARCHNET

Architecture docs, tech decisions, security model,
CI/CD pipeline, Terraform IaC — all documented.

Who I Am

17-year-old self-taught DevOps Engineer from Nigeria.
Building infrastructure that enterprises pay millions for.

Available for DevOps, Cloud, and Platform Engineering roles globally.

If this helped you — share it.
If you're hiring — let's talk.

Originally published on Hashnode: [https://edwinjonathand-devops.hashnode.dev/]