Unhappy with the cloud costs? You're not alone There is growing dissatisfaction over cloud computing, according to Gartner, and much of this can be put down to unrealistic expectations or customers simply not implementing the tech properly. The consultancy claims that cloud dissatisfaction is real, and estimates that as much as a quarter of organizations will experience …
This post has been deleted by its author
Y2K was a non event due to all the work put in by I.T. professionals doing all the testing and deploying updates and fixes before 1st jan 2000
a number of large corporates did see it as a way to maximise profits and sales by refusing to provide BIOS updates and patches for software to force companies and users to update by buying new hardware and software, but all it meant was companies did shop around and find better deals
from an I.T. pro's point of view it did enable us to get rid of some really old and horrible flaky systems and hardware being held together with bubble gum and sellotape. which were taking so much time to baby sit as the bean counters wouldn't pay for proper hardware or maintenance
More curated meh from Gartner. You could ask people about almost anything they use - coffee machine, bike, gym, phone - and you'd get a similar set of sentiments; there's some things I don't really like or I'd like to change but overall I'm content enough to stick with it cos it does the job and I can't be bothered or can't afford to get something different.
A tried and tested model. Like so many changes that become fashionable, it starts off with some slick salesman (with a big job title) schmoozing clueless execs and promising big cost savings. By the time it's BAU and costing more than when the comapny operated its own servers, nobody wants to hear that the Emperor is in the nuddy.
So the organisations congratulate themselves that they're "partnering" with top global IT companies, and celebrate that they have divested themselves of all the risks and complications of operating their own IT.
Who used to run your on prem workloads take control of your cloud workloads, then of course cloud costs will skyrocket.
You need to get rid of legacy IT people and hire bright new cloud native employees before you will see improvements.
Speaking as one of the "elderly, incompetent, IT staff", we are the reason that the cloud migrations our company has been involved with actually worked. Having people who know how the system works is rather important when you are trying to move it
Underneath the pretty cloud wrapper is a load of hardware that - oddly enough - works pretty much the same way as the on prem stuff did.
<i>Speaking as one of the "elderly, incompetent, IT staff", we are the reason that the cloud migrations our company has been involved with actually worked. </i>
This is the sweet spot - people who have the expertise and experience but can combine it with modern practices. Those are the people who in my experience typically get the best out of the cloud.
The 2 scenarios to avoid are: old people who think everything should work as it did 20-30 years ago because "it's what I know works", or people fresh out of college/uni who don't have any understanding of what existed before the cloud.
Yeah.... nah.
Cloud is just... meh, nothing really new.
It's a machine that sits somewhere else. Ok, it is a VM sitting somewhere else. Actually, you run a container on a VM somewhere else. The container contains an OS (well, parts of it, close enough) and your workload. It can talk to other containers using e.g. a network stack.
What is new (well, newer) is spliting things into simple chunks, microservices (actually nothing really new), and you no longer have to care about how the VM really is configured, because that's the provider's problem. Having stuff inside containers, iff set up correctly, can help spinning up new instances on demand (and this is pretty awesome and actually the new thing) without too much hassle. When I was still doing scientific computing on actual clusters this was more difficult (and thanks to your overhead depending on how work was split - core -> cpu -> node -> unit) it likely still is, should you want just raw power). Unless you have your workload actually split into microservices - rather than the meso-services I see - there is only limited benefit from running the stuff off-prem on somebody else's computer.
Now we need to explain to senior manglement that there is no benefit for the company (yeah, the customers will benefit, hopefully) if we are the (mandated, because Gubmint) cloud, i.e. we still need the datacentre. And thanks to SNTM (stupidity of non-technical managers) this is... hard work. Getting this stack to work as intended is also indeed something for the bright lads and lasses, though many a greybeard has more clue than the new and so-green-they-need-mowing kids.
>” iff set up correctly, can help spinning up new instances on demand (and this is pretty awesome and actually the new thing) without too much hassle. When I was still doing scientific computing on actual clusters this was more difficult ”
That is really down to the management tool development Grid and then Cloud demanded. For Cloud and public Cloud to be usable (or even viable) provisioning and decommissioning toolsets were king to be necessary.
From what I have seen with AWS, they have good provisioning toolsets, but their decommissioning tools still leave something to be desired, perhaps because they reduce people’s expenditure…
The cloud "migration" when all they do is a direct lift-and-shift from on-prem, without any thoughts to re-engineering for cloud paradigms, taking the opportunity to redesign and bring it up to date, or building it around the capabilities or components of the cloud provider itself.
Just take what you already have and ram it until it fits. Everything is a server instance.
Depending on where you are in the cycle from pre-seed to mature company - costs vary widely.
I'm primarily working for companies who are deploying on AWS. I'm a C++ programmer by background, but these days, it's mostly near-real time messaging application - e.g. large gambling tech companies are the poster child.
There is a lot of on-prem for regulatory reasons, operations must be physically located in the country.
As a pre-seed startup, you can get oodles of cloud-credits to try your stupid idea for "free" infinitely renewable for just picking a new shit company name, and paying companies house 85 quid for a limited.
My hosting on real metal involves real British Beer Tokens being transferred to my provider on a monthly basis, who would utter a hollow laugh at the concept I expect to run on their tin for free.
The horrible truth is you need better staff on prem, and if you have them, you'll be fine on-prem or in the cloud.
If you have a stable and sane architecture - you'll be running more cost effectively on prem. But if you want to bill each business unit for the cost of the compute/services they consume, that's starting to get more complicated.
I run most of my personal infra on dedicated hardware because my needs are stable so it's vastly cheaper than AWS, assuming you value my exceedingly expensive time at zero.
In my semi-defence, I've written most of this and it's stable, so requires little actual day to day effort, it's mostly automatic, but I spent a shitload of time setting it up, and learning. I still think I'm quids in, but if I had to pay me, for my time collectively...
. But at commercial scale, AWS costs are highly variable with Credits, agreements, Reserved prices etc Karpenter is dynamic auction pricing for infra.
So it's quite difficult to workout how much you actually pay - which is why I prefer to pay for OS labour costs. There are solutions which you can stand-up fast, securely and the cost is a rounding error in the profit margin, even at treble the price.
Let me give you an example. I needed to migrate something inside 6hrs. One off job. This 6hrs window cost more than the salary of everyone working on the problem for next couple of years.
AWS had a "network incident" to which I gleefully posted https://blogs.oracle.com/developers/post/fallacies-of-distributed-systems.
This momentary blip caused a 5hour transfer to fail (of course it went smoothly in rehearsals). Approximately a week later that transfer took two hours. Because of Linux engineering (slice and parallelise, with async exponential backoff) the bottlenecks could now be purely IO. Because of the cloud-native position, it was possible to have faster network path and over-provisioned storage path at excessive cost for the one off task, stood up used, torn down, without beancounter approval.
Without being able to make that parallel being on cloud-doesn't help - without being able to deploy better network links now, there is an IO limit that gates my performance envelope.
The AWS point-to-point network bandwidth is pretty impressive. I've worked with a lot of good on-prem people, they are getting older, and we're not replacing them.
That's a mistake in my view, but so is viewing Cloud costs by sticker price.
There is a series of tiered IO bottle necks. If you push a large DB dump into a DB, you won't hit the disk write bottleneck first, the first problem will be that the writer is serial wasting the performance of the datastore. If you split that dump, you can now have multiple writers which is the single most important thing to do first.
The second thing is to account for table size, pushing in ascending size order will mean most of the transfer time is devoted to pushing full blocks over the storage/network path.
You don't really want DAS when you are using a managed service, it's great for doing computation, but given an ingest job, it's about maxing out locals. then matching destination instances for snapshot and restore to rightsize instance using EBS snapshots which DAS would circumvent.
So...Gartner is saying the "cloud client" is at fault when in fact it is the "cloud provider" for:
1) misrepresenting the simplicity if the migration;
2) providing useless support;
3) providing useless documentation (if any at all);
4) providing "out of the box" systems that are poorly configured and inherently insecure, and
5) providing overly complicated controls.
All of which the client "discovers" after signing their data away and thee "'tech teams" valiantly trying the get the "cloud" to work like their on-premises systems did...
is that the servers often had better Internet connectivity than could be obtained on-prem. This especially so years ago when cloud first became a thing.
Now, for many, fast & low latency Internet is not too hard/expensive.
I am not saying that there were not other reasons but this was a big one back in the day.
> is that the servers often had better Internet connectivity than could be obtained on-prem.
You could obtain them, but for many businesses (and particularly web startups) they were eye wateringly expensive. Cloud allowed that cost to be shared.
The reason why “elastic” was a big thing, was how seemingly frequently new websites crashed due to unforeseen surges in user traffic, which tended to reduce to more predictable and manageable levels after a few days.
Well, there's a few other issues, like how costs are calculated.
Worst case I've found recently comes from MS (big surprise) where they charge for CU usage. Only they charge you for a full CU even if something only took a fraction of a CU. A bit like charging you £50 for a three course meal even if you only had the starter and hadn't even ordered a main or desert...
It was hyped as cheaper, and it can be for workloads that wouldn't even saturate a desktop machine pressed into service as a server (i.e. the norm back in the 90s and even the early 2000s when rackmount kit was exotic) used as a virtualization host, which itself was a way to consolidate all that junk onto fewer, more robust boxes. The other hype was rapid scaling in both directions... an elastic compute cloud if you will. It could never be cheaper at the large scale. Hardware, real estate, and power can only get so cheap, and profit has to be made somewhere. At the same time there was also a push to own nothing but your employees. Everything should be an operating expense. Everything went to subscriptions, often as cloud-only dbase-iii-applications-as-a-service. It was cheaper at first, because that's how they get you hooked. Now that the decade-long introductory price is over, it's time to jackpot the customers. It's not like they can leave as everything is now sold as a subscription, and is cloud-native.
I find it rather telling that with the cracks showing in the cloud-native ecosystem we're getting AI forced on us like that creepy guy at the bar that keeps trying to get his hands near our drink.
It's pretty simple really.
I've been saying this since around 2008. I worked at a company that had a dedicated web server for which they paid around £350/month (at the time). It was more than powerful enough to run everything they needed and then some.
The cloud w**kers came along and said "oh, but you're not using 100% capacity so you're paying for stuff you don't need".
(Enter the cloud)
How much is that per month? Starts off quite low, seems great.
But then... ever increasing and unpredictable bills each month. No longer a *fixed, known cost* each month anymore.
(Now): We should look at reducing our costs and want infrastructure with predicable, known pricing. /Facepalm.
Cloud is just the latest IT fad that non-technical management thought was going to solve every problem. I've seen it with Citrix / RDP, thin client, virtualisation and now cloud. The hosting platform doesn't really matter if your technical implementation is fundamentally bad and not suited to the environment.
No doubt all the consultancies that flogged "migrate to cloud" services will now be selling "on-prem repatriation" services.
one of the things missed by the article was the last 10 or. so years since AWS / Azure etc came on the bean counters radar there has been a steady loss of skills required to run on premise systems
I work in a cloud consultancy and in a fair size team there are only 2 of us who have worked in data centres and on premise support with networking and physical hardware skills
pretty soon there will not be enough of us to go round for companies who want on premise services
cloud was jumped on by bean counters as a way for making finance more predictable, as running costs moved from large intermittent CAPEX purchases to much smaller monthly OPEX cost which made budgeting a lot easier for them
the problem is they also thought they could use the cloud to reduce the expensive I.T. head count by using SaaS / PaaS service and use lower skilled staff ( queue same argument for AI ) only to discover its more expensive to use SaaS / PaaS services than employ skilled staff on premises
add to that the cost of large database services cost a fortune in the cloud I am seeing a trend of those sort of services being brought back on premise due to cost and paradise is broken
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
