K-Stack: My Production-Grade 3-Tier App on AWS EKS (Terraform, CI/CD, Observability) #173387
-
Select Topic AreaShow & Tell BodyHey everyone, I'm excited to share my latest project, K-Stack, an end-to-end deployment of a 3-tier application (React, Node.js, PostgreSQL) on AWS EKS. The goal was to build a truly production-ready system, leveraging: Terraform for full Infrastructure as Code (VPC, EKS, RDS) GitHub Actions for automated CI/CD to ECR Prometheus & Grafana for comprehensive observability and cost optimization insights My blog post dives deep into the architecture, implementation, and most importantly, the real-world debugging challenges I faced (like pg_hba.conf and ALB 502 errors) and their solutions. I'd love for you to check out the project and the detailed write-up: Project GitHub Repo: https://github.com/Ayushmore1214/K-Stack.git Blog Post: https://heyyayush.hashnode.dev/k-stack-architecting-a-3-tier-observable-application-on-eks I'm particularly interested in any feedback on: Alternative approaches to database connectivity in EKS. Best practices for monitoring costs in a similar setup. Any thoughts on optimizing the CI/CD pipeline. Thanks for taking a look! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
Hey @Ayushmore1214, Your K-Stack project sounds impressive! Deploying a 3-tier application on AWS EKS with Terraform, CI/CD, and observability is no small feat. The challenges you faced, like dealing with For database connectivity in EKS, have you considered using Amazon RDS Proxy? It can help manage database connections more efficiently, especially in serverless environments. Additionally, implementing horizontal pod autoscaling based on custom metrics (like database connection count) could enhance scalability. Your blog post provides valuable insights, and I'm sure many in the community will benefit from your experience. Looking forward to seeing how K-Stack evolves! |
Beta Was this translation helpful? Give feedback.
-
|
Hey @gpl-gowthamchand, Thank you so much for taking the time to read through the K-Stack project and for your incredibly insightful feedback! I really appreciate your kind words; battling those pg_hba.conf and ALB 502 errors definitely felt like a "feat" at the time! 😂 Your suggestions are spot on! RDS Proxy: That's a brilliant idea for managing connections more efficiently, especially with fluctuating pod counts. I hadn't explicitly built that into the initial design but it's a perfect next step for optimizing the database layer, particularly for better connection pooling. HPA with Custom Metrics: Absolutely! Implementing HPA based on custom metrics like connection count or even application-specific queues would be a fantastic enhancement for true reactive scalability. My current HPA is based on CPU/Memory, but this takes it to the next level. I'm always looking for ways to evolve K-Stack and apply best practices, so your input is extremely valuable. I'm constantly building and documenting new projects around cloud-native, DevOps, and AWS. If you're interested in seeing how K-Stack (and other projects) evolve, feel free to follow my GitHub profile or star the K-Stack repository for more updates like this! Thanks again for the excellent discussion! |
Beta Was this translation helpful? Give feedback.
Hey @Ayushmore1214,
Glad my suggestions resonated with you, It’s really inspiring to see someone so passionate about improving their project and adopting best practices
RDS Proxy and HPA with custom metrics are game-changers when it comes to scaling and reliability, especially for production-grade apps
Can’t wait to see what new innovations you’ll add next!
Definitely following your work and starring K-Stack,, Keep up the awesome work
Happy coding!