[HN Gopher] Grafana: Why observability needs FinOps, and vice versa
___________________________________________________________________
Grafana: Why observability needs FinOps, and vice versa
Author : StratusBen
Score : 19 points
Date : 2025-02-06 19:13 UTC (3 days ago)
(HTM) web link (grafana.com)
(TXT) w3m dump (grafana.com)
| floating-io wrote:
| Seriously? Not everything needs to be xxxOps. And if you need a
| "FinOps" team to manage your cloud cost, I would argue that
| there's something wrong with your whole damn paradigm.
| moandcompany wrote:
| The _Ops team needs an _Ops' team.
|
| The game here is defining parts of the job away to be someone
| else's job or responsibility.
| arccy wrote:
| we invent new functions to use to decorate our CVs with
| aledalgrande wrote:
| I had the same thought. Why do we need to keep coming up with
| weird names/acronyms/portmanteau
| MortyWaves wrote:
| Sadly it's one of the only ways of getting through the thick
| skulls of dumb middle management that seem to always be
| leading software projects despite having no technical
| background.
|
| If it's not got a familiar marketing thing going on, they'll
| refuse to acknowledge it even if their devs are practically
| begging for it.
| aledalgrande wrote:
| > dumb middle management that seem to always be leading
| software projects despite having no technical background
|
| Or you change to a company with capable & technical middle
| management :)
|
| It always blows my mind when people say "management does
| not have to be technical".
| aqueueaqueue wrote:
| What about a 5k engineer org. Having 10 finops people would
| make it 0.2% of the workforce. Those people help surface the
| information for other teams to act.
| mvdtnz wrote:
| > if you need a "FinOps" team to manage your cloud cost, I
| would argue that there's something wrong with your whole damn
| paradigm.
|
| How would you manage your cloud costs if you ran a company of,
| say, 4,000 engineers? Balancing the needs of delivery teams to
| build their technology with the needs of the business to manage
| costs. Do you think every single team should directly report
| their cloud costs to the CFO? Or at that scale does it make
| more sense to report costs to another individual? And when that
| needs to scale, maybe we give that individual a team?
| senko wrote:
| Wait until you hear about "RevOps".
|
| At this point I'm waiting for someone to start flogging
| "CodeOps".
| j0rdans wrote:
| I think for most smaller orgs you can get away with an off the
| shelf product to surface some more basic cost stuff. In
| relatively large engineering orgs, you're looking at optimising
| on stuff like cross-region calls to save millions a year so
| yeah there's a good reason to invest in cloud cost management.
| kozikow wrote:
| I am big fan of "cost monitoring".
|
| In my previous company I had a good setup for costs monitoring -
| including release to release comparisons, drill downs,
| statistics, etc.
|
| After each release I looked at this data. It saved a lot of $, by
| simple fixes like "why we are calling this API twice?".
|
| It also quite some issues that weren't strictly customer related,
| but weren't apparent from other type of data (you will always
| have some "unknown unknowns" in your monitoring, and costs data
| seem to be pretty wide net to catch some of those)
| EfficientDude wrote:
| What's Grafana? I see it mentioned here a lot, nowhere else
| though. Is it a YC property?
| brunoarueira wrote:
| Grafana is mostly knows for the most used interface to query
| Prometheus and create dashboards for collected metrics
| MortyWaves wrote:
| And more recently inventing and reinventing Prometheus
| alternatives. It's a bit much trying to keep up.
| brunoarueira wrote:
| On my last job, the company was using NewRelic (for two
| environments we was using at the time) which had an ok cost and
| "suddenly" we'd been forced to use Datadog which costs way over
| for our budget and after the person responsible for the change
| and integration see the estimated high costs, started to cut
| everything possible to keep it low. So, our tools degraded and we
| wasn't able to test things on staging and collect metrics like we
| was when using NewRelic. FinOps is certainly a good approach, but
| we need it from the start!
| jsiepkes wrote:
| One of the advantages of self-hosting is that you don't need this
| level of FinOps. You also don't have to live in fear of bill-
| mageddon.
| danpalmer wrote:
| And one of the disadvantages is that you can't solve problems
| by just spending more. It's a real trade-off, and too often is
| simplified to one option being obviously better.
| NotGMan wrote:
| You know you have a problem when you're afraid to add a few more
| metrics because the bill might get too high.
___________________________________________________________________
(page generated 2025-02-09 23:00 UTC)