IBM acquires Kubecost
(newsroom.ibm.com)72 points by ludikoff 3 days ago
72 points by ludikoff 3 days ago
I've built many projects where "the cloud" is less expensive than the alternatives
The last big one: replacing a backbone country-wide network in France with AWS
It is far less expensive due to the low bandwidth requirements (and also the ability to go full managed services)
What stops AWS from "increasing the price" until it is very close to what you were paying before, if not more?
Competition?
I've never had AWS "increase the price." Is there some reason to suspect this is a thing to actually worry about?
Nothing, and they do that regurarly
What stops dark fibers or hardware providers from "increasing the price" ? Nothing, and they do that too
You moved the goalpost from "cloud is definitely more expensive" to "well it isn't but maybe it will be for you someday" and alluding to vendor lock-in.
Vendor lock-in is a concern with cloud platforms but doesn't relate to the app in the submission.
> Do you need a tool to tell you that the cloud is more expensive?
Yes. If you want to make an argument for change in a business environment you need numbers.
It’s the wrong question usually. The right question is how many more features and what revenue growth would you get by using cloud? How many less people would you need to employ? Would you need to manage facilities - worry about hardware, power, diesel generators, etc.?
Cloud is more expensive. But you’re not stuck with capacity and sysadmin tickets.
> Do you need a tool to tell you that the cloud is more expensive?
More expensive than what? Doing your own?
That depends on what you are doing. Often, the cloud is cheaper if you factor in the human cost. I've seen many spreadsheets that just quote the hardware costs.
Not only is it potentially cheaper, it can be better than rolling your own stuff in-house.
Kadokawa can tell you all about how their in-house shit (literally, Japanese suck at computers) got pwned while the stuff they had in the cloud (I hate the term, but it is what it is) were unscathed.
Keeping in-house has its benefits, but the costs are also steep.
Unless you are currently in possession of a bunch of latest generation NVIDIA DGX, which many people are, 99% of your workloads are OpEx.
They might be CapEx in some imaginary, nonactionable accounting sense. Like maybe you are mislabeling exclusive rights to dig holes in some neighborhoods as telecommunications equipment capital expenditures. Just pay an accountant to make up stories for you. You don't need the tool.
Meanwhile, we’re transitioning to on-premises infrastructure due to the increasing complexity of cloud services. Kubernetes and Docker are powerful platforms—we love them—but they were never meant to be cost-driven. Kubernetes is already incredibly efficient. However, surviving cloud costs and avoiding its traps requires granular cost control—far beyond just monitoring RAM, network, or CPU usage. It’s become overwhelming.
In a nutshell, any K8S deployment on-premises tends to be inherently optimized, saving a significant amount of time and resources. I have new servers and old servers in the same cluster, that is epic.
Modern FinOps often feels like a frustrating exercise: Should I choose 2x 2XXL instances or 4x 8XL instances? The conversation rarely focuses on optimizing software performance or database efficiency. Instead, the cloud has turned into a maze of cost centers, where it’s easy to get lost in ‘managing’ the cloud rather than building valuable products for end users.
sorry optimizing sql queries isn't a priority this quarter, could you write a business justification for it so we can ask in the next sprint planning if it can be scored against our business needs?
thanks!
p.s. we got some complaints about slowness on a few pages. can you schedule some time to sync up and take a look? we need to get this solved!
That’s exactly my point. Instead of optimizing software, FinOps nowadays focuses on optimizing costs. While they might seem similar, they couldn’t be more different. We spend 100% our time optimizing our software, databases, etc. if we need more capacity we just add a new server to the cluster. But this hard on the cloud, easy onprem.
Which part is hard on the cloud? Optimization or adding capacity?
IBM thrives on complexity—that’s the core of many of their products and business model. The fact that even they are getting into ‘cloud cost optimization’ should be a signal for everyone to rethink public cloud strategies.
I’d contend IBM thrives on selling hidden complexity to those who don’t know better.
But is that what's going to happen? IBM has acquired a lot of clever things, only to not really utilize them and just let them wither away.
IBM bought RedHat 6 years ago, can we truly claim that they've done something useful with that purchase? I get that they haven't managed to mess it up like they did with SoftLayer, but they've also haven't done much RedHat couldn't do on its own.
Anonymous for obvious reasons: speaking as a current Red Hat employee I disagree with the statement “they haven’t managed to mess it up like they did with SoftLayer”.
IBM policy has definitely infected the company and while outwardly the host still resembles its old self, the infection is spreading and the host is as good as dead.
I some point hoped that IBM and Red Hat would evolve into a ‘reverse takeover,’ where Red Hat’s culture would eventually take precedence over IBM’s. According to many friends, that outcome is still far from happening
there is a certain term well known amongst IBMers: "Blue washing"
R.I.P. Kubecost
I dumped kubecost (gross UI, shitty helm chart) for opencost. Shortly after, AWS eliminated any need for either of them.
Do you need a tool to tell you that the cloud is more expensive?
Do you need a tool to tell you that your company underpays or is bad at recruiting? Or maybe that you do something boring that people don't want to work for?
IMO Keda is the more important product in this space, because it translates business requirements like max queue wait time into compute resources.
If you are operating in a way where small cost differences decide if you are break even if you have already failed, no amount of "FinOps" will stop your trend from going to zero. It is delaying the inevitable.