Hacker News Reader

Comment by filereaper | Hacker News Reader

Its weird to have companies say they're moving from Mainframes to the Cloud.

The Mainframe is a sort of cloud, each one has usually double the spare capacity and you call IBM to unlock it.

The cost of running a Mainframe is measured in terms of MIPS based on amount of compute used and there's compute reserved for offloading things like JITs (zAAPS). Essentially a version of cloud compute costs.

I can understand if you're locked into COBOL with EBCDIC and can't find talent, but Z runs freaking Ubuntu now! I know IBM works furiously on modern ecosystem support.

Not shill for IBM, but what exactly is it that they're expecting to be so different from their cloud migrations? Or is everyone here caught up in the "Mainframe old" falsehood.

View on HN

I doubt they have too much COBOL lock-in, since the article notes their datacenter opened in 2008.

Here's the thing: A mainframe may have spare capacity, but you still have to call IBM to unlock it. In order to make a Z run in a cost-effective manner, you need to run at 90%+ utilization at all times - which is excellent for batch jobs that can be scheduled, but is difficult to achieve with on-demand loads.

You're paying based on compute available, not just compute used (unless I'm misremembering our contracts back in the day). Sure, the amount of available capacity can be changed, but a phone call to big blue is not automated. Cloud autoscaling is.

You're right that IBM mainframes are far more modern and cost effective than we assume. Sadly, they are still behind the curve of cloud hosting.

> a phone call to big blue is not automated. Cloud autoscaling is.

Respectfully, the hell you say. Cloud 'autoscaling' is something that has to be tenderly maintained by software engineers, who expect to be paid salaries and benefits and so on. It's not like FedEx can just rsync their data into the cloud and have all their software run forever. Instead, they need the engineering team that manages their existing data workflows, and now they also need cloud engineers to translate that into something that won't bankrupt the company, since they're moving from the mainframe world (where you keep your system loaded to an efficient price point) to the cloud world (where you are billed by the second).

Moving your compute spend from capex to opex is a perfectly valid move, but pretending the reason is that someone has to make a phone call once in a while is kind of bizarre, when the alternative is having to hire a whole new cadre of techincal talent.

Why would one have to hire a whole new cadre of technical talent? Wouldn't it just be taking existing talent and/or ops teams and having them work with the autoscaling APIs as opposed to working with the data center teams. If the skillsets don't match then you can either train existing talent or, yes, hire new folks.

I agree the occasional phone call removed from your workflow isn't reason enough to justify a giant cloud migration... but it is one of many reasons.

I'll acknowledge that "have to" is maybe an exaggeration, but it's definitely going to be cheaper to hire new talent than reskill existing engineers (who may not even be interested in reskilling), and profit margins generally dictate the cheapest path forward in an ultracompetitive industry like logistics. And on top of all those issues, the existing workflows must be maintained while the cloud-adapted ones come online, and in a complex enough enterprise environment we're talking about a project that can take years to execute.

This sounds like something they will solve in cloud 2.0

I'm confused about the first data center in 2008. Surely they had data centers before that, or were they outsourced before? Automatic routing of deliveries has been the standard for many decades, I'm sure the code on their mainframes is much older than just 14 years.

> Its weird to have companies say they're moving from Mainframes to the Cloud.

Ever work for a company with their own datacenters that were NOT cutting edge? The work to provision resources can be so painful that it severely inhibits prototyping. Being able to spin up resources in seconds with some API calls is very valuable.

No one says you can't have both. An on-prem data center for reliable workloads and cloud to try out new stuff and products or to get short-term capacity. But in the end, 95%+ of servers in your data center will run 24/7 and for years on the same software. No need to outsource that.

> Or is everyone here caught up in the "Mainframe old" falsehood.

It's probably this. I've spent time trying to advocate for the benefits of these systems, but its like shooting a super soaker into the sun.

I think it’s also both the people making the tech decisions and the people implementing them simply don’t want to work on mainframes. I would 100% of the time prefer to work with an on-prem dc or colo using commodity hardware and OSS to mange it.

I get my pick of a billion different hardware vendors, they’re all interchangeable and interoperable, every problem I can possibly dream up has been solved a hundred times before. The skills are commonplace and transferable so hiring doesn’t mean convincing some poor desperate grad to get trained in the company script, hires will actually want the skills, and you can find senior people.

Can you elaborate a little? I'll admit I know close to nothing about mainframes.

Mainframes are still the best option for systems that cannot fail. Even business like FedEx is not as critical as some types of business I've seen ran through IBM.

A good example of where these systems come into their own is payment/ACH/wire processing. The consequences of these networks going down are so severe that it is worth it to construct an entire facility with the computer systems and business in mind from the very beginning.

Today, mainframes are more for the type of business that are finding the need to pour the literal foundations for their own datacenters. If you are even considering cloud as a viable path, then this kind of stuff is certainly not for you.

A lot of the cool tech that Linux and parts of cloud tech are crowing about are just new versions of stuff IBM was doing in the 1990’s. Sometimes I wish I knew some of those people, because I’m sure it would be fascinating to wind them up over a few beers and see what comes out of their mouths.

Mainframe = locked in to IBM, is probably the logic.

How is it any different than being locked to AWS/Azure/Oracle/Google?

Well your also hardware locked. The last time I worked on a mainframe (about a decade), 8 mb of RAM was $1000, a network card was $800. Commodity hardware around the same time 8mb was probably $50 and a network card even a good one was most $100.

You're paying a premium for both the hardware and the lack of develops knowing EBSIDIC, JCL, Cobol, etc..

Actually, from what I remember of Oracle, that might be very similar. I remember having to pay license fees per core.

You mean gb of memory right? Or you might have been working with several decades ago.

Its not be most C-level execs are these companies can present it as IT evolution and progress. Balance sheets look different because accounting has costs in different places. It all looks good.

The lock-in is less severe on AWS/Azure/Oracle/Google.

I'm assuming FedEx wants to be in the package delivery business, not the owning compute hardware, datacenter, cooling and power business.

The fundamental issue with mainframes is that IBM made ramping up talent on mainframes extremely painful. Sure they run Ubuntu but how does one actually get a mainframe environment to learn on?

Mainframes are still king when it comes to transaction processing but having such a closed off ecosystem has screwed them.

Even FPGA's are more accessible to learn. On AWS you can spin up eg; an F1 instance and get a dev environment.

> you call IBM

you don't need to call AWS. Negotiate a blanket deal and do whatever you need. Run whatever you want. Unsure? Check billing page.

Reply on news.ycombinator.com