I'm seeking advice on how to persuade leadership not to treat Kubernetes as the only solution for every workload. I work with a client that runs several internal business applications on Azure, interfacing with various data sources like Databricks, SQL Server, and Postgres. A year ago, different teams managed their own apps, but a recent push moved everything to a few AKS clusters for better management and cost reduction. Now, the situation is chaotic. We face deployment bottlenecks, overprovisioning issues, and a lack of understanding among developers about Kubernetes. I'm frustrated that even minor scripts end up in AKS, and I need strategies or arguments that have worked for others in convincing decision-makers to consider other, more appropriate solutions for different tasks. Any insights on this would be greatly appreciated!
5 Answers
You should definitely include costs in your conversation. Showing that workloads aren’t charged back to teams can often resonate with leadership. Keeping a close eye on costs can motivate teams to manage their resources more effectively and avoid wasting money.
It sounds like the core issue is execution rather than Kubernetes itself. If your team had proper tagging and archiving for experiments, it could mitigate a lot of your concerns. It’s essential to build a robust platform and empower developers rather than just throw everything into Kubernetes without thought.
One practical approach could be to give each team a deadline to label their resources with ownership details. If they don’t, delete the unused ones. This could encourage better management. Also, tagging everything in your cloud resources can help track costs and resource usage more effectively.
Honestly, I feel like a lot of these workloads could run better on Kubernetes if managed properly. Maybe it’s time to improve resource management instead of just blaming Kubernetes. Have you thought about exploring on-prem Kubernetes solutions to reduce costs?
I’m on the other side here. Keep pushing for Kubernetes! It’s all about automation and having DevOps set everything up with Docker and CI/CD tools. If devs aren’t managing infrastructure, they won’t feel the pain of their mistakes, so they might not fix issues. I think a more hands-on approach from developers is key.
True, but isn’t it essential for developers to take ownership? It encourages accountability, and Kubernetes is built to empower them. Otherwise, they miss out on understanding how to optimize deployments.
That's a bold move; just be careful about the potential for outages! Establishing standard pipelines and providing support can not only improve dev experience but also foster better cost awareness.