"Right now most of my focus is in the financial industry. I would say "in the US" but the truth is that my clients are multi-national behemoths. I'm regularly on plane flights to EMEA and APAC."

I'm in a similar situation, though more North America focused.

"Believe me when I tell you that they are still running systems that were around in the 70's. They have a significant investment in code that can only properly run in a mainframe environment and isn't going to get thrown away anytime soon."

Yep, I agree. Though I've witnessed at least one that actually ditched the mainframe completely... for SAP core banking. It wasn't pretty.

"Does OpenStack even have a way to upgrade from Juno to Kilo with ZERO downtime?"

I'm not one to defend OpenStack. :)

"And here is ANOTHER barrier: they can't readily do business with startups. It just doesn't work for them. "

The brokerages in particular have a long history of working with startups at certainly layers of the stack. Retail banks, I tend to agree with you, but it really depends.

Startups of a certain size and maturity (100 people+, a few years old) in many cases tend towards even better support than larger companies because they actually CARE about the outcome, and aren't bogged by the bureaucracy of fighting divisions. (How many times does the pre-sales team have to fly in to fix the screw-ups of the consulting group, or vice versa? etc.)

Every stodgy bank on the planet wants to work with Docker (150 employees now btw), for example, once they have a product to sell.

"And it's not enough to say "well they have the source code" and can support it themselves. That doesn't work for them when the auditors come out and need to identify WHO is responsible for taking care of support and the lifecycle of the code. They write the code for their applications; you can't expect them to code big parts of their OS too."

I'm not sure anyone is realistically expecting that. Pivotal (not exactly a startup at 1500+ employees, but sometimes feels like one) for example supports the OS inside Cloud Foundry for the customer, providing patches, upgrades, minimal downtime rolling updates, etc. It's all open source but has 24x7 enterprise support.

"Handling of outages tends to be business-specific so NoOPS style models don't work everywhere. It's fine for FB, but not NYSE."

I'm not sure I agree here. Having an operating platform handle self-healing and auto-recovery is sort of standard with VMware DRS/HA (admittedly not everyone runs with it turned on). All these cloud platforms are doing is the similar stuff for load balanced application containers and the VMs they run on. I think this really is marking a major shift away from bespoke CMDB-driven "how do we recover the service? get 20 people on a concall" towards systems that reorganize themselves. Yes, there is a legacy that's not going to get this, and needs its small armies... but we've seen shifts away from that before when Java and .NET hit the market.

"Transactional databases are in far more places than you'd expect."

I'd expect them to be everywhere and anywhere.

"I love virtual infrastructure but there are still too many open questions that need answers before it's going to be a complete solution for mission critical stuff"

There's a difference between virtual infra and cloud. Virtual infra already handles mission critical stuff in most of the world. Yes, plenty of bare metal and big iron too, but that's actively shrinking. Cloud runs lots of mission critical stuff too, but not with companies born prior to 1990... though that's changing. I agree there is a risk calculation to be made here, but I don't believe it is going to take more than a few years. We are talking orders of magnitude in economic difference for time/cost in many cases. Speed with safety is addictive. Most believe the speed of cloud - the safety part we're verifying now as an industry, and it's happening everywhere.