[scalemaxx]

Everything comes circle. Back in my day, we just called it a "data center". Or on-premise. You know, before the cloud even existed. A 1990s VP of IT would look at this post and say, what's new? Better computing for sure. Better virtualization and administration software, definitely. Cooling and power and racks? More of the same.

The argument made 2 decades ago was that you shouldn't own the infrastructure (capital expense) and instead just account for the cost as operational expense (opex). The rationale was you exchange ownership for rent. Make your headache someone else's headache.

The ping pong between centralized vs decentralized, owned vs rented, will just keep going. It's never an either or, but when companies make it all-or-nothing then you have to really examine the specifics.

[IG_Semmelweiss]

There's a very interesting insight from your message.

The Cloud providers made a lot of sense to finance departments since aside from the promised savings, you would take that cloud expense now and lower your tax rate.

After the passing of the One Beautiful Bill ("OBB"), the law allows you to accelerate CapEx to instead expense it[1], similar to the benefit given by cloud service providers.

This puts way more wind on the sails of the on-prem movement, for sure

[1] https://www.iqxbusiness.com/big-beautiful-bill-impact-on-cap...

[conductr]

CFO here and I capex everything I can, never understood why you'd want to opex this. I'm trying to make EBITDA as enticing as possible for investors and anyone else that cares. Also want to show we have control over technology cost and it grows at a step function instead of a linear. Capex spending is usually large and planned, so we monitor it more closely and need to see a good reason to approve a large new purchase. Giving AWS a credit card is giving devs a blank check.

[IG_Semmelweiss]

its quite simple.

if you are a profitable company paying taxes, you 100% want to defer taxes (part of EBITDA) thus trade earnings for market share.

This is exactly what TCI did [1] with cable

[1] https://www.colinkeeley.com/blog/john-malone-operating-manua...

[conductr]

Believe you're talking about conserving cash through reduced taxes since this guy was against paying taxes.

However, spending a premium on cloud services over what you could with an on-prem capital investment does not help your cash position.

His tenant of frugality would have conflicted, especially since the cloud premium can easily exceed the tax rate - that is to say, paying taxes would have been cheaper

Section in your linked article about frugality https://www.colinkeeley.com/blog/john-malone-operating-manua...

In any case, spending on this either opex or capex doesn't help you gain or lose marketshare. Conserving cash can help, so you'd want to employ the lower cost option regardless of what line of the financial statement it hits - it's not going to be cloud if you follow that thought through

If cost was equal then opex gives a tax advantage, most companies are valued on EBITDA so still may not be their priority to optimize tax spend - a lot of other methods to avoid taxes. But the environment I've operated in I choose to capex because it conserves cash (is cheaper) and improves EBITDA optics (is excluded)

[tedd4u]

Probably depends on where your gross margins would be with cloud and if you're higher or lower growth. If cloud will let you grow faster (HA/DR on-prem is hard) and you'll still have 75-80%+ gross margins, why slow top-line growth to do on-prem?

[conductr]

It’s not a real concern for vast majority of businesses. It’s a common excuse but practically no business is outgrowing a cheaper than cloud solution. Maybe on-prem isn’t right first step, but that doesn’t force you to cloud. There’s dedicated servers and everything in between.

On prem is maybe not the best first step but Colo or dedicated servers gives you a cleaner path to going on-prem if you ever decide to. The cost of growth is too high in cloud.

Learning how to run servers is actually less complicated than all the cloud architecture stuff and doesn’t have to be slower. There’s no one sized fits all, but I believe old boring solutions should be employed first and could be used to run most applications. Technology has a way of getting more complex every year just to accomplish the same tasks. But that’s largely optional.

[IG_Semmelweiss]

I didn't say conserve cash.

I say lower your tax bill.

"not the same ting" - nnt

[conductr]

What you said doesn’t make sense. Make it make sense. I was left guessing.

In other words, please explain how it makes sense to lower tax bill by shift the expenses to opex when that process involves paying more for the same utility?

The only reason to lower the tax bill is to conserve cash. The article you linked to explains it that way too.

[re-thc]

> you shouldn't own the infrastructure (capital expense) and instead just account for the cost as operational expense (opex)

That was part of the reason.

The real reason was the internal infrastructure team in many orgs got nowhere. There was a huge queue and many teams instead had to find infinite workarounds including standing up their own. The "cloud" provided a standardized way to at least deal with this mess e.g. single source of billing.

> A 1990s VP of IT would look at this post and say, what's new?

Speed. The US lives in luxury but outside of that it often takes a LONG time to get proper servers. You don't just go online. There are many places where you have to talk to a vendor with no list price and the drama continues. Being out of capacity can mean weeks to months before you get anywhere.

[sanderjd]

Yep! The biggest win for me when AWS came out was that I could self-serve what I needed and put it on a credit card, rather than filing a ticket and waiting some number of days / weeks / months to get a new VM approved and deployed.

[scalemaxx]

I agree - my reference to the 1990s VP of IT was looking at the post, which is about on-premise data centers... not the cloud. I don't think there's a speed advantage for on-premise data centers now vs the 1990s, but if there is let me know. Otherwise, indeed, it's a 1990s-era blast from the past.

[ragall]

> There are many places where you have to talk to a vendor with no list price

Which many places ?

[conductr]

Curious question. If opex is so exceedingly high for cloud, pushing people back to capex to save money, then why has no cloud entrant come around with a price competitive alternative?

It seems the main issue is that everyone is anchored to AWS so they have no incentive to reduce their prices. Probably same for Azure. I think Google is just risky because they kill products so easily.

[nine_k]

It's just, like, not very easy? Say, Digital Ocean is one such entrant. Hetzner Cloud is, too, but it offers much, much fewer services than AWS. If all you want is spinning up instances, attaching storage, and maybe running a managed database and a managed k8s, it may be adequate. If you want DNS, queue services, email services, OCR, etc, etc, AWS has the widest assortment, and uniform access controls.

[conductr]

Once you build on AWS it’s hard to decouple. I get that. But companies that focus on reducing complexity still seem to find a way to do all these things for cheaper. Can’t find the link but yesterday there was a front page article about how you can just use Postgres instead of 7 other specialty databases. The reduced complexity of using one tool is a net gain. People just aren’t trying. It’s the whole “never got fired for buying IBM” thing again.

[the_af]

Agreed. Also, a realistic assessment should not downplay the very real overhead and headache of managing your on-premise data center. It comes at a cost in engineering/firefighting hours, it's not painless. There's a reason this eternal ping pong keeps going on!

[adolph]

Yeah, I think the major improvement of cloud services was the rationalization of them into services with a cost instead of "ask that person for a whatsit" and "hopefully the associate goomba will approve."

All teams will henceforth expose their data and functionality through service interfaces

https://gist.github.com/chitchcock/1281611