The point of cloud is to be its shareholder, not its product.

Sure, there are electricity price issues but that's unavoidable whatever option you choose. The real issue as ever is vendor lock in. If you're tied to AWS APIs it's difficult to move, and they can charge whatever they want. Make your product vendor API agnostic, or use your own set of hosted servers or expandable instances.

It's often also a case of convenience, if you're not doing the end work, someone else is and will be charging you appropriately for it. What's the trade off for the customers using these systems?

Couldn't agree more. Subscribing to the proprietary features of one of the cloud platforms can let you build a lot of functionality very quickly, but the vendor then has you well and truly over a barrel. It also takes disaster recovery completely out of your control. We run our cloud infrastructure across multiple cloud vendors and have designed it in such a way that failing over from one cloud to another is straight forward (proved by both testing and recovery from actual failures).

I have never, ever understood why a company would want to turn over all its data to an external partner for the sake of a small convenience. It's a reverse economy of scale; the more data you have, the better off you are storing it on-site and the more justifiable maintenance of your own data centre becomes. But at the other end of the scale, if you only have a small amount of data to store then storing it locally becomes much easier.

Perhaps there's a Goldilocks zone where you can't centrally store your own data economically. But that isn't how it's ever pushed, of course. Cloud storage is the WaVe Of ThE fUtUrE and apparently everyone should be doing it - leaving themselves vulnerable through audience captivity.

As 'Dr Who' says proprietary features can let you build functionality quickly. Time is money and a possible business advantage. Same thing as using a commercial third party library in a desktop application.

The question is then if it comes with increased costs due to vendor lock in, a lack of control due to someone else creating the product, and potentially building up technical debt for the future.

It's not necessarily a poor decision if it results in overall increased revenue and/or less man hours required.

I'm not sure about small amounts of data - if you want to make it resilient there's a certain upfront cost regardless of data size that may make it cheaper to use a third party provider.

Not so much a matter of ROI as RAL—'Repent At Leisure'.

Well there you go then. The Man from Gartner he says no, and when has he ever been wrong before?

Maybe one effect might be that people tend to forget negative exeperiences from the past?

On-premise datacenters with limited capacity were resized in a matter of 10? years, if at all.

Often you were limited by available space, power, CAPEX and projects were sized to fit in whatever limited capacity was available.

Remeber the resulting amount of pretty expensive work spent on code optimizations in earlier days?

Now that all developers/admins have practically unlimited capacity at their fingertips, Optimization IMHO does seem to get much less attention nowadays.

So I find it unsurprising that cloud bills go up over time, however, lower manpower cost should balance rising cloud costs to a certain extent for many organizations.

In the long run, organizations need to find their balance between manpower cost for optimizing and cloud/on-premise capacity cost.

I would follow this with comments from being in the industry since almost before it became an industry

In the early days there were limitation on every aspect from CPU (I have worked on systems where the CPU did not come on a simple chip...more like 2-3 boards) to RAM to persistent storage. People learned to optimise there work within these limits and often very creative solutions were found

Once each limit was eased so did the requirement for tightly managed code and so the practise of coding changed to include processes which made things simpler although less structured. A simple program which previously ran in 16k of RAM now had 640K to play in so why did it matter if it meandered a bit and loops/searches were not as efficient..it still ran and that was what counted. To this were added helpful compilers and suchlike to make coding less like a black art and more like copy/paste from useful libraries of coding examples so that anyone could now write code.

We finally reached the point where the OS was using over 100GB of your PCs hard disc and even simple documents/spreadsheets are measured in MB and the lean/mean suite of programs required for a modern office can either be another 100GB on your PC or some unknown value in the cloud. Add to this the move of snapshots and backups to cloud systems and I would be surprised if most IT departments actually knew how much data they really had and how much of it is meaningless junk.

The C Suite people have never really cared about details just so long as they are promised improved perfection for a reduced cost and the days of having control over software, data and costs are a distant memory to most IT people with the fragmentation of responsibilities which are part and parcel of the cloud where costs are based on data volumes either at rest or moving and CPU usage. all measured by tools kindly provided by the cloud owner who is busy preparing the bill.

While it would be great to think that moving back to on-prem is still an option, none of the main software providers want that to happen since they are too busy pushing the new licensing models which require them to exert maximum control over what you can do with your data.

Of course not.

They can't understand them.

From my own recollection the stampede towards the cloud, and outsourcing generally, rarely involved consulting the poor system administrators that would have to manage the ensuing fiasco. Fortunately ( sic ) that function was often also subsequently outsourced thereby compounding the felony.

Was frequently a C suite chap knew another chap who claimed his outfit was saving a motza by being in the cloud with the inevitable board diktat with unfortunate consequences.

* or indeed Evans.

Funny, that’s how my last employer ended up in Oracle Cloud despite opposition from literally everyone in technical leadership

Exactly. Back when the "cloud" hype was first ramping up, I remember a far more generally-sceptical attitude *actual* "admin" types here and elsewhere.

Not only did the move to The Cloud always gave the impression of being management-driven, but those same sceptics were already pointing out and predicting many of the issues that have now come to fruition.

Of course, " CxOs don't care whether if the cloud was such a good idea after all, because they reaped the short-termist benefits and moved on long before any of the easily-predicted consequences actually happened " isn't such a catchy headline.

If you were a cloud advocate, we were the enemy - a pure and simple sales obstruction.

No kidding. It was as if cannabis had be legalized and every marketdroid was offering blunts.

And all the CxOs partook . . .

Bingo. "All the CxOs ", not "admins" as the article title suggests (and [1]someone which someone else already picked up on before I could).

From what I remember, the original "rush to the cloud" and buying into the hype was always primarily management-driven and there was plenty of scepticism in forums like The Register's from actual "admin" types in general.

[1] https://forums.theregister.com/forum/all/2024/09/04/cloud_buyers_regret/#c_4924071

"administrators are questioning the value and promise of the tech giant's services."

If they were good administrators, they would have been wondering this /before/ the move to the cloud, but were probably ignored....

If you can't build well on prem you won't be able to build well in the cloud - and vice versa.

If you are cutting corners on prem you'll try to cut corners in the cloud, only you won't be able to sweat assets in the same way.

If you have legacy and tech debt then you need to sort that out - if you sort it out on prem it will make your life just as easy as if you do it when you move to cloud.

Cloud is great if you have lots of opex but not much Capex. On prem is better if you have access to more Capex and less opex. The last really well justified cloud migration I did was at a startup that had to lease its servers on prem because it didn't have the Capex to buy them. They slotted in very well to the cloud financial model with the backing and blessing of the CFO. The worst cloud migrations I have done have been at companies with constraint on opex who didn't think through the reasons for doing it.

Perhaps rather than thinking in terms of capex and opex it would be best to just think in terms of money.

Ever since I read that story of a guy who ran some job on Google's cloud and made a programming error and racking up a $60,000 (!) bill over the weekend I've been steering clear of Cloud development.

I wiped my AWS account as soon as I was done with it.

I use VPS servers and run whatever I need on them, upping the memory and processor capacity as needed. No Cloud for me.

The cloud was a bad idea even before its inception. This is a cost balloon and the most easily hijacked part of IT. The shifty IT directors and their plans to rip off the companies by feeding the accountants a load of crap, but more likely enjoining them into the scam. I have aways said that data is the lifeblood of any IT system and should be secured by the owners. Cloud storage and anything that you rent in IT is the finest example of the emperor's new clothes.

After an initial euphoric rush to the cloud, administrators are questioning the value and promise of the tech giant's services.

This all has an eerie familiar feeling to it. Like we've been through it before... mainframes? vendor lock in? something similar? all of the above? Or is that me just not being a true cloud believer? Maybe we'll never know...

Here lies the fundamental issue, infrastructure exists for applications and applications are created by developers .

The biggest value for the cloud is to eliminate the need for button pushers polishing their VM's and trying to control developers because of inflated egos.

What reports like these fail to mention, is the developer velocity gained by being able to release features faster than being on premises. Of course, throw in the fact that you don't need admins to manage the infra, the ROI is well justified!

Ps, the pricing is a whole load of bullocks.. you don't mention what 3 node cluster configuration was used and any pricing concessions such as reservations were even considered. As with most articles on el register, just aimed at the admin who feels glorified pushing buttons.

Do I sense a developer with an inflated ego here?

Let's fix that opening statement:

Here lies the fundamental issue, infrastructure exists for applications and applications are created by developers exist for the business. It matters rather less who crested the application. It could be developed in house. It could alternatively be bought in or it could be FOSS (free as in beer as well as in speech!). And you don't need developers to install the last two.

I should point out that my preferred method of handling all this is as a unified team that develops and administers its own applications, in house and on prem. That way you don't write what you can't administer and if you find you can't administer it properly you rewrite it to fix it.

"Admins wonder if the cloud was such a good idea after all"

No shit!

The main driver is increased electricity prices.

Which would still also effect any organisation that's moved to the cloud if they had hypothetically kept running their own DC instead.

So this story is really: electricity has become more expensive which means it costs more to run servers.

Or is it that electricity has become more expensive and gives cloud vendors an excuse to hike their profit margins.

The ever-upward creep of cloud pricing, both in real terms and in relative comparison to on-prem costs, was openly predicted by quite a few people.

I think the electricity price idea is a red herring: all things being equal, for the same over time, power demand should decline as more efficient hardware is used.

The model is predicated that companies will find the move from CAPEX to OPEX preferable, especially as systems scale up: 100,000 servers will cost you more over time if you rent them, but you'll have to pay up front for your own. In addition, vendors promised that they would be the better administrators and would be able to squeeze greater efficiencies out of shared infrastructure than clients could on their own. However, it looks like that advantage disappeared a few years ago and has since been superseded by the hydra of complexity as the vendors have to manage more and more complex operations and abstractions. They're probably also introducing cross-subsidies to make their "AI" offerings looks more competitive: there are potential advantages there for those who don't offer them.

"would be able to squeeze greater efficiencies out of shared infrastructure"

Cui bono? Who gets to benefit from the greater efficiency?

There were a pile of promising OpenSource projects (Eucalyptus and DeltaCloud). That provided AWS API implementations so you could use cloud APIs completely independently of the cloud providers.

It would be great if we actually had a choice to run AWS workloads on-site.

Personally I realized the cloud scam (specifically, IaaS) back in 2010, and have been bitching about it ever since, fortunately have not really had to deal with it since 2012.

But there is another kind of cloud that may be worth while depending on your needs, that is SaaS. Even before cloud was a thing SaaS was in many places, from DNS/email/web hosting to CDNs and things like that. I have personal experience at my first SaaS company back in 2003-2006 which was years before I think I heard of the term cloud, where the software was so complex, immature, and unstable that the customers really could not operate it on prem. I was technical lead of a project in fact to demonstrate to our largest customer at the time AT&T that they could in fact operate it themselves. It involved me setting up the software on their systems and then we sort of trained them to use it from a demo perspective. It never saw any transactions nor had any crashes because there was no activity on it, but even they ran screaming and were happy to have our org continue to operate the software. There was literally hundreds of XML config files, where even an extra space in the config would cause the app to puke. We used client SSL certs for authentication for one part of the system(the only place I've ever used client certs), super complex Java stack running on Tomcat/Weblogic/Oracle. AT&T paid the company I worked for a $1 million check for successful completion of that particular project. The company was acquired in 2006, a couple of months after I left (fortunately was still able to go back and buy the rest of my stock options).

Fast forward 5-6 years and the different org I was at decided to use Chef configuration management. Similar situation (though not nearly as bad), operating that on prem looked to be pretty bad just based on comments I was reading at the time, so we opted for their cloud version (I think cost wise it was the same it was just a matter of preference which you wanted to do). Years after that I recall downloading Gitlab and installed it on prem, took one look at everything that was running and decided to nope out of that. Too complex, makes me feel like it would be super fragile. Developers ended up going with bitbucket at the time.

Companies have an excuse to make their software practically unusable from an on prem perspective by just making it so complicated and fragile, that the only real way to use it is with SaaS. I think that is applying to more and more products out there (at least ones that aren't desktop oriented).

Upside I suppose is for people like me who have been running mission critical internet facing infrastructure for the past 21 years that gives me plenty of opportunities in theory..

But for sure, IaaS, as deployed by all the major clouds is, and has always been quite a scam. Biggest factor is resource utilization, paying for what you provision rather than what you use. Fixed instance sizes, etc etc. Object storage I suppose is one of the few things that is pay for what you use, but even then of course the big clouds are super expensive compared to other (even cloud) options from what I've seen over the years.

But at least in many cases with SaaS the billing model is more clear(often times $ per user account which is easier to budget for and justify yes/no), and unlike IaaS you(customer) don't have to deal with the potential unreliability of the underlying infrastructure or software itself.