SHARE San Jose 2017

Linux on System z - Financial Trading demo from LinuxCon

Donna Dillenberger is showing a pure open source demo on the mainframe combining all the new technologies like Spark, MongoDB, Postgres, MariaDB, Node.js, Docker, Chef etc.
It's using live analytics for streams from Twitter and S&P financial data, showing the power of realtime analysis on the mainframe.
She is also providing a look at the infrastrucure driving this and even shows a fail over from one site to another using Hyperswap.
Towards the end she is providing real performance data for some of the components used.
During this presentation your probably want to pause and playback to get all the information she packed into those 18 minutes. Here is a breakdown (minutes:seconds) for reference:

• 0:00: demonstration
• 7:48: a look at the infrastructure
• 11:22: failover by killing one storage subsystem
• 13:45: performance data
• 17:00: agility & summary

(updated 8/19/2015)

Linux on z Docker demo at DockerCon

Since a while there is an experimental version of Docker available for Linux on z. This has now been demoed at DockerCon. Here is the video link: the demo starts around 15:40. Of course they could have run everything on System z and some more visual bells and whistles could have been added fro marketing.
However from a technical point of view it shows the prototype running and integrating with all the cool cloud stuff from Docker :-) 

Middleware / application testing - operating system, hypervisor and hardware

After the IBM statement of directions to support KVM on System z I've been asked many times for a criteria if a certain ISV software or customer solution needs to be retested or not. As in performance the answer is: it depends. Basically there are two / four different types of applications / products to consider

1. No retesting needed - certified and tested towards the operating system:
   Applications that use a standard API only, like Java or standard library functions that don't need and exploit the visibility of the underlying (virtualized) hardware.
2. Retesting recommended - certified and tested towards the operating system:
   Applications that do interact with virtualized hardware to a certain extend e.g. accessing raw devices.
3. Retesting and some coding needed - certified and tested towards the operating system and the virtualization layer:
   Applications that actively interact with the hypervisor, e.g. by vmcp commands under z/VM. They then needs an equivalent implementation of that kind of functionality for every type of virtualization. Other examles are the use of zLinux hypfs (hypervisor file system) or using the hypervisor details surfaced in /proc/sysinfo.
4. Retesting and additional code for the hypervisor needed - certified and tested towards the operating system and the virtualization layer:
   Applications that need hooks and special interfaces into the hypervisor e.g. for monitoring or systems management. Every new hypervisor will require new code as e.g. the reported performance metrics and systems management interfaces are different

For Linux on the mainframe today there is only z/VM and LPAR. And z/VM is really virtualizing the hardware in a 1:1 fashion as good as possible (with a lot of firmware and hardware support to keep the overhead to minimal levels).  For such a hardware virtualization the category #2 is nearly not existent. If there is no active interaction with hypervisor, no retesting is needed.
KVM has the concept of new virtual devices with new device names, so some products from #1 are going to slip into category #2.

(updated 4/15/2015)