Problem is we kitted out two 42U racks in two DCs with HP and EMC kit on VMware and got four humans for five years for less than the comparable quote from IBM. And we've tested replication and failover to the same extent and didnt have to rewrite the 2 million lines or so of code we have...
Back in the late 1990s I was involved in provisioning a large Sun e15k. Not indestructable but nearly.
It broke. You know what happened? The factory roof leaked and poured water onto the DC sub-building which the roof then collapsed onto the e15k which promptly blew up and caused a spectacular fire, halon dump and about a month of work arguing with insurance companies and guys with shovels.
In that circumstance, it doesn't matter what promises the vendor make. That's still all your eggs in one basket.
Buy two and keep one somewhere else didn't help either as the network termination, switching and routing layers were down and all the people using it were about 300 miles away from the backup location anyway. So some poor fucker had to dismantle the backup e15k and disk arrays, bring them in a large truck[1] to the original location and erect a temp DC in a portakabin outside the building.
Edit: We would have been better served with two smaller DCs with off the shelf kit on the same site but different buildings running a mirrored arrangement. All for pocket change compared to a zSeries...
That's what the company I work for now do. We have off the shelf kit,SAN replication, ESX, redundant routing and multiple peers in different locations.
There's nothing wrong with dynamic allocation in a kernel. It is for example better than having fixed size process tables and all the crap that comes with that.
"holy crap I've got to recompile my kernel to get more processes" is so 1995...
I've been open to it. I went on a journey of SICP, Common Lisp, Haskell and F# over three years.
I went back to my OO roots and c#/c++ and carried on mostly as I did before. Why?
Simply that its easier to rationalise a large system in terms of objects and actions. Even atypical OO languages like Go use this model.
What I did take away was limited mutability (not total immutability) and some functional paradigms such as map/filter and a well founded opinion that one shouldn't listen to programming religious wars and use what works for you.
Money is good though so that's some consolation :)
Salesforce is the root of all evil. Once you're in the ecosystem, you're stuffed. You know it's bad when the entire business team start running round clucking when the EMEA salesforce instance goes down hard...
AWS is fine. Most of the platform's concepts have real world parallels for example.
Exactly. I just want to keep a couple of processes running without having to learn the DJB ecosystem. I also want them portable if we shift off CentOS to Ubuntu in the future or something.
I have found that systemd whilst large is actually spot on for managing services particularly from say ansible. Just drop a service file and the binary on disk and start the service. No external supervisor process, no funny acres of bash to HUP and KILL stuff. Just works.
It solves the old problem of "so how the hell do I restart this network interface on distro X" as well.
I'm a pragmatist and it does solve a lot of core configuration issues with Linux.