5 ms·

Containers have been around for 15 years. They are not "newfangled" anymore.

by zer0tonin 3y ago

AnimalMuppet 3y ago
At the rate bank IT changes, maybe they kind of still are.
deleted 3y ago
[deleted]
pjmlp 3y ago
Containers in UNIX and mainframes predate Linux containers, thus a bit longer than that. The big difference is that we did not use them to ship the developer's computer into production.
derefr 3y ago
You're specifically talking about Docker/OCI containers; but "containers" have actually been around a lot longer than that — specifically on the sorts of mainframe systems that banks use. A workload on e.g. IBM z/VM is/was basically "a container" — in the sense that it was an application filesystem or binary, packaged up with a manifest that specified what environment the application expects to be run under; where it's the workload manager's responsibility to arrange a sandbox to run the application within that'll meet the application's needs. Of course, this was less about supplying an operating system to wrap around the container-image (ala Elastic Beanstalk), and more about supplying a particular flavor of emulated hardware for the workload to run "on bare metal" against. But applications of the day were bare metal — unikernels, if you want to call them that — and mainframe ISAs/memory-maps of the day were much like older-generation game console ISAs/memory-maps, in that the "bare metal" directly exposed advanced host services through CPU instructions and IO ports specific to the microarchitecture of the machine. The hardware "was" the OS, per se; and so emulating different hardware was in effect a virtualization of different operating systems. A good way to understand these mainframe ISAs, might be to picture a high-level and complex runtime-based compilation target like Macromedia Flash bytecode: sure, it's "an ISA", but each op can cause extremely complex things to happen at the runtime level. The "runtime" of a physical mainframe would originally be "in hardware" — consisting of "accelerator" boards triggered by the CPU. But in z/VM, the "runtimes" of each "hardware profile" a workload might ask to be run under, are just regular old runtimes. Like Flash. Or a JVM. Or a software x86 emulator, with hardware paravirtualization care of x86 "application processors" living on accelerator cards. To me, this abstraction — of a hypervisor that can support running workloads built for many different ISAs and microarchitectures, with these representing anything from low-level-emulated real machines (like x86) to high-level-virtualized real machines (like some specific mainframe) to high-level-virtualized abstract machines (like a JVM) — is obviously something that could have been used as "containerization" by those interested in doing so, even as far back as 1972's VM/370. And even those who weren't thinking in terms of "building a container", were still doing something very similar, in creating workloads as disk-image-based unikernels that assume full memory access, and which rely upon a single-tasking single-user exokernel library OS like DOS or CPM (but the z/VM equivalent, because they were writing programs that manipulated batch database records, not files, so regular DOS routines would be pretty useless.) Taking your "application disk" that you had developed to boot on your workstation, and uploading it byte-for-byte to your mainframe to be executed with 1000x concurrency over a batch workload, was exactly the sort of "shipping development to production" that we expect from containerization today.
- zer0tonin 3y ago
  I wasn't aware of that. Even more reasons to not call it a new thing then.

Containers have been around for 15 years. They are not "newfangled" anymore.

AnimalMuppet 3y ago

At the rate bank IT changes, maybe they kind of still are.

deleted 3y ago

[deleted]

pjmlp 3y ago

Containers in UNIX and mainframes predate Linux containers, thus a bit longer than that. The big difference is that we did not use them to ship the developer's computer into production.

derefr 3y ago

You're specifically talking about Docker/OCI containers; but "containers" have actually been around a lot longer than that — specifically on the sorts of mainframe systems that banks use. A workload on e.g. IBM z/VM is/was basically "a container" — in the sense that it was an application filesystem or binary, packaged up with a manifest that specified what environment the application expects to be run under; where it's the workload manager's responsibility to arrange a sandbox to run the application within that'll meet the application's needs. Of course, this was less about supplying an operating system to wrap around the container-image (ala Elastic Beanstalk), and more about supplying a particular flavor of emulated hardware for the workload to run "on bare metal" against. But applications of the day were bare metal — unikernels, if you want to call them that — and mainframe ISAs/memory-maps of the day were much like older-generation game console ISAs/memory-maps, in that the "bare metal" directly exposed advanced host services through CPU instructions and IO ports specific to the microarchitecture of the machine. The hardware "was" the OS, per se; and so emulating different hardware was in effect a virtualization of different operating systems. A good way to understand these mainframe ISAs, might be to picture a high-level and complex runtime-based compilation target like Macromedia Flash bytecode: sure, it's "an ISA", but each op can cause extremely complex things to happen at the runtime level. The "runtime" of a physical mainframe would originally be "in hardware" — consisting of "accelerator" boards triggered by the CPU. But in z/VM, the "runtimes" of each "hardware profile" a workload might ask to be run under, are just regular old runtimes. Like Flash. Or a JVM. Or a software x86 emulator, with hardware paravirtualization care of x86 "application processors" living on accelerator cards. To me, this abstraction — of a hypervisor that can support running workloads built for many different ISAs and microarchitectures, with these representing anything from low-level-emulated real machines (like x86) to high-level-virtualized real machines (like some specific mainframe) to high-level-virtualized abstract machines (like a JVM) — is obviously something that could have been used as "containerization" by those interested in doing so, even as far back as 1972's VM/370. And even those who weren't thinking in terms of "building a container", were still doing something very similar, in creating workloads as disk-image-based unikernels that assume full memory access, and which rely upon a single-tasking single-user exokernel library OS like DOS or CPM (but the z/VM equivalent, because they were writing programs that manipulated batch database records, not files, so regular DOS routines would be pretty useless.) Taking your "application disk" that you had developed to boot on your workstation, and uploading it byte-for-byte to your mainframe to be executed with 1000x concurrency over a batch workload, was exactly the sort of "shipping development to production" that we expect from containerization today.

zer0tonin 3y ago
I wasn't aware of that. Even more reasons to not call it a new thing then.