Anti-Patterns in Tech Cost Management: Not considering scale
Series Index
Introduction
Anti-Pattern 1: Not considering scale
Anti-Pattern 2: Bad cloud strategy
Anti-Pattern 3: Inability to assign/attribute costs
Anti-Pattern 4: No metrics or bad metrics
Anti-Pattern 5: Not designing it in
Anti-Pattern 6: Cost management as a standalone
Anti-Pattern 7/8: No ongoing reviews (current and potential)
Anti-Pattern 9: Across the board cuts
Anti-Pattern 10: “A tool will solve the problem!”
Anti-Pattern Bonus: Don’t do rewards programs!
A few thoughts: Three things you can do right now, for yourself and your team
Wrap up
Today’s anti-pattern is one I have seen trip up many organizations.
One of the repeating themes of this presentation is “You are not Google!” But many companies behave as if they are, adopting frameworks that are far too expensive, architectures that are too elaborate, and tools that they can’t possibly manage given their size/experience. One can argue that much of what has passed for “DevOps” in recent years has been little more than adopting practices of large successful companies that are trying to solve problems that you don’t have and never will.
My friend Corey Quinn refers to this as “cargo culting1” an idea: adopting a practice that generated desirable results in one context, but not recognizing that the context it is being used in is different. In many cases there may not be a good understanding of how those practices and results are connected. He elaborates on that point in this talk.
Large companies can afford to invest a lot of money in cost management and efficiency. In my previous role at AWS, I was responsible for ordering infrastructure for an organization whose infrastructure value was well into the 9 figures. In my last year in that role, I ordered over $70m of infrastructure to manage growth. Achieving small (1-2%) gains in the utilization of our infrastructure could easily pay my salary and that of the entire team around me. By compounding lots of little gains, I estimate that my programs saved about $42m in three years.
But if the annual budget was $7m, rather than $70m, it would have been tough to justify my salary. If it was $700k, it would have been impossible to justify more than a cursory evaluation of utilization levels every 6-12 months. Cargo-culting the AWS approach would have been a complete failure that would have cost far more than it saved.
Different businesses have different constraints. Businesses operating at large scale can and should invest in efficiency, as that is a big part of the value proposition they deliver to their customers. Smaller businesses have a lot going for them, but “beating the big competition on price” is never what they offer. My old consulting clients surely tried to limit their costs, but they also understood that the problems they had to solve to be successful were mostly not problems of technology cost.
The scale of your technical operations/budget places a hard limit on how much you can afford to spend on cost management. Any efforts you make must fit into that context. You are not Google. Don’t try to be.
Join us at the SoCal Linux Expo (SCaLE 21x) in Pasadena on March 14-17. My talk will be on Saturday the 16th. I will also be speaking at UpSCaLE on Friday night, and running the Observability track on Saturday and Sunday.
It’s $90 for four days of great content. (If you know me, ping me as I may have a few discount passes left.)
- I dislike the term “cargo cult” as it is not an accurate description of these groups. The term mostly reflects a poor understanding of what was going on, invented by initial (Western) observers. Suffice it to say that these groups had less to do with the cargo itself than the cultural/sociological implications of an specific culture meeting — and being disrupted by –an unfamiliar, wealthier and far more powerful one. ↩︎