I've been developing a microservices project for several months and currently have it running locally with kind. I'd like to deploy it to AWS or GCP using Terraform so I can practice real cloud and Kubernetes workflows, record a few demos for my resume, and destroy the environment afterward to control costs.
The stack includes five Node.js services, five PostgreSQL databases, Redis, Kafka, Prometheus, Grafana, Loki, and Alloy. The application images are stored in a container registry. For the stateful components, I'm using custom Kubernetes manifests with StatefulSets and headless Services. Locally, ingress is handled through the Gateway API with cloud-provider-kind.
My budget is limited because I'm a college student, so I'm trying to decide between managed Kubernetes such as EKS or GKE and running Kubernetes or k3s myself on one cloud VM. I'd also like to understand the cheapest practical way to expose the application without paying unnecessary load balancer charges.
For a portfolio project, is it reasonable to run PostgreSQL, Kafka, Redis, and the observability stack inside Kubernetes, or would hiring managers expect managed database and messaging services? I'd appreciate advice on provider choice, routing, Terraform workflows, cost-saving options, and common pitfalls.
2 Answers
For this particular stack, a small self-managed VM may be more realistic than a managed Kubernetes cluster. EKS or GKE adds useful production experience, but the control-plane and networking costs can exceed the price of the workload itself. A single appropriately sized VM running k3s can demonstrate Kubernetes and Terraform without creating several fixed cloud charges. Use an inexpensive static IP or a reverse proxy for the demo, and destroy the VM when you’re finished.
If the goal were only to host a demo, Cloud Run or another serverless container platform would probably be simpler and cheaper than Kubernetes. Since you specifically want Kubernetes and Terraform experience, though, it’s reasonable to keep the Kubernetes deployment. Just make the environment intentionally temporary and avoid leaving managed databases, load balancers, disks, or public IPs running after the demo.
That makes sense. I’m mainly trying to balance learning the managed-Kubernetes workflow with keeping the demo affordable, so I may compare a small k3s deployment with one short-lived EKS or GKE deployment.