There are lot of interesting technologies that we should pay attention to from mainframes particularly in managing distributed processes, interesting IO and accelerator configurations, etc. But this article seriously misses the mark and makes some bad arguments that show this person hasn't really administered a non-mainframe server in the last decade or so. He's also an "IBM Gold Consultant" we should take this with a huge grain of salt.

> It should not be an acceptable practice to just insert a CD and indiscriminately install software onto a production machine.

This assumes your machine is set up correctly. I've worked on some mainframes where everyone could access customer data and swap out production executable freely. Why? Because no engineer wanted to deal with 6 layers of bureaucracy to debug an issue or update a library. Segmenting the data and isolating specific infrastructure has proven out to be more efficient and more secure.

> Nor should it be acceptable to just flip the switch and reboot the server.

These are more about the fact that there is one mainframe. The reality is for distributed systems that anyone can flip the switch at any time and you better plan for that up front. Its a good thing that I can restart my laptop, or production servers whenever I need for updates, and don't need to do 6 months of business continuity planning for "update day".

> In mainframe shops there is an entire group of people in the operations department responsible for protecting and securing mainframe systems, applications, and data.

As does any non-negligent mid-sized organization. Having a security team is very standard at this point.

> Ever wonder why there are no mainframe viruses?

Because no hacker can afford to have an IBM mainframe running in their garage?

> There is even a term – the accidental DBA – that has been coined in the SQL Server world for developers who become the DBA because nobody else is doing it. Such a situation is unheard of in the mainframe world – indeed, you’d be laughed at if you even suggested it!

Great now I need to hire extra people to specifically administer my very expensive database deployments instead of relying on a cloud provided database and relying on general "DevOps" people to have enough knowledge to troubleshoot some specific problems. The DBA didn't go away for no reason, they've just largely outlived their economic usefulness.