4 ms·

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 y

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.

stonogo 4y ago
> 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.
- ranman 4y ago
  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.
  - stonogo 4y ago
    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.
- tmaly 4y ago
  This sounds like something they will solve in cloud 2.0
dx034 4y ago
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.

stonogo 4y ago

> 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.

ranman 4y ago
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.
- stonogo 4y ago
  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.
tmaly 4y ago
This sounds like something they will solve in cloud 2.0

dx034 4y ago

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.