Project Architecture Summary (For Recruiters)

Why this comes at the end#

You have built every layer separately, each one solving the problem the last one exposed. This chapter puts them back together on one page — which is also the form the platform takes when somebody else asks you to explain it.

In the capstone, this is the whole platform, summarised in four layers.

The executive summary#

If you are a Recruiter, a Hiring Manager, or a Senior Engineer looking at this GitHub repository, this document serves as the Executive Summary of the platform architecture.

This project is not a tutorial. It is a working, production-shaped platform — three microservices carried from source code to a monitored, GitOps-managed deployment on AWS EKS. The numbers below are measured, not aspirational: the Terraform plans clean against a live AWS account, and all 48 Kubernetes objects render through Kustomize and validate against the real 1.31 schemas.

High-Level Architecture Overview#

The platform is divided into four strictly segregated operational layers:

1. The Infrastructure Layer (AWS + Terraform)#

No ClickOps. The entire AWS footprint is provisioned from four Terraform modules — network, eks, ecr and server — with state in S3.

Networking: A VPC on 10.0.0.0/16 across two Availability Zones. Public subnets carry the internet-facing ALB, the NAT Gateway and the Jenkins host; the EKS worker nodes sit in private subnets with no route in. Twenty network ACL rules and VPC Flow Logs sit underneath.
Compute: An Amazon EKS cluster with a managed node group across both AZs, and a single t3.medium EC2 instance for Jenkins with IMDSv2 enforced.
Data: MySQL runs inside the cluster as a StatefulSet with a gp3 volume and a headless Service — not RDS. That is a deliberate teaching choice: it forces you to meet identity, ordering and storage in Kubernetes rather than hiding them behind a managed service.
Security: An OIDC provider on the cluster and three IRSA roles — EBS CSI driver, AWS Load Balancer Controller, Cluster Autoscaler — so no pod holds a static AWS credential.

2. The Configuration Management Layer (Ansible)#

The cluster's control plane is managed by AWS, so Ansible's job here is the part that is yours: the build host.

Nine roles — aws_cli, common, docker, java, jenkins, kubectl, helm, sonarqube, trivy — turn a bare Ubuntu instance into a working Jenkins server with the whole toolchain on it.
Dynamic inventory through the aws_ec2 plugin, so hosts are discovered by tag rather than written into a file that goes stale the first time an instance is replaced.
Vault for the values that must not be in the repository.

3. The Continuous Integration Layer (Jenkins + ECR)#

An automated, secure software supply chain, one pipeline per microservice.

Pipeline-as-Code: Nine declarative stages — checkout, unit tests, SonarQube analysis, build, Trivy scan, push to ECR, remove the local image, update the manifests, push them back to Git.
Shared library: The logic lives in a Groovy shared library under vars/, so three services share one implementation instead of three copies of the same Jenkinsfile.
DevSecOps: Trivy runs before the push. An image with a fixable CRITICAL CVE never reaches the registry — the gate is enforced, not advisory. SonarQube's quality gate can fail the build at stage 3.
Registry: Images land in Amazon ECR with immutable tags, so a tag cannot be quietly repointed at different bytes.

4. The Continuous Delivery Layer (GitOps / Argo CD)#

Humans do not deploy code. The pipeline's last act is a commit.

Argo CD runs in the cluster and reconciles it against 04-Kubernetes/manifests/ in the same repository.
Sync waves order the rollout deliberately: database first, then the backends, then the frontend, then the load balancer — because starting them all at once means the services that need the database crash-loop until it happens to be ready.
Self-healing: Automated sync with prune and selfHeal, so configuration drift is reverted rather than accumulating. A manual kubectl edit does not survive.
Kustomize renders the manifests, keeping one base with overlays rather than templating everything.

Security & Observability#

Default-deny networking#

Eight NetworkPolicies put the namespace in a deny-by-default posture, with each allowed path written down explicitly. A compromised frontend pod cannot reach the database simply because it shares a namespace with it.

Admission-enforced hardening#

The Pod Security Standard restricted is enforced at admission: pods run as non-root with a read-only root filesystem and every capability dropped. Four RBAC ServiceAccounts, a ResourceQuota and a LimitRange bound what the namespace can do and consume; three PodDisruptionBudgets keep a voluntary node drain from taking a service down, and three HorizontalPodAutoscalers handle load.

Secrets and credentials#

No static AWS credentials exist anywhere in the system — the cluster gets its permissions through IRSA, and the Jenkins host through an EC2 instance profile. KMS handles encryption at rest.

The Observability Stack (Prometheus + Grafana)#

Metrics: kube-prometheus-stack scrapes pods, nodes and endpoints, plus black-box probes that test the application from outside, the way a user meets it.
Alerts: Twelve alert rules, each annotated with a link to a runbook. An alert that tells you something is broken without telling you what to do about it is a pager that trains people to ignore it.
Dashboards: JSON definitions committed to the repository and loaded from ConfigMaps, so the visualisation layer is versioned like everything else.

Conclusion#

This repository demonstrates the ability to architect, provision, secure and monitor a distributed microservice system — and, more usefully, to prove that it works rather than assert it. Contents | Conclusion |