[HN Gopher] IBM acquires Kubecost
___________________________________________________________________
IBM acquires Kubecost
Author : ludikoff
Score : 60 points
Date : 2024-09-17 13:47 UTC (9 hours ago)
(HTM) web link (newsroom.ibm.com)
(TXT) w3m dump (newsroom.ibm.com)
| Ralley37 wrote:
| Smart acquisition, Apptio + Turbonomic + Kubecost is a strong
| FinOps suite
| jttam wrote:
| Kubecost's position in the K8s community also will help
| OpenShift along with Apptio+Turbonomic... their OpenCost
| initiative is very clever, too
| mrweasel wrote:
| 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.
| fortylove wrote:
| As someone who used SoftLayer shortly after it was acquired
| (and it was still pretty much untouched by IBM) - SoftLayer
| was pretty bad to begin with. And I'm not only comparing it
| to AWS. It was bad even when compared to RackSpace.
| redhatcordyceps wrote:
| 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.
| rafaelturk wrote:
| 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
| alephnerd wrote:
| Yep!
|
| Strong PMF with the existing hybrid cloud play that RHEL and
| OpenShift provides.
|
| Cost Management and Auditing is always a major pain point for
| any Platform team so this will be well received.
| doctorpangloss wrote:
| 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.
| athorax wrote:
| One of the main value adds of these tools is to help identify
| and categorize workloads into OpEx and CapEx buckets
| doctorpangloss wrote:
| 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.
| JackSlateur wrote:
| 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)
| doctorpangloss wrote:
| What stops AWS from "increasing the price" until it is very
| close to what you were paying before, if not more?
| JackSlateur wrote:
| Nothing, and they do that regurarly
|
| What stops dark fibers or hardware providers from
| "increasing the price" ? Nothing, and they do that too
| doctorpangloss wrote:
| So you're proving my point. The tool cannot tell you the
| single most important factor in pricing.
| Spivak wrote:
| The single most important factor in pricing is accurately
| predicting the future, as we haven't invented time travel
| yet we're gonna call that a wash. Here's a tool that
| measures everything else.
| doctorpangloss wrote:
| Yep! You are agreeing with me. The tool measures a bunch
| of noise, essentially, since it cannot predict Amazon's
| pricing roadmap. Whereas the Kubernetes ecosystem has
| plenty of valid forecasting tools, such as one which
| forecasts compute usage, that are valuable.
| akira2501 wrote:
| Competition?
|
| I've never had AWS "increase the price." Is there some
| reason to suspect this is a thing to actually worry about?
| klingoff wrote:
| Price is supposed to cut in half every 3-4 years, if it
| isn't it is largely because cloud vendors can't bear to
| take less and hope there really is that much more volume
| of half as valuable computing to do.
|
| The things they sell as an average CPU performance, etc
| are basically the average when their cloud began.
| MrDarcy wrote:
| Moore's law came to an end about a decade ago. Since the
| clouds began a vcpu then is largely the same as a vcpu
| today.
| klingoff wrote:
| No, Moore's law is fine. If the CPU takes half the real
| estate and uses half the power but costs the same it is
| the same perversion of the market expectations of Moore's
| law as if you don't deliver twice as much in the same
| price.
|
| From Wikipedia:
|
| Some forecasters, including Gordon Moore,[122] predict
| that Moore's law will end by around 2025.[123][120][124]
| Although Moore's Law will reach a physical limit, some
| forecasters are optimistic about the continuation of
| technological progress in a variety of other areas,
| including new chip architectures, quantum computing, and
| AI and machine learning.[125][126] Nvidia CEO Jensen
| Huang declared Moore's law dead in 2022;[2] several days
| later, Intel CEO Pat Gelsinger countered with the
| opposite claim.[3]
| lyu07282 wrote:
| I think it's just because if you believe in economics it
| would suggest AWS must've lowered the price per vCPU
| since CPUs have become significantly more efficient in
| the last decade. Obviously that didn't happen...
| akira2501 wrote:
| > if it isn't it is largely because cloud vendors can't
| bear to take less
|
| Cloud vendors have to buy products themselves. If their
| prices aren't changing then we have a market problem that
| extends beyond AWS.
|
| This is probably why Graviton exists and provides cheaper
| VMs and Lambdas running on it.
|
| > as an average CPU performance
|
| CPU performance, in the cloud, is effectively free. You
| can overcommit and time share the CPU.
|
| What you're paying for is memory.
| klingoff wrote:
| > If their prices aren't changing then we have a market
| problem that extends beyond AWS.
|
| How do you get there? Even in markets without any
| specific lock in, the top brands charge prices that have
| nothing to do with raw costs.
| akira2501 wrote:
| > with raw costs.
|
| You've mistaken my point about "total cost of customer"
| for "raw cost of materials."
|
| The "top brands" probably do marketing. That costs. They
| probably have better supply chain availability. That
| costs. They probably have on site engineering support
| they can offer you. That all costs.
|
| What you're highlighting is the cost of CPUs has little
| to do with raw materials and with all this other
| attendant process. That has been true since a few short
| years after the product started existing.
| CapeTheory wrote:
| > Price is supposed to cut in half every 3-4 years
|
| Citation needed
|
| > if it isn't it is largely because cloud vendors can't
| bear to take less
|
| Even if we choose to accept your original premise, I
| think anti-competitive behaviour is much more likely than
| "can't bear to take less".
| doctorpangloss wrote:
| New public IP charges and Kubernetes base pricing both
| doubled my bill.
|
| Spot pricing is kind of a black box, and it also makes no
| sense.
| hhh wrote:
| When did EKS costs change?
| unethical_ban wrote:
| 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.
| doctorpangloss wrote:
| It is always more expensive. I haven't moved any
| goalposts. What I am trying to show is that you don't
| need a tool - indeed you don't need to look at a single
| price of anything - to know why. It can be both more
| expensive and a better value though! If you can't recruit
| people or what you do is boring or if you want to operate
| a business that loses money in the long run: those are
| some common reasons it can look cheaper when it's not.
| YetAnotherNick wrote:
| > It can be both more expensive and a better value
| though!
|
| No, it can't be. Stop with the pseudo intellectual
| linkedin lingo please.
| JackSlateur wrote:
| Haa, yes, the scary "vendor lock-in" !
|
| I challenge you : give me a single product that cannot be
| moved away, given some (cost or time).
|
| At the same time, I again challenge you : give me a
| single product that you can move between providers with
| no cost nor time.
|
| To that last one, you can actually find stuff. For
| instance, you could setup your nginx in instances,
| without any kind of interactions with the hosting
| provider. In which case, you limit yourself with what
| everybody can do, leaving all opportunities to only use
| the base minimal.
|
| But wait .. are you not locked-in with nginx (or to use a
| better example: with redis) ?
|
| Vendor lock-in is a scam to increase your bills. Because,
| in itself, _everything_ is vendor locking. And it does
| not matter. Think your architecture, design your code,
| and act when necessary.
| candiddevmike wrote:
| I don't think you've ever been through the pain of moving
| a big, fully integrated, multiple ETL pipeline data
| warehouse built on something like Redshift. Vendor lock
| in is more about inertia and less about there not being
| an alternative. Some things are just really, really
| difficult to move and ridiculously impactful to change.
| unethical_ban wrote:
| You take the term "lock-in" far too seriously.
|
| Yes, one can migrate their entire CI/CD ecosystem,
| countless IAM policies across multiple AWS accounts in an
| organization, their lambdas, databases and S3 buckets
| over to Azure given enough time and money.
|
| The thing is that most everything in the cloud is billed
| on subscription, and many core components of networked
| services need not be (except support). Open file server,
| self-hosted IAM and standards-based execution stacks.
| Don't like hosting your nginx on Vendor-A? Move it to
| Vendor-B.
|
| Yes, the tradeoffs are costs. No, vendor "lock-in" is not
| the only component one should measure when deciding an
| architecture. Yes, "lock-in" can occur with on-prem
| software, and hardware, as well.
|
| Yes, it's real and worthy of concern when a vendor knows
| they can squeeze you because you have no other choice and
| the level of effort to migrate is too high.
| freedomben wrote:
| You seem to be trying to reduce the vendor-lockin issue
| to a binary "locked" or "not locked," but Idon't think
| that's a productive or realistic way to think about it.
| It's really more of a spectrum, and I prefer to think
| about it as "options" rather than "are we locked." You
| definitely have a lot more options if you go with Nginx
| and the project turns evil than you would if you went
| with some proprietary offering.
| surfingdino wrote:
| > 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.
| orochimaaru wrote:
| 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.
| empath75 wrote:
| This tool makes it relatively easy to find cost savings, and
| also to do chargebacks. Most kubernetes clusters waste tons of
| compute for no reason at all.
| outworlder wrote:
| > 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.
| Dalewyn wrote:
| 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.
| notepad0x90 wrote:
| there is a certain term well known amongst IBMers: "Blue washing"
|
| R.I.P. Kubecost
| diob wrote:
| I'm now in IBM due to an acquisition.
|
| It definitely is a company that can't do anything due to
| bureaucracy / random bullshit.
|
| You quickly understand why they acquire rather than invent.
| _zoltan_ wrote:
| I'm in Research and I beg to differ. (My own opinion.)
| rafaelturk wrote:
| 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.
| rafaelturk wrote:
| 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.
| liveoneggs wrote:
| 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!
| rafaelturk wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-17 23:01 UTC)