The CAP theorem suggests some limits on a distributed systems approach. These matter very much in industries like banking and others involving financial transactions. It's no accident that checking each transaction for credit card fraud is listed as a feature. If there's float, there's an opportunity for arbitrage.

IBM is full of really smart people some of whom work on really hard problems using the principles of Computer science. The z13 wasn't the result of two recent grads pivoting a Yelp for Rabbits startup and the z13 isn't for companies hoping to do a billion transactions a day. It's for those doing it.

These things tend to be used nowadays as the single source of truth in middle of large distributed systems. When your data represent real value you really need full transactional semantics and when your transactional volume is large enough, buying or renting System z is the cheapest solution.

Computers, even these, are cheaper than development and opportunity costs for a complex system. Especially if that system has been around for 30+ years and lies at the core of a large business.

But development for mainframes seems to be much more costly than development on pc's. If you need this type of machine you need it, but it will probably cost you a lot to work with it over the years.

You say that as if managing a system at Google or AWS or Facebook scale is free. The downtime of individual servers may not matter as much in that architecture, but they each have an army of (costly!) engineers just to keep things running.

To say that the Google 'many-servers' approach is the only valid one is to overstate the trade-offs.

Distributed systems as a whole can still suffer from the same kind of issues that you would expect to see in a monolithic system. Look at how a single bad software update can take down Google or AWS.

At a basic level this kind of sytem gives you lots of low latency bandwidth connecting CPUs to each other and CPUs to storage. That is a useful quality to have and not neccessarily easily repoducible using network and internet connections between servers and data centers.

You're regurgitating 'common' wisdom here, but you really should check your assumptions and reality when it comes to current mainframes. IBM's mainframes have a minimum and maximum number of engines (CPU). An engine can be either general purpose (I forget the acronym they use) for use with z/OS, or can be a specialty engine (IFL, zIIP, zAAP). My understanding is that it's the same hardware, just a simple firmware update to tell the engine what 'type' it is. An IFL (what you would use to run Linux under z/VM) is significantly cheaper than the general purpose one used for z/OS. Also, mainframes can be loaded with more engines that what you've paid for -- this is what IBM calls Capacity-On-Demand (COD). So you can temporarily activate additional engines to handle spikes. The zSeries has some fantastic capabilities for Reliability, Availability, and Serviceability (RAS). The systems I've been around keep engine utilizations quite high (98/99%) as the norm.

A mainframe is typically partitioned into multiple, smaller systems. This is what IBM calls a Logical Partition (LPAR). This partitioning is done with firmware called PR/SM. This capability has been around since the 3090 (mid to late 80's). Within an LPAR, one typically installs either z/OS or z/VM (there are other systems too, but less commonly used this way). Running in an LPAR is 'bare metal'. Within z/VM, there's typically a mix of guest types, but this is where Linux would typically be configured to run. z/VM has some pretty impressive capabilities and has been around for a LONG time. It's very stable. The biggest things that you would probably dislike about it are: (1) one uses a 3270 emulator to do day-to-day system-level admin work, (2) it only runs (legally) on real mainframe hardware, and (3) much of IBM's jargon is dated and would unfamiliar to people coming from x86.

The modern mainframe hardware and software has an impressive feature set for virtualized networking (networking is all software defined and runs within the box). This means you can set up hundreds or thousands of Linux guests and have them on networks that are all virtualized within z/VM. And of course, z/VM guests can be created and spun-up on demand and stopped on-demand. This has been there for decades.

IBM now has support for OpenStack in z/VM. From what I've perused, it seems to be quite slick. Assuming it all works as advertised, this would make folks coming from x86 feel much more at home.

Many seem to think that distributed systems are so much cheaper. You can't just think of it as the price of the rack server though. You have to include everything in the mix to understand the total cost: hardware, software, networking, people (headcount and consulting), power and cooling, floorspace, and intangibles (such as capabilities). When you do the math, mainframes running Linux under z/VM are often fairly economical (YMMV).

Once you throw off the stereotypes and objectively dig into the modern mainframe, you might be surprised at what you find.

Excellent explanation! Specially the fact that within a mainframe you can create hundreds or even thousands of virtualized linux guests, which can be created or destroyed on demand. That makes for a much more compelling use case!