Systems generally cost money, there is rarely any escape from that. Whether that is down to license costs or platform hosting costs (cloud, onprem VM or physical tin), it all adds up.
This is one that's always really been in my head, maybe i'm just inherently tight with money, who knows? Different roles and levels will have different thoughts on the matter. Ideally, an eye on the pursestrings, and spending wisely on the things that need investment is best.
Spoiler Alert, some things will always really need cash, there is no way around that.
But if you're the tech, that's not your problem right? Someone upstairs has to write the cheques to pay for the hardware and software required. You design, build. configure and operate the systems....you don't PAY for the components that make up the systems.
But, let's think from a different point of view for a second. You have your requirements, the department has its projects, and the company has its goals. Budget is always involved at all levels... ok, maybe more of a focus on budget is held the wider the referred scopes become?
Ultimately, we're all part of the same entity, we need the company to succeed in whatever field it's in, both technical/performance AND sustainability levels.
A ridiculously simplified view.
A company who's products/services are so bad may not gain custom because of that fact. Ultimately, no income, no sustainability. But also:
A company with the greatest product in the world gaining all of the custom in the world means income, but if costs are crazy, also has little sustainability.
We're part of that system, maybe only the tiniest "worker ant" part of it but still a part. That said, doesn't that give us a responsibilty to aid that sustainability in any way that we can? One thing I definitely don't mean though, is selling yourself short with your experience and skillsets and direct renumeration either, respect your own worth always.
So, what I'm getting at is should we be incorporating that mindset into how we design and operate the systems we're responsible for.
The very nature of techies is that our primary focus is the technologies, and rightly so. We are also sometimes guilty of over engineering and/or underengineering.
What? How can you both Over and Underengineer something?
What I mean by that is:
Overengineering in terms of system design and product choices (if we have that responsibilty.)
Underengineering in terms of not making existing systems operate as optimally as possible... Ie... Tuning.
Don't get me wrong, we strive to deliver the best we possibly can, meeting the brief and surpassing it whereever possible. Its how we surpass the brief that we need to be cautious off.
Just to clarify, I mean surpass, not overachieve. If we can unexpectedly achieve great things without spending lots of cash, then thats overachieving in my book. And remind your managerial handlers on such things...see the point about not selling yourself short above.
Design
If there are multiple products all providing the same functionality... are some overkill? ie, the provide functionality that you don't (and importantly never) require?
If there are multiple editions of the same product, with varying feature levels, so you need all of those features to provide the service within your brief?
Is there an opensource option that is feasible? Opensource options have been serious alternatives for years now.
On the flip side of the coin...throwing complications in...
Are the required skillsets available already for the product? If not, what sorts of training do you/the team require? Chances are, the costing for that is someone else's decision.
Are the costs for a budget friendly option just going to get swallowed up in staff time for config/support/admin etc.
Growth! Systems usually have to have capacity to cater for a number of years, often meaning design big now, use later.
Taking an obvious example of SQL server here, with its multiple editions, all with increasing levels of feature sets, and drastically increasing license costs.
Do you need online rebuilds as you have no scope for regular(ish) maintenance? Or, HA/DR requirements that can't be provided with Basic A.G.s? Or huge amounts of addressible memory?
Being familiar with the product feature matrix (here) can often answer the "Do I NEED that?" vs. the "Do I WANT that?" question.
Would Standard work just as well as Enterprise for what we need? Do some have such tiny (granted, really tiny) requirements that Express can be used in places?
Is SQL Server the correct choice in the first place? Ie... Would something like Postgres be better? Are the skills available to support PG?
Are there design considerations/migration patterns that could be used to allow the increased featureset at no additional cost? i.e., the obvious one being licensing all cores in a VM Host servers with Enterprise so you can then load them up with VMs running enterprise without having to pay any extra?
Its a complex set of questions, with rarely ever a clear cut answer. But, redirecting a little bit of brain power for these points often helps avoid unneeded spend.
Thankfully, the other side of the fence is clearer cut...
Operations
I'm not a fan of just throwing hardware at a problem when there are other options. There, i've said it...it just seems like a cop-out to me. We wouldn't just replace an engine in a car that isn't running correctly without diagnosing and tuning it first? If that engine was at it's maximum potential already, THEN we'd think about replacement/go faster bits.
Tuning can be a double whammy, faster queries for happy users, and less greedy queries for happy servers.
We still need restraint however.
Ah, I did say clearer cut, not clear cut. We still wouldn't want to (or would be able to) spend weeks and weeks hunting for tuning opportunities either, nor spend masses of time to eek out every little bit of Ferrari matching performance for a query, when all the users require is a Ford. (Fast Fords and other marques are available)
Maybe tune to the point that the "heavy hitter" queries have been addressed, effectively tackling the low hanging fruit, then stop and review.
Think about it this way
Less reads, less disk and RAM usage.
Less CPU, less contention on the host CPUs.
Less host contention, potential to host more VMs on the same kit.
Even something that runs in the same duration as previously, but uses less resource is still a win. Maybe not for the users, but definately for the IT function.
In serious improvement "wins"...in its new tuned state, will it now perform acceptably on Standard Edition, and not require the large Enterprise Edition levels of allocated hardware?
Can we now consolidate DBs/Systems in their entirity?
When does this become particularly important?
Cloudburst.
Ah, this is where costs become tangable as we pay for exactly what we have allocated. This means the beancounters upstairs can see exactly what is being spent where. We have to 'technically' account for these specifications so can rarely afford wastage.
As I like to look for a silver lining in every situation, I think this can be a blessing as well as a curse.
It highlights our pricey systems straight away, and gives us budget tuning targets.
It gives us a tangible level of saving too when we can reduce the spec of a server/db/pool etc.
What it doesn't help with though is when we successfully tune, reduce the spec, save £1000s and are subsequently asked 27 times again over the next three years if we can reduce it further. I need to check, but violence against accountants in this particular situation may actually be legal.*
Azure gives some decent auto scaling/shut off options here too, making use of these is a quick win. It might be that you can expand further, and create Automation routines to handle other situations for powering down what's not needed at a particular time? All good things to think about.
Thanks for reading.
Scrooge McRod.
*May not be legal in your state/province/country. Justifiable perhaps, legal no.
Comments