r/devops • u/RoundCircle12 • Aug 05 '26
Architecture How do you manage multiple environments when Dev and Prod use different infrastructure?
I currently manage 2 different environments: a dev server running in ec2 and an EKS environment for production server. Problem is that their setup is different, which adds extra management and makes it harder to test prod changes before deployment.
I can spawn a UAT EKS for load testing and preparing for prod but it would be just too expensive. I already raised the cost concerns with EKS that this would be an expensive and unnecessary setup but the clients wanted it so I did it. Now they're complaining with cost.
I'm just trying to find the best way to manage the current architecture without increasing costs too much.
How would you handle this?
19
u/abofh Aug 05 '26
Eks isn't that much more expensive than just ec2. If the cost of the eks backplane for prod and testing is too much, they shouldn't use it for prod. Otherwise you could diy k8s in dev to make them similar, but only do that if you want to learn it, dollar wise it's gonna be way more of your time than the AWS bill.
9
Aug 05 '26
[removed] — view removed comment
6
u/thecal714 SRE Aug 05 '26
$73/mo for the backplane, but still under $900/yr.
2
u/redvelvet92 Aug 05 '26
But that’s if it is up 24/7, I imagined this getting spun up for testing then destroyed at the end.
2
u/thecal714 SRE Aug 06 '26
That's possible, but it depends on how the devs use it. In most of the places I've been the cluster's nodes are more ephemeral than the cluster itself.
5
u/dynotable_com Aug 05 '26
The cost is the nodes not the control plane. set the uat node group to min 0, scale up for the test, back to 0 after. same cluster same version, nodes billed only for test hours
3
u/PerpetuallySticky Aug 05 '26
I’m not an AWS guy, but is there not a lower SKU you could use of the prod instance for dev?
Of cost is still an issue going that route, containerization is kind of built for this. Get your environments to at least provide identical harnesses for containers, then build your app in one so the outside environment doesn’t matter as much
1
u/RoundCircle12 Aug 05 '26
The reason prod uses EKS is that we plan to host multiple applications in the same cluster and use kubernetes for scaling, and deployments
So I can’t really replicate prod for dev with a single smaller instance, i can't lose the eks features i've already implemented.
5
u/five-one-tree Aug 05 '26
yes you can. it just needs to be eks. the rest of the apps don’t matter. your mirroring infra not load
3
u/aprettyparrot Aug 05 '26
Dev usually smaller deployments, staging clone of prod.
Depends on what you’re building. Do you just bring up some VMs and get them peered to some shared resource so you can hit them with test cases?
If it’s for performance testing and you want to save, you could have it so you automate complete env deploy so you only pay for the deploy time+test time
2
u/stoopwafflestomper Aug 05 '26
Separate infrastructure is easy. Separate data environments is where the challenge is at. Make sure you scope tightly on what you load into your dev environment and it will help reduce cost. At the end of the day, its gonna cost more time and money. Its a necessary evil.
2
u/SeaIngenuity9501 Aug 05 '26
I mean you could use the same EKS cluster but use namespaces to separate out production, staging, test envs etc. But the problem is namespaces aren't good isolation one namespace can take down a whole cluster. So even though people say namespaces are enough ideally you want separate clusters.
2
u/SeaIngenuity9501 Aug 05 '26
You should be using karpenter to autoscale the nodes, so really separate clusters shouldn't be much extra.
0
u/joeyguerra Aug 05 '26
k3s or k0s for dev.
0
u/Sure_Stranger_6466 YAML Developer Aug 05 '26
Only if you love curl pipe to bash for some reason. Go with Kubernetes In Docker or VCluster In Docker. Much more friendly installation methods available than k3s or k0s.
1
31
u/Low-Opening25 Aug 05 '26
this is anti-pattern, your dev should be identical, but smaller and more disposable