The first time I ran a real patrol, my team leader told me something I didn't understand at the time:

"We're not training to do everything right. We're training so that when everything goes wrong, we still complete the mission."

I thought he was being dramatic.

Then we hit a rough patch on deployment, lost comms, took out some frustration, and had to extract with zero support.

And we still made it out.

Not because everything went according to plan. Because we trained for when the plan fell apart.

That lesson is burned into me now. And it's the single most valuable thing I brought from the military into building cloud systems.

Most engineers build for success. Veterans build for failure.

When I first started working in tech, I noticed something immediately.

Most engineers I worked with were optimizing for the happy path:

  • "If the user does X, then Y happens."
  • "If the deployment works, then we're good."
  • "If the database stays up, the app runs fine."

But almost no one was asking:

"What happens when it doesn't work?"

That mindset is foreign to military training.

In the military, you plan for failure from day one:

  • Comms go down: what's the backup plan?
  • Someone gets hit: who takes over their role?
  • The primary route is compromised: what's the alternate?
  • You lose your primary weapon: what do you do next?

You don't just have a plan. You have contingencies stacked on contingencies.

Because in combat, failure isn't theoretical. It's expected.

The same principle applies to cloud systems.

Production will go down. Databases will fail. Networks will drop. Services will crash. Deployments will break.

The question isn't if it happens. The question is what you do when it does.

Resilience isn't a feature you add later. It's how you think from the start.

When I design a system now, I start with failure modes.

Not "how will this work?"

But "how will this break, and what do we do about it?"

This is the same mental model we used for mission planning:

Military Mission Planning:

  1. What's the objective?
  2. What's the primary plan?
  3. What can go wrong?
  4. What's the backup for each failure point?
  5. How do we adapt if multiple things go wrong?

Cloud System Design (my version):

  1. What's the system supposed to do?
  2. What's the architecture?
  3. What are the failure modes?
  4. What's the fallback for each failure?
  5. How does the system degrade gracefully if multiple things fail?

Most people skip steps 3-5. That's where veterans have the edge.

Why secure design is the most critical vulnerability you'll face

Here's something that took me years to fully understand: the biggest security vulnerabilities don't come from missing a patch or forgetting to update a library.

They come from how you designed the system in the first place.

OWASP, the organization that tracks the most critical web application security risks, moved "Insecure Design" into their Top 10 list because they realized something important:

You can't patch your way out of bad design.

If your system is designed without thinking about failure modes, attack vectors, and abuse cases from the beginning, you're building on a broken foundation.

No amount of security tools, pentesting, or monitoring will fix that.

In the military, we understood this instinctively. You don't design a patrol route and then think about security afterwards. Security is baked into the mission planning:

  • Where are the chokepoints?
  • What are the blind spots?
  • If we get ambushed here, what's the fallback position?
  • How do we protect the convoy if we lose a vehicle?

Design came first. Execution followed.

The same principle applies to building systems.

Insecure design vs. insecure implementation

There's a difference between these two:

Insecure implementation: You designed a good authentication system, but forgot to enforce password complexity. That's fixable. You add the validation, push a patch, done.

Insecure design: You built a system where user accounts share the same session tokens. No amount of patching fixes that. The entire authentication model is fundamentally flawed. You have to rebuild it.

That's why OWASP elevated insecure design to a top-tier threat. Because it's the hardest to fix and the easiest to miss.

And here's the kicker: most engineers don't think about abuse cases during design.

They think about:

  • How the user will use the feature
  • How the system will scale
  • How fast it needs to perform

But not:

  • How an attacker will abuse this
  • What happens if someone sends malicious input
  • How this fails under adversarial conditions

Veterans are different. We've been trained to think adversarially from day one.

How military threat modeling translates to secure design

In military planning, you don't just think about your mission. You think about how the enemy will try to stop you.

  • What intel do they have?
  • What are their capabilities?
  • How will they exploit our weaknesses?
  • What would I do if I were them?

That's threat modeling.

In tech, threat modeling means asking:

  • What's the most valuable data in this system?
  • Who would want to steal or corrupt it?
  • What are the entry points?
  • If I were an attacker, how would I break in?
  • What's the easiest way to cause damage?

This isn't paranoia. This is design.

When you design with threat models in mind, you build different systems:

  • You don't trust user input by default
  • You enforce least privilege access
  • You separate sensitive data from public-facing services
  • You build in rate limiting and abuse detection from day one
  • You design for defense in depth, not single-layer security

These aren't features you add later. These are architectural decisions.

Real example: Designing Oauth-authentication for a high-stakes application

Early in my career, I worked on an application that handled sensitive law enforcement data.

The initial design proposal was straightforward:

  • Username/password login
  • Session cookies
  • Single database for everything

From a "make it work" perspective, that's fine.

From a security design perspective, that's a disaster waiting to happen.

Here's what we changed based on threat modeling:

Original design flaw: Session tokens stored in cookies without proper validation
Threat: Session hijacking, token reuse
Design fix: Moved to short-lived JWT tokens with refresh token rotation and device fingerprinting

Original design flaw: All data in one database with shared access
Threat: SQL injection or compromised credential = full data breach
Design fix: Separated sensitive data into isolated datastores with different access patterns, implemented row-level security

Original design flaw: Password reset via email link with no expiration
Threat: Password reset link interception, account takeover
Design fix: Time-limited reset tokens, require old password or multi-factor verification, invalidate all sessions on reset

Original design flaw: No rate limiting on login attempts
Threat: Credential stuffing, brute force attacks
Design fix: Exponential backoff on failed logins, CAPTCHA after 3 attempts, temporary account lock after 5 attempts

None of these were "features." These were foundational design decisions.

And they couldn't have been patched in later without major rework.

Design is where security succeeds or fails

The reason OWASP put insecure design in the Top 10 is because it's the root cause of so many breaches.

You can have perfect implementation, perfect code review, perfect testing, and still get breached because the design itself was flawed.

Some of the biggest breaches in history weren't due to missing patches. They were due to insecure design:

  • Systems that trusted client-side validation
  • APIs that didn't enforce authorization checks
  • Architectures that gave broad access to sensitive data
  • Applications that didn't separate concerns properly

All of these are design failures, not implementation failures.

And here's why this matters for resilience:

A system designed insecurely can't be resilient.

If your design allows a single compromised credential to access everything, you don't have resilience. You have a single point of catastrophic failure.

If your design doesn't consider how the system degrades under attack, you don't have resilience. You have a fragile system waiting to break.

The military lesson: Security through design, not just tools

In the military, we didn't rely on gear alone to stay safe.

We relied on:

  • Sound tactics (design)
  • Layered defense (architecture)
  • Constant situational awareness (monitoring)
  • Rapid response to threats (incident response)

The gear was important. But the tactics came first.

Same with security in tech.

Tools are important: firewalls, intrusion detection, vulnerability scanners, pentesting.

But if your design is broken, those tools are just putting band-aids on a gunshot wound.

Design is the foundation. Everything else builds on it.

When you start with secure design, you:

  • Reduce the attack surface from the beginning
  • Make implementation easier because guardrails are built in
  • Create systems that are easier to audit and verify
  • Build resilience that actually holds up under pressure

When you skip secure design and try to add security later, you:

  • Spend massive amounts of time retrofitting protections
  • Still miss fundamental flaws that can't be patched
  • Build fragile systems that break under adversarial conditions
  • Create technical debt that never fully gets paid down

How to think about design from a security-first perspective

If you're coming from the military, you already have this mindset. You just need to translate it.

Here's how I approach design now:

1. Start with the threat model, not the feature list

Before I write a single line of code, I ask:

  • What's the worst thing an attacker could do if they compromise this?
  • What data is most valuable?
  • What are the trust boundaries?
  • Where are the weak points?

2. Design for least privilege by default

Every component, every service, every user should have the minimum access needed to do their job. Nothing more.

This is the same principle as need-to-know in the military.

3. Assume breach

Design like the perimeter is already compromised. Because eventually, it will be.

This means:

  • Encrypt data at rest and in transit
  • Segment networks and services
  • Monitor for anomalous behavior inside the perimeter
  • Have detection and response capabilities ready

4. Build in observability for security, not just performance

You need to see when things go wrong. That means logging security events, tracking access patterns, and alerting on anomalies.

If you can't see an attack happening, you can't respond to it.

5. Test your design against abuse cases, not just use cases

Don't just test "can the user log in successfully?"

Test:

  • Can someone brute force the login?
  • Can someone bypass authentication?
  • Can someone escalate their privileges?
  • Can someone access data they shouldn't?

If your design holds up under those tests, it's resilient.

Real example: Building a monitoring system that doesn't depend on the thing it's monitoring

Early in my cloud engineering career, I inherited a monitoring setup that was... let's say "optimistic."

The monitoring dashboard ran on the same server cluster as the application it was monitoring.

So when the app went down, the monitoring went down with it.

Which meant we had no visibility into what was actually broken.

This is the equivalent of having your backup radio stored in the same vehicle as your primary radio.

If the vehicle gets hit, you lose both.

Anyone with military experience would spot this immediately. It's a single point of failure.

Here's what I changed:

  1. Moved monitoring to a separate infrastructure (different cloud region, different accounts)
  2. Set up multiple alerting channels (PagerDuty, Slack, email, SMS)
  3. Added external health checks from third-party services
  4. Built fallback notification paths in case the primary alerting system failed

Now, even if the entire production environment goes dark, we still have visibility and alerting.

That's not over-engineering. That's resilience.

The difference between redundancy and resilience

People hear "build for failure" and think "add more servers."

That's not what I'm talking about.

Redundancy means having backups.
Resilience means the system keeps working even when parts fail.

Example:

Redundant system: Two databases. If one fails, switch to the other.
Resilient system: Data is replicated across multiple regions in real time. If one region goes down, traffic automatically routes to another with zero downtime.

Redundancy is having a spare tire.
Resilience is having run-flat tires that keep you moving even after a puncture.

In the military, we didn't just carry backup gear. We trained to operate with degraded capabilities:

  • Lost night vision? We still moved.
  • Radio went down? We used hand signals.
  • Vehicle disabled? We continued on foot.

The mission didn't stop because one system failed.

That's the mindset I bring to system design:

If this component fails, does the system still work in some capacity?

If the answer is no, that's a problem.

Post-incident reviews aren't about blame. They're about getting better.

One of the hardest cultural shifts I had to make in tech was around how people handle failure.

In the military, After Action Reviews (AARs) were standard. After every mission, every training exercise, every operation, you sit down and ask:

  • What was supposed to happen?
  • What actually happened?
  • What went well?
  • What went wrong?
  • What do we do differently next time?

Critically: AARs aren't about blame.

The goal isn't to find out who screwed up. The goal is to learn so it doesn't happen again.

When I got to tech, I found that a lot of companies didn't do this well. Incidents happened, things got fixed, and everyone moved on without really analyzing what broke and why.

That's like getting ambushed, surviving, and then going back to the same spot without changing tactics.

You're just asking to get hit again.

I started running blameless post-incident reviews using the same AAR structure:

After every production incident:

  1. Document the timeline (what happened, in order)
  2. Identify what went well (what worked, what helped us recover faster)
  3. Identify what went wrong (root cause, contributing factors)
  4. Identify action items (specific changes we're making to prevent this)
  5. Assign owners and deadlines for those action items

Then we track them. We don't just write them down and forget them.

This is how you get better.

Every incident is a training opportunity. Every failure is intel about how your system actually behaves under stress.

If you're not learning from incidents, you're wasting valuable information.

The mental shift: From "we need 100% uptime" to "we need to recover fast"

Here's the hard truth: perfect uptime doesn't exist.

Not in combat. Not in cloud systems.

No matter how good your infrastructure is, something will eventually break.

The question is: how fast can you recover?

In the military, we called this resilience. The ability to take a hit and keep moving.

In tech, it's the same thing.

Some of the best systems I've worked on weren't the ones that never failed. They were the ones that failed fast, failed small, and recovered automatically.

Example:

  • Old way: Monolithic app. One bug crashes the whole thing. Recovery takes 20 minutes.
  • New way: Microservices. One service crashes. The rest keep running. Failed service auto-restarts in 30 seconds.

The second system has more frequent small failures. But the impact is smaller, and recovery is faster.

That's resilient design.

Chaos engineering: Training for failure on purpose

In the Marines, we ran drills constantly.

Casualty evacuation drills. Equipment failure drills. Communication blackout drills.

Not because we wanted things to go wrong. But because we needed to know we could handle it when they did.

In tech, this concept exists. It's called chaos engineering.

You intentionally break parts of your system in production (in controlled ways) to see how it responds.

Netflix made this famous with their "Chaos Monkey" tool, which randomly shuts down servers in production.

Sounds insane, right?

But here's the thing: if you don't test your system's failure modes, you don't actually know if your resilience works.

You're assuming it works. And assumptions get you killed in combat, and they crash production in tech.

I started running small chaos experiments:

  • Simulate a database failover during low-traffic hours
  • Kill a service instance and watch how the load balancer responds
  • Introduce artificial latency and see if timeouts trigger correctly
  • Disable a dependency and verify the system degrades gracefully

Every test taught me something. Every failure revealed a gap I didn't know existed.

This is just a drill.

Same concept the military has used forever. You train like you fight.

What you can do right now

If you're transitioning from the military into cloud engineering or DevSecOps, here's how to start applying this mindset:

1. Stop assuming things will work. Start assuming they'll fail.

When you design a system, document a feature, or deploy code, ask:

  • What happens if this fails?
  • What's the blast radius?
  • How will we know it failed?
  • How will we recover?

2. Build monitoring and alerting before you need it

You wouldn't go on patrol without comms. Don't run a production system without observability.

Set up monitoring and alerting first. Then build the feature.

3. Practice failure scenarios

Pick one component in your system. Turn it off. See what breaks.

Then fix it so it doesn't break next time.

Repeat until your system can survive most single-point failures.

4. Run post-incident reviews after every incident

Even small ones. Especially small ones.

Small incidents are practice for big ones. Treat them like training exercises.

5. Automate recovery wherever possible

If you find yourself manually fixing the same issue repeatedly, that's a signal to automate it.

In the military, we rehearsed until muscle memory took over. In tech, you automate until the system fixes itself.

The long game: Building systems that survive you

One thing the military teaches you: individuals rotate out. Units endure.

You're not building a system for yourself. You're building a system for the people who come after you.

That means:

  • Document failure modes and recovery procedures
  • Build runbooks for common incidents
  • Make your architecture understandable to someone who wasn't there when you built it
  • Train your team so they can respond without you

Your system should be able to survive:

  • You leaving the company
  • A junior engineer being on-call
  • Half the team being out sick
  • A major incident happening at 3 AM when no one is sharp

If your system can't handle those scenarios, it's not resilient. It's dependent.

And dependencies are vulnerabilities.

Closing thought

The military didn't teach me how to build cloud systems.

But it taught me how to think about failure. And how to think about threats.

How to plan for failure. How to design for security. How to train for worst-case scenarios. How to recover when things go wrong.

And that's more valuable than any cloud certification or security tool.

Because tools change. Platforms evolve. Services get deprecated.

But the mindset of building systems that don't break, or recover fast when they do. that's timeless.

And the mindset of designing for security from the start, not bolting it on later. that's the difference between systems that survive and systems that collapse under pressure.

OWASP didn't put insecure design in the Top 10 by accident. They put it there because it's the hardest problem to fix and the easiest to prevent.

If you're coming from the military, you already have this. You already think about threats, failure modes, and adversarial conditions. You just need to translate it into technical terms.

And if you're already in tech, take a page from military doctrine:

Design with threats in mind. Train for failure. Build for resilience. Learn from every incident.

The systems you build will thank you. And so will the people on-call at 3 AM.

Stay sharp.