WIP.2 Week 1

week1.md

@@ -13,7 +13,7 @@ This project will migrate the Spring PetClinic Microservices demo from its local
 | Cloud Architect | Architecture, service selection |
 | Dev Lead | App changes for cloud readiness |
 | DevOps Engineer | CI/CD, IaC, deployments, monitoring |
-| Security Engineer | IAM, encryption, compliance |
+| Security Team | IAM, encryption |
 | End Users / Demo Audience | Acceptance and usability feedback
 
 ### Expectations
@@ -67,13 +67,76 @@ This project will migrate the Spring PetClinic Microservices demo from its local
 | Stakeholder / Role | Requirement | Description |
 |----|----|----|
 | **Developers** | Continuous Integration | Each merge must trigger automated build, test, and image creation. |
-| | Local to Cloud Parity | Development environment must mirror AWS setup using Docker Compose or local ECS simulation. |
+| | Local to Cloud Parity | Development environment must mirror AWS setup. |
 | **DevOps Engineers** | Automated Deployment | CI/CD pipeline must deploy microservices to Dev, Staging, and Prod environments automatically. |
 | | Test Automation | Integration tests must run automatically in CI/CD pipeline. |
 || Infrastructure as Code | All AWS resources defined through configuration files |
 | | Monitoring & Alerts | Centralized logging, metrics, and tracing for all microservices. Automated alerting for service downtime or threshold breaches. |
+| | Scalability | Services must be scalable |
 | **Security Team** | Access Control | Roles per service with least-privilege permissions.|
 | | Secrets Management | All secrets stored securely. |
 | **Product / Management** | Availability & Demo Readiness | System must be reliable and presentable for client or internal demos.|
 | **End Users (Demo Audience)** | Stable Access | Web UI and APIs must remain responsive under typical load. |
 
+### Non-Functional Requirements
+| Category | Requirement | Standard |
+|----|----|----|
+| **Development** | Local to Cloud parity | Docker Compose or local ECS simulation |
+| **Maintainability** | IaC  | Code stored in version control |
+| **Performance** | Pipeline execution time | < 10 minutes per merge |
+| | Scaling | Services can be scaled horizontally |
+| | API / UI response | p95 latency < 200 ms under normal demo load |
+| **Reliability** | Deployment success rate | ≥ 99% successful deployments |
+| | Alert response | Alerts trigger within < 5 minutes of failure detection |
+| | Error tolerance | < 0.1% failed requests |
+| **Availability** | System uptime | ≥ 99.9% uptime |
+| **Observability** | Logs, Metrics, Traces | Centralized in monitoring solution |
+| **Security** | Least-privileged Roles | Roles restricted per service; no default full-access policies |
+| | Secret encryption | Secrets stored in AWS |
+| **Continuity** | RPO / RTO | RPO ≤ 5 min, RTO ≤ 30 min using RDS Multi-AZ and S3 backups |
+| **Cost** | Budget target | Monthly AWS cost ≤ defined cap |
+
+## System Components — Spring PetClinic Microservices
+| Component | Role / Function | Dependencies | Notes |
+|----|----|----|----|
+| `spring-petclinic-admin-server` | Provides admin UI and dashboards | Microservices, Config Server | Central monitoring and management interface |
+| `spring-petclinic-api-gateway` | Routes external requests to microservices | Customers, Vets, Visits, GenAI services | Single entry point for all APIs; can handle load balancing |
+| `spring-petclinic-config-server` | Centralized configuration | Git repo | Supplies configuration to all microservices at runtime |
+| `spring-petclinic-customers-service` | Manages customer data | RDBMS, Config Server | Core domain service |
+| `spring-petclinic-vets-service` | Manages veterinary staff | RDBMS, Config Server | Lookup and assignment of vets |
+| `spring-petclinic-visits-service` | Manages pet visit records | RDBMS, Customers Service | Tracks appointments and visit history |
+| `spring-petclinic-genai-service` | Optional AI / generative service | Microservices, RDBMS | Provides a chatbot interface to the application. |
+| `spring-petclinic-discovery-server` | Service registry / discovery | All microservices | Enables service-to-service discovery |
+| RDBMS | Persistent storage | Customers, Vets, Visits | Single relational database supporting multiple services |
+
+## Architecture and Specifications
+
+### Project
+- Kanban as agile methodology
+- Breakdown of work and phases:
+	- Infrastructure Setup
+	- Service Orchestration
+	- Configuration Management
+	- CI/CD Automation
+	- Security
+	- Resilience
+	- Observability
+- Assignments:
+
+| Role | Responsibilities |
+|----|----|
+| **Cloud Architect** | Design AWS target architecture, network, and IAM structure |
+| **DevOps Engineer** | Build CI/CD pipelines, container orchestration, monitoring setup  |
+| **Dev Lead** | Containerize services, modify configs for cloud compatibility     |
+| **Database Engineer** | Migrate data from local RDBMS to AWS RDS, manage schema updates |
+| **Security Team** | Set up access and roles for services |
+| **Everyone** | Validate deployments, pipeline runs, rollback testing |
+| **Project Lead** | Manage Asana Kanban board, ensure alignment and progress tracking |
+
+### Source Code
+
+- Architecture Type: Microservices deployed via containers, managed by ECS/EKS, behind an AWS Application Load Balancer (ALB).
+- Review via pull request process:
+	- All commits merged via PRs.
+	- Peer review required before merging.
+- Vaildation: Run tests during pipeline build