Project Overview

Why this comes after Start Here#

Start Here gave you the list of what will be running at the end: a VPC across two availability zones, an EKS cluster carrying three microservices and a MySQL StatefulSet, a pipeline that refuses to publish insecure images, and a GitOps loop that turns a git push into a rolling update.

A list is not a system. Knowing the platform has both a cluster and a pipeline tells you nothing about why it needs both, what each layer is responsible for, or what would break if you removed one. Start naming tools now and you will learn Terraform, Kubernetes and Jenkins as three separate subjects that happen to share a repository.

So before any tool: what is this thing, and why does each layer exist?

The Cloud DevOps Capstone carries three microservices from source code to a monitored, GitOps-managed deployment on AWS EKS. It is the project every roadmap on this site ends at, and it is a working system rather than a demonstration. These chapters dissect every layer of that repository, from the VPC up to the reconciliation loop that deploys into it.

In the capstone, this chapter is the map every later one fills in.

Level 1 — Beginner#

What is this project?#

Imagine you are starting a new pizza restaurant. Before you can bake a pizza, you need to buy a building, install electricity, set up an oven, hire chefs, and create a recipe book.

In the software world, developers are the "chefs" and their code is the "pizza." This project automatically builds the entire restaurant for them. When a developer writes code, our system automatically creates the building (AWS Servers), installs the oven (Kubernetes), tests the recipe (Jenkins), and delivers the pizza to the customer (ArgoCD).

Why do we need it?#

If you don't have this system, every time a developer wants to launch a new app, a human has to manually click buttons on a screen to build a server, manually type commands to install software, and manually copy files. This is slow, causes human errors, and costs a lot of money.

ASCII Diagram: The Old Way vs. Our Way#

The Old Way (Manual):

[Developer] --> Types code --> Emails code to IT Guy --> IT Guy logs into Server --> Clicks buttons --> ❌ Server crashes (Human Error)

Our Project (Automated Platform):

[Developer] --> Types code --> Pushes to GitHub --> [🤖 Our Robot Platform] --> Tests Code --> Builds Server --> Deploys Code --> ✅ Success!

Level 2 — Intermediate#

What problem does this solve?#

This project solves the "It works on my machine" problem, and the "Deployment Anxiety" problem. By utilizing a completely automated Cloud-Native Platform, we achieve:

1. Consistency: Environments (Dev, Staging, Prod) are identical because they are built from the same code.
2. Speed: Code goes from the developer's laptop to production in minutes, not months.
3. Reliability: Automated tests prevent broken code from reaching users.

What existed before it?#

Before Cloud-Native platforms, companies used Monolithic Architectures running on Bare-Metal Servers.

• You bought physical hardware (Dell/HP servers) and put it in a closet.
• You installed Linux manually using a CD-ROM.
• You copied your code onto the server using FTP or SSH.

Why isn't the old solution enough?#

• Scaling: If your app goes viral, you can't buy and plug in 10 physical servers fast enough. Your website crashes.
• Blast Radius: In a monolith, if a developer writes a bad line of code in the "Shopping Cart" feature, the entire website (including the "Login" page) goes offline.
• Recovery Time: If the physical server's hard drive dies, the company is offline for days while IT restores manual backups.

How does our project use it?#

Our repository acts as the "Single Source of Truth." If the entire AWS datacenter burns down, we do not panic. We run the scripts in this repository, and the entire platform (Network, Databases, Servers, CI/CD, Monitoring) is perfectly rebuilt in another region in less than 30 minutes.

The Technology Stack (Overview)#

• AWS: The Cloud Provider (Rents us the physical computers).
• Terraform: The Architect (Builds the AWS infrastructure).
• Ansible: The Plumber (Installs the software on the AWS computers).
• Kubernetes: The Manager (Runs the actual application containers).
• Jenkins: The Quality Assurance Tester (Tests the code).
• ArgoCD: The Delivery Driver (Puts the code into Kubernetes).
• Prometheus/Grafana: The Security Cameras (Monitors the health of the system).

Level 3 — Advanced#

Production Architecture#

Let's look at how this platform is designed for a true production environment.

When we say "Cloud-Native", we mean the system is designed to embrace failure. Servers will die. Networks will partition. Our architecture handles this autonomously.

1. High Availability (HA): The Terraform network module spreads the subnets across two Availability Zones, and the EKS managed node group places workers in both. If us-east-1a fails, the Application Load Balancer routes to what remains in 1b. Three PodDisruptionBudgets make sure a voluntary disruption — a node drain during an upgrade — cannot take all replicas of a service at once either.
2. Horizontal Scaling: Three HorizontalPodAutoscalers add pods when CPU rises. When the cluster runs out of room to place them, the Cluster Autoscaler — granted its AWS permissions through IRSA, not a stored key — grows the node group.
3. Disaster Recovery (DR): The state of the cluster is not stored on the cluster. It is in Git. In a total loss you rebuild the account with terraform apply and point Argo CD back at the repository; it reconciles the cluster to what the manifests say.

The managed-service trade-off#

Enterprise architecture is not just about technology; it is about where you spend your attention.

• Why EKS rather than kubeadm on EC2? The control plane is roughly $73/month, and running your own is genuinely cheaper on paper. What you buy for that money is the part nobody enjoys: etcd backups, certificate rotation, and control-plane upgrades. This project spends its complexity budget on the delivery pipeline and the security posture instead.
• Where the same logic goes the other way: MySQL runs in the cluster as a StatefulSet rather than on RDS. Managed would be the production answer; here the point is to meet volumes, ordering and stable identity directly, because those are the concepts that make stateful Kubernetes hard.

ASCII Diagram: High-Level Platform Architecture#

                              [ User ]
                                 | HTTPS
   AWS Cloud (us-east-1)         v
  ┌──────────────────────────────────────────────────────────────────┐
  │  VPC 10.0.0.0/16                                                 │
  │  ┌────────────────────────────────────────────────────────────┐  │
  │  │ PUBLIC SUBNETS      [ ALB ]   [ NAT GW ]   [ Jenkins EC2 ] │  │
  │  └────────────────────────────────────────────────────────────┘  │
  │           |                                        |             │
  │           v                                        | push image  │
  │  ┌────────────────────────────────────────────┐    v             │
  │  │ PRIVATE SUBNETS — EKS node group           │  [ ECR ]         │
  │  │                                            │                  │
  │  │   node AZ-a                node AZ-b       │                  │
  │  │  ┌──────────────────────────────────────┐  │                  │
  │  │  │ namespace: ivolve                    │  │                  │
  │  │  │   frontend  (Node.js)  <-- only this │  │                  │
  │  │  │      |         |          is exposed │  │                  │
  │  │  │      v         v                     │  │                  │
  │  │  │   auth      roadmap                  │  │                  │
  │  │  │  (Python)    (Java)                  │  │                  │
  │  │  │      |         |                     │  │                  │
  │  │  │      +----+----+                     │  │                  │
  │  │  │           v                          │  │                  │
  │  │  │      mysql-0  (StatefulSet + PVC)    │  │                  │
  │  │  └──────────────────────────────────────┘  │                  │
  │  └────────────────────────────────────────────┘                  │
  └──────────────────────────────────────────────────────────────────┘
 
      [ EKS control plane ] — run by AWS, in an account you never see

Level 4 — Enterprise#

Industry Best Practices & Platform Engineering#

In Fortune 500 companies (like Netflix, Uber, or Spotify), they do not have "DevOps Teams" that just write CI/CD pipelines for developers. They have Platform Engineering Teams.

What is Platform Engineering? Instead of holding the developer's hand for every release, the Platform team builds an Internal Developer Platform (IDP)—a self-service engine. This repository is the foundation of an IDP. We provide "Golden Paths." If a developer writes a Java application and puts a Dockerfile in their repo, our platform automatically inherits it, tests it via Jenkins Shared Libraries, and deploys it via ArgoCD. The developer never speaks to the Ops team. They just push code.

Security, Compliance, and Zero Trust#

Enterprise platforms must adhere to strict regulatory compliance frameworks like SOC2 (System and Organization Controls) and ISO27001. How does this repository achieve that?

1. No Public IP Addresses: Worker nodes sit in private subnets with no route from an Internet Gateway, so nothing on the internet can open a connection to them directly. They remain reachable from inside the VPC and from the load balancer, which is how traffic gets in at all. Network segmentation like this is the kind of control an auditor looks for under frameworks such as SOC 2 — but a subnet layout does not by itself make a platform compliant, and no single control ever does.
2. Zero Trust Networking: Inside the cluster we do not assume the network is safe. Eight NetworkPolicies enforce a default-deny stance. The frontend is explicitly allowed to reach the two backends, and the backends the database — but a compromised frontend pod cannot scan the namespace, because sharing a namespace grants it nothing.
3. Enforced at admission, not by convention: The Pod Security Standard restricted is applied to the namespace, so a container asking to run as root, or for a writable root filesystem, or for extra capabilities, is rejected before it starts. A rule that is checked in review gets forgotten; a rule the API server enforces does not.
4. Immutable Infrastructure: Nobody SSHes in to run apt-get upgrade. Node images are replaced by rolling the managed node group, and the workloads survive it because of the PodDisruptionBudgets. This is what eliminates configuration drift.

Incident Response (SRE)#

In a Site Reliability Engineering (SRE) culture, we measure success in SLIs (Service Level Indicators) and SLOs (Service Level Objectives). Our platform is built to support this:

• Metrics: Prometheus scrapes system health every 15 seconds.
• Alerting: Alertmanager triggers PagerDuty if the Error Budget is burned too quickly.
• Blameless Post-Mortems: When the system fails (and it will), we don't fire the engineer. We fix the systemic flaw in this repository to ensure it can never happen again.

Interview Questions#

Beginner#

Q: What is the difference between IaaS and PaaS? A: IaaS (Infrastructure as a Service) is renting the raw hardware (like AWS EC2). PaaS (Platform as a Service) provides the hardware and the operating system/tools so developers can just focus on code (like Heroku, or the Kubernetes platform we are building in this project).

Intermediate#

Q: Why do we use both Terraform and Ansible? Why not just use one? A: They serve different purposes. Terraform is an Infrastructure Provisioner (it declares the existence of a server, network, or database in AWS). Ansible is a Configuration Manager (it connects to the server Terraform created and installs software on it). While they have overlapping features, using Terraform for hardware and Ansible for software is the industry standard.

Senior#

Q: This runs a database as a StatefulSet rather than on RDS. Defend that, then argue against it. A: For it: a StatefulSet gives each pod a stable identity and a volume that survives rescheduling, and the headless Service gives it a stable DNS name — which is exactly the machinery you must understand to run anything stateful on Kubernetes. Doing it by hand also makes the failure modes visible: delete the pod and watch the same PVC reattach. Against it: in production you would almost certainly use RDS. Backups, patching, failover and point-in-time recovery are solved problems that you are choosing to re-solve, and a single replica on one volume is a single point of failure regardless of how good the manifest is. The honest framing is that this is a teaching decision, not a production one.

Principal/Architect#

Q: The pipeline ends by committing a manifest rather than by running kubectl apply. What does that buy, and what does it cost? A: It buys three things. Credentials: a push-based pipeline needs cluster-admin from CI, so anyone who compromises the build server owns the cluster; here Jenkins only needs write access to a Git repository and to ECR, while Argo CD's authority stays inside the cluster. Determinism: the cluster continuously reconciles against Git, so manual kubectl edit drift is reverted instead of accumulating quietly until the next incident. Recovery: rebuilding is terraform apply plus pointing Argo CD at the repository. It costs latency and a harder debugging story — the deploy is now asynchronous, so "my build passed, where is my change?" becomes a question about sync state rather than a pipeline log, and you need sync waves to express ordering the pipeline used to enforce implicitly. Contents | System Architecture |