Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Posted May 3, 2025 16:11 UTC (Sat) by pizza (subscriber, #46)In reply to: Suprised we aren't seeing more of this by niner
Parent article: Redis is now available under the AGPLv3 open source license (Redis blog)
Based on how many folks keep forking over ever-increasing amounts of money to them... objectively, yes, they are very good at what they do.
> The whole industry seems to just go on the assumption that because they are huge, they have enormous economies of scale and - this is the critical part - that they extend those savings to the customer.
Of course they won't extend any savings to thier customers if they can get away with it.
Keep in mind though, you're not just paying AWS for cpu-hours, you're paying them for the ability to nearly-instantaneously add (and remove) resources on demand, whereas it could take weeks to months to get a new system spun up in-house and you pay the full cost to keep it running no matter how [under]utilized it is on average. Plus there's the way costs are accounted for; with in-house servers there are rules about how much (and rapidly) you can depreciate things, whereas rental costs are much more easily expensed.
Posted May 3, 2025 16:29 UTC (Sat)
by niner (subscriber, #26151)
[Link] (19 responses)
That's just an argumentum ad populum. The number of customers does not tell you whether the service is actually good or reasonably priced. Especially given that I specifically mentioned an assumption that many of these customers make without actually questioning its validity.
> you're paying them for the ability to nearly-instantaneously add (and remove) resources on demand
Yes, that's a common argument. What I rarely hear though is an in-depth discussion about whether a specific customer actually needs this elasticity. And even if demand is fluctuating highly, that's still not a clear sign that using a hyper scaler will then be cheaper. I've had a customer where even if on average 80 % of the hardware was just idling it would still have been cheaper than staying with Google. In a sense, the near-instantaneous scaling solves a problem that cloud providers created in the first place, i.e. that resources are super expensive.
> whereas it could take weeks to months to get a new system spun up in-house
That's assuming that the only alternative to hyper scalers is buying your own hardware and running it fully in-house. Which of course is not true at all. There are a lot of in-betweens. E.g. I can rent additional VMs at Hetzner, deploy kubernetes and add them as new nodes to our cluster within minutes and all of this - including the renting part - fully automated. Hetzner charges for these VMs on an hourly basis. So no, you don't pay the full cost if you no longer need it. And that's just one example.
Posted May 3, 2025 19:04 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (16 responses)
"10,000 lemmings can't be wrong" is a common attitude ...
I bang on about how Pick uses far less disk storage (and is far more efficient with disk access), but nobody's interested. How many companies are international, and could run datacentres optimised for normal demand in 2, 3, 4, large geographic areas? If your Europe datacentre is designed to cope with typical European demand, likewise your American and - let's say your Japanese - datacentres, how easy is it for a datacentre to spin up instances on the other two, knowing that if one is overloaded the other two will (thanks to timezones) probably only be lightly loaded at that time ...
The two (or maybe three) major needs AWS, Google etc are seen as filling is good backups, and resilience against attack. But are they the best providers? (The third is security.)
But for backps (I'm thinking especially of ransomware here) there's at least one provider that charges almost nothing for inbound (to the backup service) traffic. They charge through the nose to get it back out, though! But that way, it's cheap insurance - you keep a couple of generations backup, they keep long term backups, and it only costs real money if you need it.
Likewise resilience - people use Cloudflare to protect against DoS attacks. I don't know if they use a similar charging mechanism, but why not? "Pay if you need it".
And what, exactly, security do AWS, Google et al actually provide? Given that most attacks are social engineering and carried out with genuine user credentials, how do they protect against that?
The biggest advantage they seem to provide is the lemming factor :-) "Best practice" often is not the best at all ... (that, and ditching the hassle of managing your own datacentre.)
Cheers,
Posted May 3, 2025 22:04 UTC (Sat)
by khim (subscriber, #9252)
[Link] (15 responses)
Yet surprisingly often it's also the right attitude… Why should they be? In today's world most companies care much more about ability to hire someone who may support they IT system then about cost of hardware. Not only tiny companies who may host everything on just one server that's cheaper than monthly salary of a single developer but also the likes of Amazon or Google spend more on developers salaries than on hardware. Pick is absolutely useless for them: they would need to find and train developers who would work in entirely different paradigm… you couldn't easily fire them and rehire when needed… why go there? Similarly with hyperscalers: what hyperscalers save are not price of hardware (your own hardware is, indeed, cheaper), but administrator salary: finding someone who may help you do something with AWS instance or Google Cloud is trivial and cheap… the first incident with a dedicated hardware would chew all savings for many years of self-hosting. Yup. But that's THE main requirement. By far. The main need that they are filling is the ability to find someone on freelancer or upwork who would be ready to solve your problem for a small price. Yes, that's precisely that “10,000 lemmings can't be wrong” thing, but it's also the real reason cheap ad-hoc solutions are not used: people on lwn.net often don't even realize how few people are there who can do what they can do.
Posted May 4, 2025 7:11 UTC (Sun)
by niner (subscriber, #26151)
[Link] (7 responses)
Cost for administrators is indeed an often repeated argument. But what company has actually let go of a significant part of their IT team after migrating into the cloud? Conversely I don't know of any company that had to hire additional personnel after moving away from a hyperscaler.
Even if, one of my customers pays about a million USD per year to Google. Buying the required hardware to run the whole shop would cost about 300k once. Even with rented boxes in a data center and on-site service by the great people at firstcolo this customer could save a staggering 90 % of cost[1]. How many competent sysadmins can you get for that kind of money and still save a ton? In this region 100k per year is a super competitive salary for this job. Get 3 of them and still save tons. Or don't and instead hire one of the plenty of IT service companies (like mine).
> Yes, that's precisely that “10,000 lemmings can't be wrong” thing, but it's also the real reason cheap ad-hoc solutions are not used
That is indeed the core of the problem: people coming from universities nowadays only know the world where you run your k8s pods at a hyperscaler. That's what they learn how things are just done and for them there's no point in questioning this. For them, that's the only world that exists. Even so, it's not yet too late to turn around.
[1] You may wonder why they don't. Case of bad timing. Shortly before I became aware of their enormous cloud cost they signed a deal with Google for 3 years for a few percent rebate.
Posted May 4, 2025 13:23 UTC (Sun)
by khim (subscriber, #9252)
[Link] (3 responses)
If company even have “an IT team” then it's rare “medium” company. There are 33 million businesses in US for 170 million of labor force. Do the math. Well, if they had none before they, obviously, would have none after thus it's not surprising. The question is how often they need to pay for someone who is managing their infrastructure. And how much. Which, again, means it's not a typical company and for them, perhaps, using Google isn't a good idea anymore. Seriously? Would they bring their own hardware and hosting, too? Because to pay 100k salary you would need to spend 250k-300k per year (corber should know more precisely for US, but 2.5x-3x is typical overhead in most places in the world), thus with 3 admins you have nothing left for hardware and other things. And that's even before we bring in cost of insurance, loans and etc. All these things go up if you do “nonstandard” things. For a company that's ready to pay million per month… probably not. For majority of the companies… they couldn't afford anything else.
Posted May 4, 2025 15:35 UTC (Sun)
by niner (subscriber, #26151)
[Link] (2 responses)
And how many of these 33 million businesses use a Redis hosted by a hyperscaler or have their own k8s load or anything? Those numbers are meaningless for this discussion.
> The question is how often they need to pay for someone who is managing their infrastructure. And how much.
They always have to pay someone for their infrastructure. The whole point is that people blindly assume that hyperscalers are the cheapest option when that is quite often just not true in my experience.
> Which, again, means it's not a typical company and for them, perhaps, using Google isn't a good idea anymore.
As Google cloud customers go they are still a pretty small fish. So they are not that untypical either.
> Seriously? Would they bring their own hardware and hosting, too? Because to pay 100k salary you would need to spend 250k-300k per year
No, I meant 100k Euros cost for the company. All taxes and insurance included. That's in central Europe.
> For majority of the companies… they couldn't afford anything else.
And there we are back to that unproven assumption.
Posted May 4, 2025 18:58 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
Why? You want to say that when company grows large enough to need to use Redis or want to run something besides simplest web site it needs to, suddenly, forget everything it did before? Why? Yes. But for the company with 3 or 5 employees it's often cheapest option if you include the price of freelancer work into equation. Simply because hardware costs are negligible no matter where you host your web site with 1000 visitors per day and freelancer that would work with hyperscaler is cheaper than someone for less common setup. Ouch. Yeah, if that's in place where 100k is good salary “all taxes and insurance included” then use of Google cloud is highly questionable. It's not hard to find decent IT support that wouldn't cost arm and leg in these places. Try to find someone on freelancer who would help you create some website with budget measured in less that $100. The best you may hope for is some student that only knows “the big three” and then not very well. And that's where most companies start. Granted, the fact that people would still use hyperscalers when they start paying thousands and even, in some cases, millions for hyperscalers is crazy… but that's how life works: they started where it made perfect sense, then grew till it stopped making sense… but only started to question their assumptions when it started killing them.
Posted May 5, 2025 6:56 UTC (Mon)
by niner (subscriber, #26151)
[Link]
A company running the simplest web site doesn't use a hyperscaler (directly) either. If all you need is a website for a lemonade stand, you go to Wordpress, Squarespace or the like, click around and go online. Or go to some marketing agency that will do that for you. I don't understand how a company needing the simplest web site even relates to this discussion.
> but that's how life works: they started where it made perfect sense, then grew till it stopped making sense… but only started to question their assumptions when it started killing them.
Indeed. And that just makes me sad. Most of all because it doesn't have to be this way. Even in the other startup I co-founded, we started out on Google cloud, because if you have practically 0 load on your hand full of k8s pods, the cost is indeed almost 0. It made sense. But then our Postgres queries became more interesting and needed more memory to complete and we suddenly had to upgrade our Postgres from the cheapest to the enterprise offering, despite the database still being tiny and 99 % idle. That's when we got the hell outta there and now run the whole setup (including fully redundant k8s, PG and backup) on Hetzner VMs for less than half of what just the database cost on Google.
Posted May 4, 2025 21:28 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
It's clearly for something serious, not just a marketing website. Do you need 24h service? And can you tolerate 12h of downtime?
If the answers are "yes" and "no", then you need a team of on-call engineers near the colocation site (and good luck if you want to use a DC in Oregon). For 24h coverage, you need a minimum of 5 people (168 hours in a week, so 5 people to cover that with 8-hour shifts). At a reasonable $150k a year salary and overhead, you're already looking at $750k a year.
Now suppose you want to add another datacenter on the East coast. Your expenses go up by 2x.
Sure, you can cost-share the on-call technicians with other companies. But then you have questions of access control, data security policies, etc.
Then there's a question of hardware availability. Did you make sure to buy spares in advance for all of your critical hardware? Do you test these spares regularly? Are your engineers sufficiently qualified to design computing architecture that is not accidentally bottlenecked?
If you do the math, cloud computing makes total sense if you want to avoid the risk.
Posted May 5, 2025 6:36 UTC (Mon)
by niner (subscriber, #26151)
[Link] (1 responses)
If you're intimidated by having to design and set up reliable systems, there are lots of companies (including my own) that can help you get up and running. We did the math - for customers - and they ended up saving a lot.
Posted May 5, 2025 6:53 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And this typically tops out at something like "1 rack, 1 gbit and no SLA" before it starts becoming expensive. "Remote hands" also are typically not responsible for anything more than checking cable connectivity and/or swapping hardware. If you want someone who actually understands your network topology and can debug complex issues, this starts getting really expensive.
I have done these kinds of calculations, and you absolutely can get cheaper than AWS (or Azure), but you won't get _much_ cheaper. Unless you have very specific needs like massive storage or a lot of egress traffic.
So not using hyperscalers is cheaper either if you have something small, or if you are VERY big.
Posted May 4, 2025 9:03 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (4 responses)
Because you can train up USERS very easily to be developers - as an alleged end-user I'm expected to program as part of my job. So you don't need to hire-and-fire because they're users who can program, not surplus programmers. I'm expecting my colleagues to find Pick *much* easier than what they do at the moment ...
Because jobs come in ON TIME and UNDER BUDGET? Our current "big project" - finally going live this year - has been "two years away" for the last five years - which seems to be the norm for big relational projects? We've been told we'll have to wait 18 months before IT will even look at our little project - I've been threatening to write the whole system single-handed in 6 months. Etc etc.
Because it'll halve the cost of your IT department? What little information there is says that a Pick shop pays roughly half the percentage of gross turnover on IT than other shops do.
It's "Nobody got fired for buying IBM" all over again.
Cheers,
Posted May 4, 2025 13:41 UTC (Sun)
by khim (subscriber, #9252)
[Link] (3 responses)
And pay $5000 or $1000 for each user each year? To retain people with rare and valuable skills? Seriously? In what world would that make any sense? It doesn't matter whether it's easier or not. It only matter if people with these skills are lining up outside of your business or whether you have to train then and then retain them in your business, somehow. That's serious proposition, but you would have to prove that perpetual Pick tax would offset these one-time problems. This may work, in some cases, but it's very far from the “no-brainer” deal that you imagine. One may imagine an alternate world, where Pick won, but it would have other problems, namely: It's the norm for all projects and is not related to Pick in any way, shape or form. All successful projects come out late and over budget, be it bridge building, relational projects or moon rocker launching. Pick project only have the luxury to “come in on time and under budget” because they are rare. Managers have absolutely no idea how much Pick projects may cost thus you may say you would need 100k and 1 year for project that would take 100k and 1 year – and get away with that. Because you have no competitors. Once competitors would be there competitor who would ask for 40k and 4 month would win. And management would pay 100k for 1 year of work to them and not to you. That, again, have nothing to do with Pick and is typical dynamics of how project works in largish companies. No. It wouldn't. In imaginary world where Pick is popular instead of incompetent relational developers you would get incompetent Pick developers. Salary spending would stay the same and hardware costs are not a big problem for most companies, these days. Of course. But that because Pick is only driven by people with passion. Technology have nothing to do with that, only one characteristic is important: whether it's popular or not. Welcome to the real world. That's how businesses almost always work. Only in rare cases, where a paradigm shift is happening and where change of technology may change how you interact with your customers may ever change that dynamic. Otherwise, for most businesses, “doing what everyone else is doing” is the right and proper strategy.
Posted May 4, 2025 18:57 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (2 responses)
> It's the norm for all projects and is not related to Pick in any way, shape or form.
Please stop making inflammatory and clearly bullshit statements. I am aware of a lot of people working with Pick, and whenever late projects come up it's NEVER Pick projects that are late. If the set of Pick projects is large (it is), and the set of Pick projects that are late is almost non-existent (it is - there aren't even rumours of late projects, every project mentioned is on time), then it CAN'T be the norm for all projects. And it IS related to Pick, as if you had said it was the norm for all RELATIONAL projects, I would have no problem with it.
> Managers have absolutely no idea how much Pick projects may cost thus you may say you would need 100k and 1 year for project that would take 100k and 1 year – and get away with that. Because you have no competitors.
> Once competitors would be there competitor who would ask for 40k and 4 month would win. And management would pay 100k for 1 year of work to them and not to you.
Except, assuming said competitor was using a relational database, I wouldn't bid 100K. I'd bid 40K *FIXED* *PRICE*. So if it truly is 100K for a relational solution, either I get the contract, or my competitor ends up badly out of pocket (or, as seems to be the norm, "big contractor" stitches the client up).
Oh - and a real-life internal example in my company - one of my colleagues took about a week to write an analysis system. Which isn't used much because it still leaves a lot of manual work to massage the results into usable form. I've bid a Pick system which will analyse and cleanse the data straight into our reporting system (Tableau). Guess what - I've bid ONE DAY (double that for contingency). And her SQL/Python etc is a damn sight better than mine. Desite that, I don't expect to be over budget ...
> > It's "Nobody got fired for buying IBM" all over again.
> Welcome to the real world. That's how businesses almost always work.
Nobody ever got fired for buying IBM :-(
Until some brave business does something different and takes everybody else to the cleaners.
Cheers,
Posted May 4, 2025 21:07 UTC (Sun)
by jake (editor, #205)
[Link] (1 responses)
No minds are being changed, seemingly, but never-ending walls of text are being posted about it ...
can we *please* just give it a rest?
thanks,
jake
Posted May 4, 2025 21:59 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
And while people might not want to believe my facts, at least I do my best to avoid stuff which is easily proved (or even obviously) wrong.
I just wish people weren't lemmings.
Cheers,
Posted May 6, 2025 4:10 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (1 responses)
At risk of committing an act of necromancy, I'll disagree a bit here. There are a lot of no-sql tools with different paradigms which didn't exist 10 or 20 years ago and that one couldn't assume any new hire would be familiar with that they'd have to learn on the job. New hires are going to need to learn the particulars of your tech stack and in-house tools, so learning a different DB engine then one they've used before is probably not an insurmountable challenge. Using the most common tools in hopes of making hiring easier is fine as far as it goes, but so does using best-of-breed tools that fit your particular problem set and expecting some amount of in-house training/acclimation.
That said, I'm not sure where Pick would fall into this, while I'm sure it is innovative in it's own way, and has it's own cheerleaders (hi Wol) I don't think it represents some hidden arcane field of computer science that doesn't exist in equivalent forms in other tools. There are only so many different ways to make efficient data structures in memory or on disk that have different tradeoffs. The no-sql evolution was about offering tools using specific data structures that fit well with the problems they were solving but weren't commonly available or efficient in SQL-fronted database engines, because SQL servers were targeted at different problems. I'm not sure that's the case anymore, the SQL-fronted engines like PostgreSQL or MariaDB have added storage and indexing methods which offer some of the same data structures which made no-sql engines useful, and the other no-sql engines have thrived in their niches refining the use-cases which spawned them. I'm not sure Pick would be any different than someone coming from PostgreSQL learning Redis/Valkey or someone familiar with Cassandra learning sqllite or etcd
So building a tech stack for hire-ability seems foolish, it's one property among many and if you hire for competency and willingness to learn then they can pick up the specifics, familiarity with more components of your stack is nice but lack of familiarity with one component is not a deal breaker.
Posted May 6, 2025 7:12 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
At the risk of pouring petrol on the flames I'll just point out I was programming Pick way back last century - in fact it predates Relational, and probably SQL too ... (it nearly predates me, and I'm on the verge of retirement.)
> and that one couldn't assume any new hire would be familiar with that they'd have to learn on the job.
I'm expecting end-user "new hires" to pick it up quickly and easily - people who don't have an IT/CS education.
> I don't think it represents some hidden arcane field of computer science that doesn't exist in equivalent forms in other tools.
Efficiency?
> There are only so many different ways to make efficient data structures in memory or on disk that have different tradeoffs.
Efficiency? Native 4NF in the database is pretty unbeatable ...
> I'm not sure that's the case anymore, the SQL-fronted engines like PostgreSQL or MariaDB have added storage and indexing methods which offer some of the same data structures which made no-sql engines useful, and the other no-sql engines have thrived in their niches refining the use-cases which spawned them.
Efficiency? IME, SQL cannot query those striuctures particularly efficiently. Efficiency? The majority of an ENGLISH (one of the names of the Pick query language) query lives in the table schema (note I didn't say view!). Efficiency? Your normal query is a short one liner, that has no optimiser because the possible gains aren't worth the candle. Efficiency? ENGLISH is optimised for accessing 4NF data.
Bear in mind also that Pick is a second-gen NoSQL. As in NotOnlySQL, not NoSQL. If you want to query Pick using SQL, go ahead. Why would you, though, seeing as you'd be replacing one line of ENGLISH with screeds of SQL (Unless, of course, you cheated and took advantage of all the ENGLISH buried in the table schemas.
At the end of the day, I have to work with Excel formulae, and SQL queries all day. I CRINGE at the volume of code, the time wasted working out what the hell is going on, the time wasted writing huge multi-line SQL programs, all the stuff I could do in ten minites in Pick that takes a week in VBA/SQL/Formulae. Maybe (almost certainly) I'm a crap SQL programmer, but a lot of colleagues, who are a lot better at it than me, fare equally badly.
Efficiency! At some point in the near future I'm going to get the opportunity to pitch a rewrite of our system. I am - SERIOUSLY - going to bid that I can rebuild the majority of our shit single-handed in six months. Our IT department is saying "maybe we'll get round to looking at it in 18 months". I'm not stupid enough to think that doing it single-handed is a good idea though. I want to build a team round me (with the intention that they rewrite their systems in the same sort of time frame :-) So when IT come and take a look at it, they'll say it'll take five years for them to replace our system that we built in six months ...
Cheers,
Posted May 4, 2025 23:20 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
That can only be answered with respect to that *specific* customer.
In my experience, internal bureaucracies/overhead meant that it was infinitely cheaper to use the likes of AWS vs in-house resources, because the latter was effectively made of unobtanium -- either the process would take so long that it would render the need moot, or we simply didn't' have the budget to outright buy an appropriately configured system.
> E.g. I can rent additional VMs at Hetzner, deploy kubernetes and add them as new nodes to our cluster within minutes and all of this - including the renting part - fully automated. Hetzner charges for these VMs on an hourly basis. So no, you don't pay the full cost if you no longer need it. And that's just one example.
So... you've just gone with a cheaper vendor?
Posted May 5, 2025 6:44 UTC (Mon)
by niner (subscriber, #26151)
[Link]
That's a fair question. In a sense, yes. However, the point is, that it's not one of the big 3 hyperscalers. Thus it still invalidates the assumption that due to their, well, scale they are unbeatably cheap or even value for money. There are a lot of vendors out there that offer services that are somewhere between the 100 % do it yourself and full cloud where my workload gets pushed onto the cheapest machines at Google's convenience.
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Wol
> "10,000 lemmings can't be wrong" is a common attitude ...
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
> But what company has actually let go of a significant part of their IT team after migrating into the cloud?
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
> Those numbers are meaningless for this discussion.
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Wol
> Because you can train up USERS very easily to be developers - as an alleged end-user I'm expected to program as part of my job.
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Wol
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Wol
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this
Wol
Suprised we aren't seeing more of this
Suprised we aren't seeing more of this