Mainframes are still relevant for certain projects and legacy environments but unless you know you have that problem there is zero reason to greenfield there.
Writing off all the big computer shop stuff as irrelevant means you throw away all the experience and best practices and will be repeating the mistakes people made 50 years ago. And maybe reinvent some wheels too.
A computer center is your best resource for observing and learning how to build computer services, deploy them, and keep them available. And for knowing what experienced computing people and their customers expect.
And some of the stuff you do today is descended from here:
You probably wrote this comment in a program that displays forms, and allows you to fill in forms and call up other forms. This is how the 3270 terminal worked.
Maybe you have some hypervisor running somewhere. Welcome to 1970s IBM. We don't want to rewrite our 360 stuff so we will emulate the 360 in its own sandbox.
Saddest part of these things, when they come into general awareness one way or another, they are so out of tune with the universe that the public hail them as new "technology." The ideas are old, it's only some new implementation or circumstance that's novel.
It’s not completely irrelevant. Like I said, if you know you need big iron you use big iron (I dealt with as400s and cobol for years).
But it’s not a commonly taught tech anymore. I look at it like a lot of niche languages. Erlang has a lot of great advantages but if it costs several multiples more budget to hire for I’m going with python if I can get away with it.
I will always use the most boring possible tool to solve a problem because I don’t want to get stuck as the “that thing” guy. And because I’d rather spend my “effort” bucks on stuff that directly makes me money.
Edit: I’ve seen zseries feature set and it’s impressive. Still not going to use it over AWS if I can get away with it.
I think this betrays my ignorance (youth?) but what exactly does the author mean by 'mainframe'? Does the word imply a specific type of system, CPU architecture, OS, etc? My understanding was that 'mainframe' and 'server room/warehouse' are kind of interchangeable, and so a 'mainframe' can be as generic as any old physical server. I suspect that my understanding is quite incorrect...
Mainframe typically refers to a specific class of system, most famous example probably are the IBM z-series.
Rough differentiators: large single systems, optimized for reliability and throughput. Backwards-compatibility going far back, enabled by virtualization and abstraction.
> By working on mainframe systems newbies will learn the correct IT discipline for managing mission critical software.
I've spent my whole career avoiding mission critical software development: basically if it flies, runs in a hospital or alerts Hawaii of nuclear attack I don't want to touch it.
Some people have the mindset, some don't. I think it's very valuable to know which you are.
I have to disagree with the author on the security and change management. I work at an IBM iseries AS/400 shop. Our IT department does follow the normal protocol on the mainframe systems as well as our Windows and Linux systems, however if you have the elevated credentials on the AS/400, you can do anything such as install software or make configuration changes. In fact the problem with the iseries is that in order to perform certain essential system maintenance procedures, you need to have the equivalent of an Windows Enterprise admin logon rights.
Yes, we do have log files for all changes and go through the Sox compliance audits. As well as a ITIL change process, however the actual user rights could be improved by reducing the super admin rights for our operations team.
Some serious industries, banks, insurance companies, telco are using mainframes. I worked in one of that for a while and I learnt a lot. Besides, I don't think many people would prefer they bank accounts on the cloud ...
Basically it seems like the article is saying having mutliple people responsible for different aspects of server environment is better than one person doing it all and companies that have mainframes embrace that - also including snark that it's beneficial that mainframes have remained stagnant in features while open source keeps adapting and changing?
In these places, this is a great thing to avoid. Old software is well known. You do not want to be the one to be affected by a bug that stops production or changes data.
> mainframes have remained stagnant in features
Having a well known universe without any beta software, and not being disrupted by new stuff that you don't need anyway, is a damn good feature.
Meanwhile, some small startup is using newer technology that makes them many times more efficient. And allows them to utilize their IT as a core part of their product, instead of an internal utility service. And stealing all your customers.
Of course, there are industries that are immune to startup competition due to the high barrier of entry (banks, insurance, governments). I don't think it is a coincidence that these are about the only environments where mainframes are still dominant.
I spent the first 6 years of my career in a mainframe environment. There really is a lot of good there, especially for enterprises that have mission-critical applications.
But it must not have been that great, because I haven't gone back. :)
>Talk to anyone who has ever worked on a mainframe and you will see that they are acutely aware of important factors that are sometimes overlooked on other platforms. Things like security, control, scalability, and reliability are second nature to mainframe computer systems and applications.
Those things have always been apparent to the majority of my distributed peers.
> Well, it is because of the robust system management processes and procedures which are in place and working extremely well within every mainframe shop in the world. This is simply not the case for Windows, Unix, and other platforms. By working on mainframe systems newbies will learn the correct IT discipline for managing mission-critical software.
This just isn't logical, and he's not providing evidence. I think what he means is that by working fresh out of college in an environment with good processes the programmer will learn those processes, and become a better programmer. Why that required a mainframe environment isn't mentioned. It's also obviously not required, since there are plenty of places out there that run mission-critical software on non-mainframe systems, and have excellent processes in place.
I suspect the root here is that mainframe systems are so exorbitantly expensive that the additional expensive processes are required to maximize ROI, hence those processes being more likely to be in place, and rigorously enforced in a mainframe environment.
All the processes mentioned are required to be in place and well managed for all mission-critical systems - there's no actual argument here requiring a mainframe, except that it's more likely to be an indicator of good processes.
14 comments
[ 10.9 ms ] story [ 424 ms ] threadMainframes are still relevant for certain projects and legacy environments but unless you know you have that problem there is zero reason to greenfield there.
A computer center is your best resource for observing and learning how to build computer services, deploy them, and keep them available. And for knowing what experienced computing people and their customers expect.
And some of the stuff you do today is descended from here:
You probably wrote this comment in a program that displays forms, and allows you to fill in forms and call up other forms. This is how the 3270 terminal worked.
Maybe you have some hypervisor running somewhere. Welcome to 1970s IBM. We don't want to rewrite our 360 stuff so we will emulate the 360 in its own sandbox.
Saddest part of these things, when they come into general awareness one way or another, they are so out of tune with the universe that the public hail them as new "technology." The ideas are old, it's only some new implementation or circumstance that's novel.
But it’s not a commonly taught tech anymore. I look at it like a lot of niche languages. Erlang has a lot of great advantages but if it costs several multiples more budget to hire for I’m going with python if I can get away with it.
I will always use the most boring possible tool to solve a problem because I don’t want to get stuck as the “that thing” guy. And because I’d rather spend my “effort” bucks on stuff that directly makes me money.
Edit: I’ve seen zseries feature set and it’s impressive. Still not going to use it over AWS if I can get away with it.
Rough differentiators: large single systems, optimized for reliability and throughput. Backwards-compatibility going far back, enabled by virtualization and abstraction.
https://en.wikipedia.org/wiki/Mainframe_computer#Design
I've spent my whole career avoiding mission critical software development: basically if it flies, runs in a hospital or alerts Hawaii of nuclear attack I don't want to touch it.
Some people have the mindset, some don't. I think it's very valuable to know which you are.
In these places, this is a great thing to avoid. Old software is well known. You do not want to be the one to be affected by a bug that stops production or changes data.
> mainframes have remained stagnant in features
Having a well known universe without any beta software, and not being disrupted by new stuff that you don't need anyway, is a damn good feature.
Of course, there are industries that are immune to startup competition due to the high barrier of entry (banks, insurance, governments). I don't think it is a coincidence that these are about the only environments where mainframes are still dominant.
But it must not have been that great, because I haven't gone back. :)
>Talk to anyone who has ever worked on a mainframe and you will see that they are acutely aware of important factors that are sometimes overlooked on other platforms. Things like security, control, scalability, and reliability are second nature to mainframe computer systems and applications.
Those things have always been apparent to the majority of my distributed peers.
> Well, it is because of the robust system management processes and procedures which are in place and working extremely well within every mainframe shop in the world. This is simply not the case for Windows, Unix, and other platforms. By working on mainframe systems newbies will learn the correct IT discipline for managing mission-critical software.
This just isn't logical, and he's not providing evidence. I think what he means is that by working fresh out of college in an environment with good processes the programmer will learn those processes, and become a better programmer. Why that required a mainframe environment isn't mentioned. It's also obviously not required, since there are plenty of places out there that run mission-critical software on non-mainframe systems, and have excellent processes in place.
I suspect the root here is that mainframe systems are so exorbitantly expensive that the additional expensive processes are required to maximize ROI, hence those processes being more likely to be in place, and rigorously enforced in a mainframe environment.
All the processes mentioned are required to be in place and well managed for all mission-critical systems - there's no actual argument here requiring a mainframe, except that it's more likely to be an indicator of good processes.