July 23, 2017 at 10:01 am
Comments posted to this topic are about the item The Financial DBA
July 24, 2017 at 1:57 am
I can see a new post in the offing
Financial Controller of Cloud Services?
Bagsy I'm not it.
Definitely good practice to check your statements though. I've come across a few people who have turned things on and forgotten about them until they've got their statement in.
cloudydatablog.net
July 24, 2017 at 2:07 am
Tags, tags, tags!!!!
July 24, 2017 at 3:00 am
We have someone here whose job it is to manage licences & subscriptions across IT. It depends on the size of the organisation of course, but this doesn't need to be something else a DBA or developer has on their plate.
July 24, 2017 at 4:41 am
It's definitely a problem area. As the costs are often low is it even worth worrying in some cases? In general because the costs are ongoing, yes it is.
As a poster alluded to above you might use tags (or some other non-technical properties) to at least attribute what something is for, whose domain it is in.
July 24, 2017 at 6:32 am
Arguably, moving services to the cloud is going to be only a little different from when you manage the services locally. You're still going to have to keep track of that one reporting server that only gets used once per quarter (or worse, once a year,) but then spends the remainder of the year idle. The difference being, with an on-premise, you'd probably just leave the box on and eat the costs of electric, cooling, patching.
With a cloud server, you might shut it down to avoid paying charges for it.
But what about the process some developer stood up in the cloud, for a very particular use-case, but it never got documented? That's your cancelled service contract disruption waiting to happen.
Over time, I think as funbi and Dalkeith said, organizations will have someone assigned to monitoring the cloud service bills for anomalous charges, tracking down why there's certain charges (oh, that service? Yeah, Joe stood that up a couple months ago for the developers, but I don't know if they ever used it and Joe left a month ago,) and in general riding herd on the cloud services. Smaller companies, this might fall to the DBA or developers, with a dash of the accounting people thrown in.
Short term? Yeah, I can see companies finding services they'd been paying for, for months, but weren't using because some developer stood it up and forgot about it when they were done.
July 24, 2017 at 6:58 am
We learned some hard lessons that these charges can add up fast. We found out we were spending $5 or $6,000 a month simply because azure machines were left up when no one was using them. We instituted a policy to shut down azure machines at the end of the day (when possible) and especially over the weekend. Made a difference on the order of 70%. Frankly, this is one of the reasons I'm not a big fan of the public cloud. They can charge me whatever they want and I really can't validate that they're charging me correctly. Eventually, companies are going to figure out it's safer, faster, and cheaper to buy a server and create VM's locally. That's what we did and the cost of a pretty powerful server was less than one month of azure charges.
"Beliefs" get in the way of learning.
July 24, 2017 at 7:17 am
I see this responsibility (maintaining an inventory of Azure assets owned by the enterprise) falling under the umbrella of Platform Operations or Data Governance, not necessarily the DBA team. Not all Azure accounts are SQL related, and not all Azure SQL instances are production; they can be spun up by developers using the corporate MSDN account. Of course the DBAs should report what production databases are new or retired.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 24, 2017 at 8:42 am
call.copse - Monday, July 24, 2017 4:41 AMIt's definitely a problem area. As the costs are often low is it even worth worrying in some cases? In general because the costs are ongoing, yes it is.As a poster alluded to above you might use tags (or some other non-technical properties) to at least attribute what something is for, whose domain it is in.
Careful about assuming these are low. I have some customers spending tens of thousands of dollars a month. For a most hosting providers, this is a package of things bundled. For the cloud, this is a series of disparate services and new ones can be added all the time.
July 24, 2017 at 8:51 am
This can easily become a mess. Billing is messy and can be very obscure (unlike physical servers where you buy it once), and there is plenty of room for forgotten resources or misunderstood items to become buried in a big bill of hundreds or even thousands of item lines.
We had that with our old phone system, hundreds of dollars were spent each month for phone lines and service that hadn't been used in years. And yet tracking that down required an intensive effort requiring lots of hours in itself.
...
-- FORTRAN manual for Xerox Computers --
July 24, 2017 at 8:54 am
Very interesting topic and good points raised to be considered.
See these 2 links, they go hand-in-hand:
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-using-tags
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-policy
It's like anything else, you need to plan carefully. You could end-up with a sporadic sprawl and things can get out-of-hand fairly quickly. Nothing different to having a MSL or CMDB for your on-premises stuff, albeit in-house owned or outsourced. Management is key.
July 24, 2017 at 9:03 am
It's not that the DBA is responsible for all charges, but they might have to work with the person responsible for tracking to ensure that all database related charge have some value. Over time, especially with staff changes, this might not be as easy as one thinks.
July 24, 2017 at 9:09 am
nico.botes 119922 - Monday, July 24, 2017 8:54 AMVery interesting topic and good points raised to be considered.
See these 2 links, they go hand-in-hand:
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-using-tags
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-policy
It's like anything else, you need to plan carefully. You could end-up with a sporadic sprawl and things can get out-of-hand fairly quickly. Nothing different to having a MSL or CMDB for your on-premises stuff, albeit in-house owned or outsourced. Management is key.
Planning carefully is hard. I think some of the RG stuff helps, but I used Azure for months before I realized these were there. Some of the serverless stuff makes this harder and harder. Having dealt with tags in other environments, how does someone know which tag to use for a new function? what if it's for two apps? What if it gets used in production, and then superseded with a new version? One thing we often may do is want to keep two versions live, in case we have an issue over the next few days. Who's going to check that the old one is removed? Or worse, what if some code uses the old rarely and there are still charges?
Imaging the scope of functions your developers create in code now.
July 24, 2017 at 9:11 am
Absolutely, 100% correct. From my experience, the DBA Team are only responsible for PaaS and IaaS SQL, and have access through the Azure Portal, but the Management\Enterprise Portal are managed through the Project Management Office. Platform Engineering Teams and other ares support their respective areas: Services, Networks, Storage etc.
Definitely not easy at all, especially when you get thinking at Enterprise level, and having multiple subscriptions across different domains.
July 24, 2017 at 9:12 am
Steve Jones - SSC Editor - Monday, July 24, 2017 9:03 AMIt's not that the DBA is responsible for all charges, but they might have to work with the person responsible for tracking to ensure that all database related charge have some value. Over time, especially with staff changes, this might not be as easy as one thinks.
Agreed, it's a massive headache. Tags are good but they only go so far, and (when I last checked, anyway) they're not mandatory. We built some tagging logic into our ARM templates, but however good a job you do of that side of things, the hardest bit is actually getting the right department to stump up the £20K they accidentally spent by leaving an unused (test!) data warehouse running for weeks on end.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply