[Info-vax] VMS on Raspberry Pi 5
56d.1152
56d.1152 at ztq9.net
Sat Nov 18 01:16:41 EST 2023
On 11/16/23 10:46 AM, Ahem A Rivet's Shot wrote:
> On 16 Nov 2023 13:36:17 -0000
> kludge at panix.com (Scott Dorsey) wrote:
>
>> The IBM systems are I/O machines. The CPU is just sitting there telling
>> the I/O controllers what to do and most of the real work is being done by
>> other hardware outside the CPU. So you can have incredibly high
>> workloads and huge transation rates with relatively slow CPUs.
>
> Yes you can but ...
>
>> This was a huge win as late as a decade ago, but these days it's not that
>> much of a win unless you have a write-mostly database that is inefficient
>> to distribute. Because CPU has become so damn cheap that we just throw
>> CPU at problems now.
>
> Back in 1990 I was involved in designing a system that could not
> have been run on the mainframes of the day because they had insufficient IO
> bandwidth but a distributed solution spread across twenty high end 88K
> machines did.
>
>>> Tell that to Amazon, Google etc. look into the architecture of
>>> Amazon Dynamo and marvel at the way it scales and handles machine
>>> failures and network outages. Mainframes are great up to a point, right
>>> up until you can't get one big enough and then you *need* a scalable
>>> solution. kubernetes is an easy way to get one.
>>
>> This is true, but Amazon and Google -are- still slow and insecure in ways
>> that I don't think is apparently obvious. Instead of keeping one thing
>> secure, you have thousands upon thousands to keep secure.
>
> Yes but instead of trying to secure each one individually you write
> rules which are used by the deployment engine (kubernetes usually).
>
> A single instance implemented on virtual hardware is certainly
> slower than the same thing implemented on bare metal - the win comes from
> having a scalable design. The artful part is making the design scalable and
> not putting bottlenecks in it. If the single instance is 1/10th the speed
> of bare metal but you can run a thousand instances in parallel then you
> have 100 times the speed of bare metal.
>
>>> SAAS is huge in the large corporate world, it all runs on
>>> virtual machines and docker containers orchestrated by kubernetes. It's
>>> only insecure if you don't know how to secure it, the most security
>>> sensitive run it all in their own datacentres on hypervisors that they
>>> control. The rest trust the contractual obligations of the companies that
>>> run the data centres (Microsoft, Google and Amazon mostly).
>>
>> This is where the scary part is, yes.
>
> Yes it is - that's why my data lives at home. I don't need scalable
> solutions thankfully. Those who do and care a lot run their own.
>
Ok, there ARE apps like Google that NEED what are
essentially "infinitely scalable" solutions.
However the poster WAS right about something ... the
more you go that way the more vague and unmanagible
the 'security' issues become. Docker/Kubernetes are
NOT as secure as their authors like to claim and
indeed any super-"spread out" solution will also
suffer issues. It's a TRADE-OFF.
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
More information about the Info-vax
mailing list