5 ms·

> Apprehension toward containers is a red flag. Unqualified statements like that are unqualified B.S. Not all environments gain anything from containers, and

by sgbeal 3y ago

> Apprehension toward containers is a red flag. Unqualified statements like that are unqualified B.S. Not all environments gain anything from containers, and if you have "ultra-stability" requirements like, e.g., those found in banks, avoiding newfangled containers for oldfangled methods which are known to work well and for which the organization has long-proven fallbacks is not only legitimate, but arguably preferred.

zer0tonin 3y ago
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.
night-rider 3y ago
Containers are also an abstraction, adding complexity, where bugs lurk. Maybe the 'Perl script someone wrote in the early 00s' has been revised multiple times to address security concerns, and if it's not broken, don't try and fix it by architecting large abstractions.
- briffle 3y ago
  Until you got to deploy it on a new, supported linux OS, and realize that CPAN modules that load are different that the old server, and the developers own workstation, and now things go to hell, but they worked great on the developers machine. (not just perl, python and others can be fun too). As an admin, not a dev, I appreciate the additional complexity and security concerns, but I much more appreciate the portability and reproducability.
  - kazinator 3y ago
    Portability and reproducibility means that the same code runs nicely in different envrionments. A container or VM with a specific version of an OS and packages is the exact opposite of portability.
brazzledazzle 3y ago
I don't know if it's a red flag but it's something that should be followed up on to determine if it's a sign of one. Just like there are situations where containers aren't appropriate there are situations where they most definitely are and a lack of nuance with reservations towards containers from a candidate would be a red flag for me.
_jal 3y ago
It reads like the advice of a mid-career engineer who is not aware that their time has been spent in a very small corner of the overall software engineering world.
kdwikzncba 3y ago
I thought the same about every item in the list. A more honest title would be "questions to ask to determine if you think like me"
bee_rider 3y ago
An affection for containers are a green flag in some sense. Management probably has really low expectations if they accept “works on my system, let’s just ship my system” at scale as a solution.
- scrps 3y ago
  Shipping containerized beta as production as a service, SCBaPaaS? You can promise fantastic turn-around, cut staff, and "crowdsource" testing! You offer a pretty dashboard and you are cooking with fire.
  - bee_rider 3y ago
    Shippable Containerized Actionalized Betas for Productive Ideation and Customer Creation. Our goal is to minimize the difference between your environment and that of your customers. When you think “converged external and internal environments” think SCABPICC.
    - scrps 3y ago
      Move to add 'and Retention' to the name so as to make the acronym SCABPICCR.
jcranmer 3y ago
I mean, if you read the entire statement, it's clear that it's not exactly an unqualified statement. If your view on containers is that you've evaluated them and found that they aren't useful for your organizational needs, then it's not a red flag... but it's also not "apprehension toward containers."
rattlesnakedave 3y ago
Getting a response like this to the question "What are the firm’s views on containers?" is the actual red flag.
puppetmaster 3y ago
Saying "apprehension towards containers is a red flag" is as subjective as the apprehension itself. I like to work with professionals that have a justified opinion, rather than knee jerk reactions. I am old, I've seen it all, sometimes I use containers. Are they useful? Sure! Are they "the final form"? No! Tools are just tools, don't get obsessed about them... They only matter when used properly to solve the right problem. Obsession about tooling generates so much waste... and burnout!
Ferret7446 3y ago
Containers don't inherently reduce stability (quite the opposite in most cases). If I'm being generous to the author, they probably meant "unfounded apprehension", such as assuming out of ignorance that containers are somehow less stable. Containers merely namespace/segment various OS resources.

by sgbeal 3y ago

zer0tonin 3y ago

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.

night-rider 3y ago

Containers are also an abstraction, adding complexity, where bugs lurk. Maybe the 'Perl script someone wrote in the early 00s' has been revised multiple times to address security concerns, and if it's not broken, don't try and fix it by architecting large abstractions.

briffle 3y ago
Until you got to deploy it on a new, supported linux OS, and realize that CPAN modules that load are different that the old server, and the developers own workstation, and now things go to hell, but they worked great on the developers machine. (not just perl, python and others can be fun too). As an admin, not a dev, I appreciate the additional complexity and security concerns, but I much more appreciate the portability and reproducability.
- kazinator 3y ago
  Portability and reproducibility means that the same code runs nicely in different envrionments. A container or VM with a specific version of an OS and packages is the exact opposite of portability.

brazzledazzle 3y ago

I don't know if it's a red flag but it's something that should be followed up on to determine if it's a sign of one. Just like there are situations where containers aren't appropriate there are situations where they most definitely are and a lack of nuance with reservations towards containers from a candidate would be a red flag for me.

_jal 3y ago

It reads like the advice of a mid-career engineer who is not aware that their time has been spent in a very small corner of the overall software engineering world.

kdwikzncba 3y ago

I thought the same about every item in the list. A more honest title would be "questions to ask to determine if you think like me"

bee_rider 3y ago

An affection for containers are a green flag in some sense. Management probably has really low expectations if they accept “works on my system, let’s just ship my system” at scale as a solution.

scrps 3y ago
Shipping containerized beta as production as a service, SCBaPaaS? You can promise fantastic turn-around, cut staff, and "crowdsource" testing! You offer a pretty dashboard and you are cooking with fire.
- bee_rider 3y ago
  Shippable Containerized Actionalized Betas for Productive Ideation and Customer Creation. Our goal is to minimize the difference between your environment and that of your customers. When you think “converged external and internal environments” think SCABPICC.
  - scrps 3y ago
    Move to add 'and Retention' to the name so as to make the acronym SCABPICCR.

jcranmer 3y ago

I mean, if you read the entire statement, it's clear that it's not exactly an unqualified statement. If your view on containers is that you've evaluated them and found that they aren't useful for your organizational needs, then it's not a red flag... but it's also not "apprehension toward containers."

rattlesnakedave 3y ago

Getting a response like this to the question "What are the firm’s views on containers?" is the actual red flag.

puppetmaster 3y ago

Saying "apprehension towards containers is a red flag" is as subjective as the apprehension itself. I like to work with professionals that have a justified opinion, rather than knee jerk reactions. I am old, I've seen it all, sometimes I use containers. Are they useful? Sure! Are they "the final form"? No! Tools are just tools, don't get obsessed about them... They only matter when used properly to solve the right problem. Obsession about tooling generates so much waste... and burnout!

Ferret7446 3y ago

Containers don't inherently reduce stability (quite the opposite in most cases). If I'm being generous to the author, they probably meant "unfounded apprehension", such as assuming out of ignorance that containers are somehow less stable. Containers merely namespace/segment various OS resources.