bluecmd

Author here, I might write a blog article about that because it is really quite interesting.

The TL;DR is that some might want to rather run 1 or 2 systems (mainframe) instead of 100 physical machines (conventional distributed cattle system).

Now, IBM does make it quite expensive but the mainframe has some pretty cool features like pay-for-what-you-use (which you of course get with the cloud, but not so much if you also want your data in-house).

Anyway, it is a fun beer topic if nothing else :-)

For what it is worth, it will run using 100% renewable energy at https://datacenterlight.ch :-).

Correct, it will run at https://datacenterlight.ch using 100% renewable energy. It the least I can do to offset the ~3 kW everything (z114 + dasd + everything else) will consume.

Do you have a source on that new banks do not use mainframes? I'd love to learn what new banks use to talk to older banks.

Hi, author here. Spot on! It is pretty common to see mainframe courses for $10k each - so given how much I hope to learn I kind of justify the cost just on that. Now, I do not expect to change to work on mainframes full time, but maybe it can grow into a side gig? Who knows! I do enjoy the process anyhow so it feels like a win-win :-).

Thanks for reading!

Hi kev! Thanks for your comments, you are 100% right. Yes, living in the states make this hobby waaay easier. The surplus auctions help as well, having various goverments with various languages going in Europe does not make it as easy :-).

Was $3000 your outlay for the system + the DS6800? Or just the shipping? That is a great find in that case!

I just want to correct a small thing: You need SEs (the frame mounted laptops), you do not actually need an HMC as far as I know. Do you have any information that tells another story? If so I will update the article.

Thanks again!

A lot of these debug features are re-enabled on SoC reset so there are quite interesting attacks you can do there just given access to reboot the SoC. Attack before the OS has been loaded and has had time to disable the features and you win.

These are silicon issues as far as I know.

We used ScaleFT for Dreamhack (https://www.scaleft.com/blog/how-dreamhack-used-scaleft-to-s...) and it was very easy to work with. A very good product if your company simply wants something that works.

From the github page:

> Disclaimer: This is not an official Google product.

Here in Sweden it's common to fly on unleaded AVGAS.

It's up to the SREs taking over the service. A storage SRE PRR is different from an Ads SRE PRR.

Or the Yubico official https://developers.yubico.com/libu2f-host/ - that will do the same

Quite interesting that super-sonic flight was achieved 1946. I don't know if Orville was informed, but imagine that - from barely flying to supersonic in 40 years.

FWIW, that is what stopped OpenRISC to become part of mainstream GCC.

If you always require a short-term win, you will lose in the long-term. When the company is 100x the size it is today, the savings are quite substantial.

Things change

> ordinary site maintenance position

Seems you don't know much what Google's SRE job is about.

Isn't that widely known though? Don't trust random peers on the internet. Hardly a take-away.

Yes, and together with systemd it makes it super trivial to run stuff on things like privileged ports or sending ICMP and stuff like that. Great stuff!

Wouldn't the nounce approach described in the article work for this?

Usually you run NS behind anycast, so the actual number of servers can be vastly bigger. But since this is NK, maybe 5 is reasonable.

Any form of NAT is also much much more expensive than just normal routing. For n:m NAT you need to keep track of sessions for example. This is going to hurt things like BitTorrent among a lot of things.

How is that relevant? The author didn't complain about the performance - the complaint was about API stability. Which I agree with. Docker is really terrible at supporting their own APIs.

Neat! How do you handle versioning? If you want to have docs for release 1.0, 1.5, 2.0 but also "master" - how would that work in Doctor?

Sure, but won't you be in debt for possibly a few decades?

A "probably" there would be nice. I don't want to have to defend myself, but I'm pretty confident about the scale I've worked on.

I guess it boils down to what you call aggregation.

Is having multiple stateless receivers behind anycast/ECMP aggregation writing to a distributed database aggregation? I'd argue not, but maybe this is where the difference in opinion lies.

They say that without aggregation scale-out is impossible. That's simply not true. Using things like anycast and ECMP it's super easy as log destinations are usually stateless.

Also, never had network contention because I logged too much unless something was really broken - and then only at that node.

I'll continue sending events to my anycast address without any aggregation thank you very much.

But... they really don't. There is a lot of things that will make the auto pilot disengage and you will always need to change the programming enroute.

You make a good point, but I don't see it as black and white.

> 4) Are you absolutely positive that your app is worthless without a DB/redis/backend-baz, and every endpoint is broken?

Yes, if that's the case you should not respond "unable to serve". However, you should probably fail setup check and not start serving traffic if you're a newly provisioned node.

But!

I wouldn't call this cascading failure more than error propagation. If a critical dependency is down making the node essential worthless, it should be removed. This can be caused by things like network partitions and whatnot - as you say by 5. You say "it's not likely" which is sadly a common statement, but when it does happen it can be nasty - and the bigger environment the often it happens.

Cascading failure usually (in my experience anyway) refers to having the actual failover cause more outages. In the case of failing /status I can only see this happening if the architecture of the system is broken anyway - or the load is genuinely too high for the failure that just occurred.

You say: "The DB and overall health of the service cluster are monitored through more organic instrumentation". What is acting on that? What happens when you do get that rare network partition and half of your web nodes cannot reach the database?