[Tubby Isaacs]

`Thanks. I did see some explanation of why they're often near London. I'll see if I can find it again.

[Boiler]

Maybe the much-vaunted Rolls-Royce mini nuclear power stations?

Like fusion which is always 30 years away, I suspect SMRs will always be 5 years in the future.

I saw someone BTL on the Guardian get very snotty with someone who said that re: fusion - "oh, are you an engineer in this field? Because I am." I waited for the "I am very intelligent", but it never came.

[Bones McCoy]

`Thanks. I did see some explanation of why they're often near London. I'll see if I can find it again.

Laziness. They want to hop in a cab and show their config guys where the kit lives.

They will feed you some bullcrap about latency.
But all current cloud works on a 3 copies in geographically distinct sites basis.
Where Geographically distinct is set to match the exclusion zones of a nuclear incident.

If your application is sensitive to tenths of milliseconds latency, then Cloud isn't the answer you need.
A good example of this would be the national grid, who have premises housing computers relatively close to major sites.
Hint: There's a lot of national grid that's in NotLondon.

And if you're running cloud stuff that is millisecond sensitive....
You're asking for trouble fomr black hats who learned their tricks during the high-frequency trading boom.

[Tubby Isaacs]

It was indeed something about latency.

[Boiler]

Isn't that what PTP (Precision Timing Protocol) is for?

[Bones McCoy]

It was indeed something about latency.

There's a third aspect to Latency which I through had been completely resolved.

Back in the decade of the 2000s, wide area networking became much more affordable.
And a viable generation of VPNs emerged that might allow you to tunnel international computer links through the Internet.

An example of "More affordable", a business with 150 staff in Glasgow and 30 in Edinburgh.
The smart money choice was to spend £125,000 on duplicating the important processing kit in the branch office.
Because buying sufficient bandwidth to let the Edinburgh staff connect to the Glasgow server was around 60 grand per year.
In a Lunar Module / smartwatch type comparison, that expensive bandwidth was about a fifth of what you'll get off a £30/mth fibre connection today.

Some people did tunnelling, it was relatively slow, and the industry observed massive performance differences between very similar applications.
We're off into database programming past this point, well beyond my ken.
But the answer for dummies was that some applications would transfer a tiny amount of data and await acknowledgement before sending the next tiny piece.
Sometimes these were old applications, where the database of the day had very limited buffer capacity.
Far more were relatively new, on the latest+greatest database, but the programmers had simply forklifted the old code across without paying attention to tuning.

You don't notice this sort of lag if you're on the next floor of the building and transmission takes microseconds.
If you're attempting to update HR records from Paris, France to a server is in Sunny California we're looking at a hundred milliseconds or so.
If your application is tuned to send an entire personnel record, you'll barely notice.
But if it sends 400 lines of data one by one, you're looking t a half minute before your screen updates.

I've picked pathalogically bad examples to illustrate.
I suspect the third driving category is "shit code".


Consider also that the cloud claims to be location independent.
You may have reserved space on servers in the Londona nd Dublin datacentres, with a recovery only backup in Kansas.
But the small print means you could be perfectly legitimately bounced to Kansas if another customer bids higher on capacity spot pricing.

I hope I've bored you all to sleep now.
Or at least to the point where "Nuke the place from orbit" seems the better option.