Hacker News Reader

Comment by rbanffy | Hacker News Reader

Software licensing is expensive on them, but the people to keep your 99.999% uptime on your Kubernetes cluster aren't cheap either.

And software licenses are one of the reasons why LinuxONE machines exist - they don't run z/OS, so you don't pay those licenses. You can even start a dozen VMs under an LPAR and run your Kubernetes cluster as if it were running on more common hardware that just never, ever fails. IIRC, you can run a special version of z/VM to manage your Linux VMs if you don't want to run Linux on the LPAR and use KVM for your VMs.

View on HN

When I moved from a tech company to an aero company who used mainframes, there were literally hordes of IBM contractors who helped maintain the mainframe environments. Getting anything done in those environments was a multi month project, even for basic stuff like patching the OS. There were probably 2 or more sysadmins per rack, employed to just keep the damn lights on those boxes.

For context, there was about 1 admin for every 400 servers at the tech company, and that was for the entire tech stack (LAMP).

Mainframes require a lot of care and feeding. In my experience, having worked at 3 different companies who relied on them (education, aero and finance), their capex is higher, their opex is higher and their uptime / reliability is entirely dependent on the facilities / staffing.

You don't think it requires some expensive mainframe admins, even with the fancy software? Anywhere I worked with a mainframe, the mainframe admin was highly distinguished within the org and extremely knowledgeable.

I would argue Kubernetes talent is cheaper than mainframe talent these days because it's ubiquitous.

I think the rough premise is there's a 1:>3-5 ratio of "super knowledgeable mainframe guy" to "super knowledgeable kubernetes guy".

Also, Kubernetes talent is far from ubiquitous. That sounds more to me like you're counting anyone who has successfully deployed one time.

Yeah, I am that super knowledgeable K8s guy, but I’d still say true mainframe admins are still a higher metric.

But in regards to K8s talent, lots of the people who think they know Kubernetes in production but have never had to actually upgrade the cluster, or go through the process of having to update manifests, deployments, and CSIs, and having to actually deal with api removals.

Agreed. The tooling around upgrades is painfully atrocious, and stuff like kubepug [1] should be part of the Kubernetes core.

[1] https://github.com/kubepug/kubepug

Why bother using an LPAR if you're just gonna use kubernetes anyway? Why not just use one fat machine?

LPAR isolation happens on a lower level than z/VM or KVM. I don't think anyone has ever demonstrated a successful LPAR escape attack.

The lack of escape demonstrations are likely, at least in partv due to a fairly low availability of those systems to the security researchers.

I do not want to make it see that LPAR isolation is just waiting to be compromised, but security-by-unavailability also plays a part :)

OTOH, the technology has been in production for decades.

It took many years for Spectre and Meltdown to be discovered, and that was for CPUs affordable for individuals.

How many security researchers are even familiar enough with the concept of a mainframe to consider looking for an LPAR breakout, let alone have access to the necessary hardware?

Also consider: anyone with access to a mainframe will never ever get approval to try to hack it because companies that have mainframes will never want the risk of accidentally breaking the host in some way.

>It took many years for Spectre and Meltdown to be discovered, and that was for CPUs affordable for individuals.

Both of these were anticipated in security papers dating back to the 1980s. It wasn't practical to use those types of exploits on 10mhz VAXen.

It may be implemented in the system firmware, but it's still a hypervisor performing context switches and enforcing access to pci devices. Even if you've never looked at the processor architecture manuals you can tell this is what's happening when you can assign 0.1 cores to an LPAR. Different implementation details but the same functionality as SPARC LDOMs and Intel's vt-x & vt-d.

Why bother using a mainframe LPAR for Linux at all? In most cases, it makes much more sense to run it as a guest under z/VM.

For many generations now, you can't run Linux on bare metal anymore, it has to be inside an LPAR. I think this is true for z/VM and the other operating systems as well.

Reply on news.ycombinator.com