DEV Community: Jeff Graham

From Minikube to EKS: When "exec format error" Taught Me About Platform

Jeff Graham — Fri, 17 Oct 2025 01:42:05 +0000

Last week, I deployed three microservices to Kubernetes locally. This week, I deployed them to AWS EKS. What I thought would be a straightforward migration turned into a deep lesson about container platforms, cross-compilation, and production deployment patterns.

Here's what actually happened when theory met reality.

The Confidence Before the Crash

After successfully deploying to Minikube, I felt ready. I had working Kubernetes manifests, healthy pods, and services communicating properly. Moving to EKS seemed like the natural next step - just point kubectl at a different cluster, right?

I provisioned an EKS cluster, updated my kubeconfig, and confidently deployed all three services:

kubectl apply -f k8s-eks/api-service/
kubectl apply -f k8s-eks/auth-service/
kubectl apply -f k8s-eks/worker-service/

Then I watched the pods:

kubectl get pods -w

Everything showed "Running" status initially. Then "CrashLoopBackOff." All six pods. Every single one failing.

This was not the smooth migration I'd envisioned.

When Everything Fails: The Debugging Process

The first instinct when all your pods crash is panic. The second is to check the logs:

kubectl logs api-service-6bdd859969-bsssz

The output was cryptic:

exec /usr/local/bin/docker-entrypoint.sh: exec format error

I'd never seen this error before. Google taught me what it meant: platform architecture mismatch.

My development machine is an M2 Mac (ARM64 architecture). I'd been building Docker images locally, which defaulted to ARM64. Minikube on my Mac runs ARM64, so everything worked fine.

But EKS nodes run on AMD64 architecture. When Kubernetes tried to run my ARM64 containers on AMD64 nodes, the kernel couldn't execute the binaries. Hence: "exec format error."

The lesson: Local development and production infrastructure need platform alignment, or you need multi-platform builds.

Solution Attempt #1: Just Add --platform (Failed)

Armed with this knowledge, I tried the obvious fix:

docker buildx build --platform linux/amd64 \
  -t 023231074087.dkr.ecr.us-east-1.amazonaws.com/secure-cloud-platform/api-service:v1 \
  --push .

I rebuilt all three services with the --platform linux/amd64 flag and pushed to ECR. Then I restarted the deployments:

kubectl rollout restart deployment api-service
kubectl rollout restart deployment worker-service
kubectl rollout restart deployment auth-service

Surely this would work. The new pods spun up. I watched them start...and crash again.

Same error. Still ARM64 images somehow.

The lesson: The default Docker builder on Mac doesn't reliably cross-compile. You need a proper buildx builder.

Solution Attempt #2: Multi-Platform Builder (Success)

The fix required creating a dedicated buildx builder that properly supports cross-platform builds:

docker buildx create --name multiplatform --driver docker-container --use
docker buildx inspect --bootstrap

This creates a container-based builder that can properly build for different platforms. Then I rebuilt:

cd apps/api-service
docker buildx build --platform linux/amd64 \
  -t 023231074087.dkr.ecr.us-east-1.amazonaws.com/secure-cloud-platform/api-service:v1 \
  --push .

Same for worker and auth services.

But there was still a problem. When I checked which platforms were actually in ECR:

docker buildx imagetools inspect \
  023231074087.dkr.ecr.us-east-1.amazonaws.com/secure-cloud-platform/api-service:v1

The output showed multiple manifests - including both AMD64 AND an "unknown/unknown" platform (build attestations). Kubernetes was apparently pulling the wrong one.

The lesson: Multi-platform images are great, but you need to ensure Kubernetes pulls the right architecture.

The Final Solution: Explicit SHA Digests

The breakthrough came from understanding that the :v1 tag pointed to a manifest list with multiple platform variants. Kubernetes was making the wrong choice.

The fix was to reference the specific AMD64 digest directly:

kubectl set image deployment/api-service \
  api=023231074087.dkr.ecr.us-east-1.amazonaws.com/secure-cloud-platform/api-service:v1@sha256:6b8903f38db383b2732565a4022ad916b10009c962c761986a76841c2c354834

I got the SHA256 digest from the imagetools inspect output - it showed exactly which digest was the AMD64 platform.

After updating all three deployments with their specific AMD64 digests, I watched the pods:

kubectl get pods

NAME                              READY   STATUS    RESTARTS   AGE
api-service-65f8f5f745-6mhd7      1/1     Running   0          39s
api-service-65f8f5f745-sv2xx      1/1     Running   0          29s
auth-service-7867d7bc58-nlkj9     1/1     Running   0          6s
worker-service-7dd95b78bc-rtslr   1/1     Running   0          20s

Finally. All pods running. All services healthy.

Testing the public API LoadBalancer:

curl http://aec0488a8aa514bafbe7b0ad77647334-1658914460.us-east-1.elb.amazonaws.com/health

{"status":"healthy","service":"api-service","timestamp":"2025-10-16T23:51:26.385Z"}

Success.

What I Learned About Production Deployments

Platform Architecture Matters

In local development, you can ignore platform differences. In production, you can't. Your build process needs to account for where your code will actually run.

For cloud deployments, that almost always means AMD64/x86_64, even if you develop on ARM Macs.

Multi-Platform Builds Are the Standard

The proper solution isn't to avoid building on ARM machines. It's to build multi-platform images correctly:

docker buildx build --platform linux/amd64,linux/arm64 \
  -t myimage:latest --push .

This creates a manifest list that works on both architectures. Kubernetes will automatically pull the right variant for each node.

But you need the right builder setup, or it silently fails.

Debugging Requires Multiple Tools

Solving this required understanding several layers:

kubectl logs to see the error
kubectl describe pod to check events
docker buildx imagetools inspect to verify what platforms were actually built
ECR console to confirm what was pushed
Understanding of Docker manifest lists and multi-arch images

No single tool showed the full picture. Production debugging means combining multiple perspectives.

Local-to-Production Gaps Are Real

Minikube worked because it matched my local architecture. Moving to EKS exposed the platform mismatch.

This is a small example of a larger truth: local development environments don't fully replicate production, no matter how hard you try.

The solution isn't to make local identical to production. It's to catch these differences early with proper CI/CD pipelines that build and test in production-like environments.

The Architecture That Emerged

After all the debugging, here's what's running in EKS:

Three Deployments:

API Service: 2 replicas on port 3000
Auth Service: 2 replicas on port 3001
Worker Service: 2 replicas on port 3002

Three Services:

API Service: LoadBalancer (public internet access)
Auth Service: ClusterIP (internal only)
Worker Service: ClusterIP (internal only)

Resource Configuration:

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "200m"

Health Checks:

livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 10
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 5
  periodSeconds: 5

Every service has proper resource limits to prevent one container from consuming all node resources. Every service implements health checks so Kubernetes knows when to restart or remove pods from load balancing.

This isn't just "getting it to work." This is production-ready configuration.

What's Next

This deployment taught me about the gap between local development and production infrastructure. But it also revealed the next challenges:

Immediate Needs:

ConfigMaps for application configuration
Secrets for sensitive data (JWT keys, DB credentials)
Proper logging and monitoring
CI/CD pipeline for automated deployments

Future Infrastructure:

Ingress controller for better HTTP routing
Network policies for service-to-service security
Horizontal pod autoscaling based on load
Complete observability stack

The platform is running, but it's not yet production-ready. There's still work to do.

The Value of Building in Public

When you document your learning publicly, you can't hide mistakes. That's uncomfortable but valuable.

I could have written a clean tutorial: "Here's how to deploy to EKS in 5 easy steps." That would have been simpler.

But it wouldn't have been honest. And it wouldn't have taught the real lesson: production deployments are rarely smooth, and the debugging process is where you actually learn.

Every error message is a lesson. Every wrong assumption gets corrected. Every "why doesn't this work?" forces you to understand the system more deeply.

That's how you build real expertise.

Want to Follow Along?

The complete project is on GitHub: secure-cloud-platform

All the Kubernetes manifests, Dockerfiles, and deployment documentation are there. You can see exactly what I built and how it's configured.

I'm documenting this journey on Dev.to and LinkedIn. If you're also learning Kubernetes, dealing with platform architecture issues, or just want to follow along, connect with me.

Next post: Setting up proper configuration management with ConfigMaps and Secrets, and why hardcoded values in manifests are technical debt.

About my journey: Former Air Force officer and software engineer/solutions architect, now teaching middle school computer science while transitioning back into tech with a focus on DevSecOps. Building elite expertise in Infrastructure as Code, Kubernetes security, and cloud-native platforms. AWS certified (SA Pro, Security Specialty, Developer, SysOps). Learning in public, one commit at a time.

From Docker Containers to Kubernetes Pods: Deploying My First Microservices Platform

Jeff Graham — Sun, 12 Oct 2025 00:12:56 +0000

Last week, I built three microservices in three days. This weekend, I deployed them all to Kubernetes. Here's what I learned about container orchestration by doing it myself.

The Gap Between Docker and Kubernetes

After building my API service, auth service, and worker service with Docker, I had three working containers. I could run them individually, test them locally, and they worked fine.

But running containers individually doesn't scale. In production, you need:

Multiple replicas for redundancy
Automatic restarts when containers fail
Load balancing across instances
Service discovery so containers can find each other
Rolling updates without downtime

That's what Kubernetes provides. It's the difference between "I have containers" and "I have a platform."

Day 1: Deploying the First Service

I started with Minikube, a local Kubernetes cluster that runs on your machine. The installation was straightforward, but the conceptual shift from Docker to Kubernetes took time to understand.

Kubernetes introduces new abstractions:

Pods - The smallest unit in Kubernetes. Think of a pod as a wrapper around one or more containers. My API service container becomes an API service pod.

Deployments - Manages pods. Instead of saying "run this container," you say "maintain 2 replicas of this service with these resources." Kubernetes handles the rest.

Services - Provides a stable network endpoint. Pods can die and restart (with new IP addresses). Services give them a consistent name and handle load balancing.

Writing my first Kubernetes manifests felt like learning a new language. Here's what a basic deployment looks like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      containers:
      - name: api
        image: api-service:v1
        ports:
        - containerPort: 3000

This declares what I want (2 replicas of my API service), and Kubernetes maintains that state. If a pod crashes, Kubernetes automatically creates a new one. If I scale to 3 replicas, Kubernetes creates another pod. It's declarative infrastructure.

The first deployment took several attempts. I hit the classic error: ErrImageNeverPull. Minikube has its own Docker environment, so I had to rebuild my image in Minikube's Docker daemon. A small detail, but it cost me 30 minutes of debugging.

Once the pods were running, accessing them was another learning curve. Kubernetes doesn't expose pods directly to your host machine. You need a Service with a NodePort, or you use Minikube's tunnel feature.

minikube service api-service --url

This gave me a localhost URL to test my API. When I hit the health endpoint and got back JSON, it felt like a breakthrough. My container was now a pod, managed by Kubernetes.

Day 2: Deploying All Three Services

With the pattern established, deploying the auth and worker services went faster. Build the image in Minikube's Docker, write the Deployment and Service manifests, apply them with kubectl, verify the pods are running.

By the end of Saturday, I had:

6 pods running (2 replicas each of API, auth, worker)
3 Deployments managing them
3 Services exposing them
All orchestrated by Kubernetes

Running kubectl get all and seeing everything marked as "Running" was satisfying in a way that's hard to explain. This was no longer just containers. This was a platform.

Day 3: Service Discovery and Communication

The real power of Kubernetes became apparent when I tested service-to-service communication.

In Kubernetes, services can reach each other by name. No IP addresses, no configuration files with hardcoded endpoints. Kubernetes DNS handles service discovery automatically.

From any pod in the cluster, I could reach other services:

http://api-service:3000
http://auth-service:3001
http://worker-service:3002

To test this, I ran a temporary pod with curl installed:

kubectl run curl-test --image=curlimages/curl -it --rm -- sh

Inside that pod, I tested the full authentication flow:

Called auth-service to login and get a JWT token
Verified the token by calling auth-service again
Created a background job by calling worker-service
Checked worker statistics

Everything worked. Services could discover and communicate with each other automatically. The auth service didn't need to know the worker service's IP address. Kubernetes DNS resolved the service names to the correct pods and load-balanced requests across replicas.

This is what makes microservices viable at scale. Services are decoupled. Pods can restart, move to different nodes, or scale up and down, and the network layer just works.

What I Learned About Kubernetes

Kubernetes is declarative, not imperative

With Docker, you run commands: "start this container with these flags." With Kubernetes, you declare what you want: "maintain 2 replicas of this service." Kubernetes continuously reconciles the actual state with your desired state.

If a pod crashes, Kubernetes automatically creates a new one. You don't write scripts to handle failures. The system is self-healing by design.

Resource limits matter

Every container in my deployments has CPU and memory limits:

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "200m"

Requests tell Kubernetes how much the container needs. Limits prevent a single container from consuming all node resources. Without these, a memory leak in one service could crash the entire cluster.

Health checks are essential

I implemented liveness and readiness probes for every service:

livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 10
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 5
  periodSeconds: 5

Liveness probes tell Kubernetes if the container is healthy (if not, restart it). Readiness probes tell Kubernetes if the container is ready to receive traffic (if not, remove it from the service endpoints).

These aren't optional features to add later. They're fundamental to how Kubernetes manages your workloads.

kubectl is your interface to everything

Learning kubectl commands was like learning a new shell. The most useful ones:

kubectl get pods              # See all pods
kubectl get pods -w           # Watch pods update
kubectl logs <pod-name>       # View pod logs
kubectl describe pod <name>   # Debug pod issues
kubectl exec -it <pod> -- sh  # Shell into a pod
kubectl scale deployment api-service --replicas=3  # Scale up

When things go wrong (and they will), these commands are how you debug. Looking at pod events with kubectl describe saved me multiple times when pods wouldn't start.

Challenges I Hit

Image pull errors were frustrating until I understood Minikube's Docker environment. Building images locally and expecting Kubernetes to find them doesn't work. You have to build in the right context.

Networking confusion took time to sort out. NodePort services, Minikube tunnels, internal vs external access - it's more complex than Docker's port mapping. Understanding that services handle internal routing while NodePort handles external access clarified things.

YAML syntax is unforgiving. Missing indentation, typos in field names, wrong API versions - all caused cryptic errors. A linter would have saved me time.

Why This Matters for DevOps

Container orchestration is fundamental to modern DevOps practices. You can't practice continuous deployment at scale without it. You can't implement blue-green deployments, canary releases, or auto-scaling without an orchestrator.

Kubernetes provides the platform for everything else: CI/CD pipelines, infrastructure as code, observability, security policies. Learning Kubernetes isn't just about containers. It's about building production systems.

What's Next

This weekend taught me Kubernetes fundamentals, but I'm just scratching the surface. Coming next:

ConfigMaps and Secrets - Right now, configuration is hardcoded in my manifests. I need to externalize configuration and manage secrets properly.

Ingress - Instead of NodePort services, use an Ingress controller for proper HTTP routing and load balancing.

Network Policies - Implement security controls that restrict which services can talk to which.

Terraform for EKS - Deploy this platform to real AWS infrastructure using Infrastructure as Code.

CI/CD Pipeline - Automate building images, scanning for vulnerabilities, and deploying to Kubernetes.

After that: monitoring with Prometheus, logging aggregation, service mesh, and all the other pieces of a production platform.

The Power of Hands-On Learning

I could have watched 10 hours of Kubernetes tutorials and still not understood it as deeply as deploying my own services and debugging the issues.

Reading about Deployments is one thing. Writing one, applying it, watching pods fail, reading error messages, fixing the manifest, and seeing it finally work - that's how you actually learn.

If you're learning Kubernetes, I recommend this approach: build something simple, deploy it, break it, fix it. The concepts that seemed abstract in documentation become concrete when you're running actual workloads.

Want to Follow Along?

The complete project is on GitHub: secure-cloud-platform

All the Kubernetes manifests, documentation, and setup instructions are there. Each service has detailed deployment guides.

I'm documenting this journey on Dev.to and LinkedIn. If you're also learning Kubernetes or have feedback on my setup, I'd love to hear from you.

Next post: Infrastructure as Code with Terraform - provisioning AWS resources and deploying this platform to real cloud infrastructure.

3 Microservices, 3 Days: What I Learned About DevOps Architecture

Jeff Graham — Fri, 10 Oct 2025 02:05:19 +0000

A few days ago, I published my first technical post defining DevOps. Then I immediately started building - three microservices in three days. Here's what I learned about DevOps architecture by actually doing the work.

Why Build Three Services?

When I started my transition from teaching to DevSecOps engineering, I knew I needed more than certifications and theory. I needed to build real systems that demonstrate the principles I'm learning.

The goal: create a production-ready microservices platform that showcases Infrastructure as Code, container orchestration, security automation, and CI/CD practices. But before I could deploy to Kubernetes or write Terraform configurations, I needed actual services to orchestrate.

So I committed to building three microservices in three days, documenting everything publicly on GitHub.

Day 1: API Service - Learning Docker Fundamentals

The first service was a Node.js REST API - simple, familiar territory that let me focus on containerization rather than application logic.

What I built:

Express.js API with health check and basic endpoints
Dockerfile with multi-stage considerations
Proper health checks for container orchestration
Clean project structure

Key learnings:

The Docker build process taught me about image layers and caching. Every line in a Dockerfile creates a layer, and the order matters. Copying package.json before the application code means dependency installation only runs when dependencies actually change, not on every code change.

Health checks aren't optional in production systems. They're how orchestrators like Kubernetes know if a container is actually ready to receive traffic. I learned to implement them from day one rather than retrofitting later.

DevOps principle in action: Automation starts with containerization. If you can't package your application consistently, you can't automate its deployment.

You can see the API service code here.

Day 2: Auth Service - Security from the Start

The second service added JWT-based authentication. This taught me about service isolation and security thinking in a microservices architecture.

What I built:

JWT token generation and validation
Token refresh mechanism
Proper error handling for auth failures
Environment-based configuration

Key learnings:

Microservices force you to think about service boundaries. The auth service doesn't know about users, orders, or business logic. It has one job: authenticate and validate tokens. This separation is powerful because it means authentication logic lives in exactly one place.

Security considerations change in distributed systems. In a monolith, you might store sessions in memory. In microservices, you need stateless authentication that works across service boundaries. JWTs solve this, but they come with their own challenges around token invalidation and secret management.

I also learned that .env.example files are critical. They document what configuration a service needs without exposing actual secrets - a small detail that matters when multiple people (or your future self) need to run the service.

DevOps principle in action: Security must be built in, not bolted on. DevSecOps means considering security at every layer, from the container base image to how secrets are managed.

Check out the auth service implementation here.

Day 3: Worker Service - Diversifying the Stack

The third service was a Python background worker for asynchronous job processing. This diversified my tech stack and taught me about async patterns in distributed systems.

What I built:

Flask API for job submission
Threading-based job queue
Job status tracking
Multiple job types (email, image processing, data sync, reports)

Key learnings:

Background workers solve a fundamental problem in web applications: some operations take too long to run synchronously. Users don't want to wait 30 seconds for an image to process or a report to generate. Workers let you respond immediately with "job queued" and process it asynchronously.

In production, this worker would connect to Redis or RabbitMQ. For learning purposes, I used Python's Queue class. The important lesson was understanding the pattern: decouple request handling from work execution.

Python's threading model is different from Node's event loop. Understanding these differences matters when you're building polyglot microservices. The right tool for the job means choosing languages based on what each service needs to do.

DevOps principle in action: Observability matters from the start. The worker exposes statistics endpoints showing queue depth, completed jobs, and processing status. You can't operate what you can't observe.

See the worker service here.

What This Taught Me About DevOps Architecture

Building these services clarified several DevOps principles I'd only understood theoretically:

Microservices Enable Independent Deployment

Each service has its own Dockerfile, dependencies, and release cycle. The API service can deploy without touching auth or worker. This independence is what enables continuous deployment at scale.

Containers Are the Unit of Deployment

With Docker, "it works on my machine" becomes "it works in this container." The container is the deployment artifact. This consistency across development, staging, and production is foundational to DevOps practices.

Documentation Is Infrastructure

Good README files, clear environment variable documentation, and example configurations aren't nice-to-haves. They're essential infrastructure. When you're running dozens of services, clear documentation is what prevents deployment failures at 2am.

Service Communication Requires Planning

Right now these services run independently. But when I deploy them to Kubernetes, I'll need to think about:

Service discovery (how does the API find the auth service?)
Network policies (which services can talk to which?)
Failure handling (what happens when auth is down?)

These aren't problems that exist in monoliths. Microservices trade local complexity for distributed systems complexity.

Security Thinking Changes

In a monolith, you secure the perimeter. In microservices, you need defense in depth:

Container security scanning
Network policies between services
Secret management per service
Token-based authentication across service boundaries

This is why it's DevSecOps, not just DevOps. Security has to be woven into every architectural decision.

Architecture Decisions and Tradeoffs

Why three services specifically?

Three is the minimum to demonstrate microservices patterns without overwhelming complexity. You have:

A stateless API (scales horizontally easily)
A security service (single responsibility)
A background worker (async patterns)

This mirrors real production architectures at smaller scale.

Why Node and Python?

Polyglot microservices are common in production. Different services have different needs. Node's async model is great for I/O-bound APIs. Python's ecosystem is strong for data processing and background jobs. Learning to containerize both prepares me for real-world heterogeneous environments.

Why no database yet?

I'm building in layers. First, get services containerized and running. Next, orchestrate them with Kubernetes. Then add databases, message queues, and observability tooling. Trying to do everything at once is how projects stall.

What about production concerns?

Each service's README documents production considerations I'm aware of but haven't implemented yet:

Database persistence
Proper message queues
Horizontal scaling
Monitoring and alerting
Log aggregation

Acknowledging what you don't know is as important as demonstrating what you've learned.

What's Next: Kubernetes

These three services are ready for orchestration. Next up, I'm deploying them to a local Kubernetes cluster using Minikube. That means:

Writing Kubernetes manifests (Deployments, Services)
Understanding pods, replicas, and service discovery
Deploying all three services to K8s
Implementing service-to-service communication
Learning kubectl and cluster management

After that: Terraform for infrastructure as code, GitHub Actions for CI/CD, and security scanning throughout the pipeline.

The Power of Building in Public

Three days ago, I had an empty GitHub repository. Today, I have three working microservices, comprehensive documentation, and a deeper understanding of DevOps architecture than any tutorial could provide.

Building in public creates accountability. Documenting as I learn forces clarity. Sharing code means writing it well enough that others could run it.

If you're learning DevOps, I recommend this approach: pick a project, commit to building it publicly, and document everything. The act of explaining what you're learning solidifies the knowledge.

Want to Follow Along?

The complete project is on GitHub: secure-cloud-platform

Each service has its own README with setup instructions, API documentation, and production considerations. The project is a work in progress - I'm adding to it as I learn.

I'm documenting this journey on Dev.to and LinkedIn. If you're also transitioning into DevOps or have feedback on the architecture, I'd love to hear from you.

Next post: Deploying these microservices to Kubernetes - what I learn when three containers become three pods.

What is DevOps? A Definition from a Teacher Transitioning to DevSecOps

Jeff Graham — Tue, 07 Oct 2025 00:04:03 +0000

The Problem DevOps Solves

For decades, software development operated like a relay race with a broken baton pass. Developers would "throw code over the wall" to operations teams, who then struggled to deploy and maintain it in production. When things inevitably broke, the blame game began. This friction created slow release cycles, brittle systems, and frustrated teams on both sides.

I'm witnessing this firsthand as I transition from teaching middle school computer science to pursuing a career in DevSecOps. As I study the landscape, I'm realizing that DevOps emerged as a fundamental rethinking of how we build and run software.

What DevOps Actually Is

DevOps isn't just a set of tools or a job title—it's a cultural philosophy that tears down the wall between development and operations.

At its core, DevOps means shared ownership of the entire software lifecycle. Developers don't get to say "it worked on my machine" and walk away. Operations teams don't just keep the lights on without understanding what they're running. Everyone is responsible for delivering value to users—from the first line of code to the last byte served in production.

This shared responsibility manifests through three key practices:

1. Automation Everywhere

Every code commit triggers automated testing, security scanning, and quality checks. Deployments happen through repeatable, auditable pipelines—not manual runbooks prone to human error. Infrastructure itself becomes code that can be versioned, tested, and deployed like any application.

As someone with a software engineering background, this resonates deeply. The idea that infrastructure can be treated with the same rigor as application code is powerful.

2. Continuous Feedback Loops

Monitoring, logging, and observability aren't afterthoughts—they're built in from day one. When issues arise, teams practice blameless post-mortems focused on improving systems, not finding scapegoats.

This reminds me of my work as a Solutions Architect, where understanding system behavior was critical to making good architectural decisions.

3. Iterative Improvement

Instead of massive quarterly releases that terrify everyone, teams ship small changes frequently. This reduces risk, accelerates learning, and keeps the feedback cycle tight between what we build and how users experience it.

The Business Impact

Companies practicing DevOps deploy code dramatically more frequently while maintaining stability and security. They recover from incidents faster and spend less time firefighting, freeing teams to build new capabilities instead of just keeping existing ones alive.

But here's what's often missed: DevOps isn't about developers doing operations work or ops learning to code (though both help). It's about creating a culture where the success of the system is everyone's job. Where "it's not my problem" becomes "how can I help?" Where deployment day stops being feared and starts being routine.

My Journey

As I transition from teaching to DevSecOps, I'm building a foundation in:

Infrastructure as Code (Terraform)
Container orchestration (Kubernetes)
Cloud platforms (AWS—I hold SA Pro, Security Specialty, Developer Associate, and SysOps Admin certs)
Security automation and scanning

I'm documenting my journey by building a production-ready microservices platform that demonstrates DevSecOps principles in action. You can follow along at github.com/jeffgrahamcodes/secure-cloud-platform.

Why This Matters to Me

Coming from education, I've spent years breaking down complex concepts for middle schoolers. Now I'm realizing that DevOps represents the maturation of our industry—moving from individual craftspeople working in isolation to true engineering discipline with collaboration, measurement, and continuous improvement at its heart.

The principles I taught in the classroom—collaboration, accountability, continuous learning—are the same principles that make DevOps teams successful.

What's Next

I'm on a mission to become a top 1% DevSecOps engineer, and part of that journey is solidifying my understanding of these fundamental concepts. This post is my current understanding of DevOps, but I know it will evolve as I gain hands-on experience.

If you're further along in your DevOps journey, I'd love to hear your thoughts. What did I miss? What nuances become apparent only after you've lived it?

And if you're also transitioning into DevOps, let's connect. We're in this together.

About me: Former Air Force officer, software engineer, and Solutions Architect now teaching middle school math and computer science. Currently making the leap back into tech with a focus on DevSecOps, infrastructure as code, and Kubernetes security. Follow my journey as I build in public.

Connect with me on LinkedIn | Follow my projects on GitHub