I manage a firm that hosts environments for around 500 clients, each needing Production, Staging, Dev, and Test setups. Currently, about 40% of our workloads run on Azure, and we aim to ramp that up to 90% in the future. However, our Staging, Dev, and Test subscriptions in Azure aren't set as Dev/Test environments, which means we're incurring full Production costs for these resources. A previous IT Manager insisted on this setup, claiming that even though they aren't live environments for clients, they are treated as Production by us since we charge clients for using them. These environments are strictly for development and testing purposes and do not handle actual Production data. Has anyone encountered a similar situation, and is that manager's statement valid?
4 Answers
That makes sense because you're essentially using those as staging environments. Maybe you could explore analyzing your deployment processes and infrastructure to cut costs. Also, think about whether every client really needs their own Dev environment or if you can consolidate things to save some cash.
Your comment touches on a critical point. The way you frame how these environments are used matters in terms of costs and SLAs. You should also consider that if there’s an outage on a ‘dev’ subscription, your customers could be severely impacted without any support from Microsoft.
Yep, totally agree! It’s really about managing risk along with costs. Better to be safe and stick with Production settings in this case.
It's a tricky question. In my experience, those resources could be considered Production, especially since they impact service delivery. If they go down, it might breach your service contracts. It’s really up to your management to finalize this, but it certainly feels like they should be treated with that level of importance.
That's a good point! I see how they directly impact our service to clients, which might support the idea that we should keep them as Production resources.
One thing that helped us include cost awareness from the start was implementing automated anomaly detection. This way, you can catch unexpected cost spikes before they turn into a big issue. Make sure stakeholders get regular reports—this keeps everyone accountable for their spending without bogging down DevOps.
That sounds like a great approach! I think getting everyone on the same page about costs will be really beneficial for us moving forward.
Exactly! It’s great that you're looking into this now. We’ve been trying to streamline our environment management too, and those savings can add up quickly.