Smart Building Management Platform - On-Prem to AWS EKS Migration

Business Problem

The platform had multiple Scala, Node.js, Java, and Angular services running outside a consistent cloud-native deployment model. Releases required stronger repeatability, health validation, observability, and support documentation before the workload could be treated as production-ready on Kubernetes.

Architecture

flowchart LR
  Users[Users] --> R53[Route 53]
  R53 --> ALB[Application Load Balancer]
  ALB --> Ingress[AWS Load Balancer Controller]
  Ingress --> EKS[AWS EKS Cluster]
  subgraph VPC[AWS VPC]
    subgraph Public[Public Subnets]
      ALB
      NAT[NAT Gateway]
      IGW[Internet Gateway]
    end
    subgraph Private[Private Subnets]
      EKS
      Pods[Scala Node Java Angular Pods]
      RDS[(Private Data Layer)]
    end
  end
  Dev[Git Commit] --> Jenkins[Jenkins CI Pipeline]
  Jenkins --> ECR[Amazon ECR]
  ECR --> Argo[ArgoCD GitOps Sync]
  Argo --> EKS
  EKS --> CW[CloudWatch Logs and Metrics]
  EKS --> Probes[Liveness and Readiness Probes]
  IAM[IAM Roles and Policies] --> Jenkins
  IAM --> EKS
  SG[Security Groups] --> ALB
  SG --> EKS
  SG --> RDS

My Responsibilities

• Owned the DevOps migration path from self-managed deployment patterns to AWS EKS delivery workflows.
• Created and documented Dockerfile patterns for Scala, Node.js, Java, and Angular workloads.
• Built Jenkins pipeline stages for checkout, build, image tagging, Amazon ECR publishing, and deployment handoff.
• Defined Kubernetes deployment, service, ingress, ConfigMap/Secret reference, liveness probe, and readiness probe patterns.
• Documented ArgoCD GitOps sync, ALB ingress routing, CloudWatch validation, rollback steps, and support handover.

Implementation

• Separated application build concerns from runtime configuration so images could move across environments predictably.
• Standardized readiness behavior so traffic is routed only to pods that can serve requests.
• Introduced liveness checks to recover stuck application processes without manual intervention.
• Aligned image promotion through ECR with a GitOps deployment flow for controlled Kubernetes changes.
• Captured operational runbooks for deployment verification, logs, rollback, and KT.

Challenges

• Different application stacks had different health endpoint behavior.
• Service startup timing had to be respected before routing production traffic.
• Deployment ownership needed to move from manual knowledge to documented, repeatable workflows.

Solution

The solution combined automation, clear infrastructure boundaries, operational validation, and documentation-first handover. The design focuses on traceable releases, least-privilege access, predictable runtime behavior, and observable production systems.

Code Snippet

Representative public-safe snippet showing the type of implementation pattern used.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application-service
spec:
  template:
    spec:
      containers:
        - name: app
          image: account-id.dkr.ecr.region.amazonaws.com/app:release-tag
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
            initialDelaySeconds: 20
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080
            initialDelaySeconds: 45
            periodSeconds: 20

Deployment Flow

1. 1

   Discovery and target architecture

2. 2

   Dockerization

3. 3

   CI/CD and ECR flow

4. 4

   Kubernetes manifests and ALB ingress

5. 5

   Health checks, monitoring, rollback, handover

Validation

• Verified deployment health before routing user traffic.
• Reviewed logs, metrics, events, and runtime configuration.
• Documented rollback and post-deployment checks for support teams.

Monitoring and Security

• Monitoring focused on logs, runtime status, health checks, alarms, and deployment evidence.
• Security guidance covered IAM roles, security groups, secrets handling, and private network boundaries where applicable.
• Operational notes included backup, restore, rollback, and incident response expectations.

Outcome and Impact

• Improved release repeatability through containerized builds and GitOps deployment control.
• Improved Kubernetes stability through liveness and readiness probes.
• Improved support readiness through CloudWatch checks, rollback documentation, and handover notes.

Lessons Learned

• Reliable DevOps delivery depends on validation, not only deployment automation.
• Runbooks and handover notes reduce operational risk during production support.
• Health checks, logs, access boundaries, and rollback steps should be designed before go-live.

Related Incident Experience

• Kubernetes deployment issue
• Storage lifecycle recovery
• Service startup failure
• Pipeline rollback

Pipeline Screenshots Placeholder