IMVHO yes, you donât. And itâs fine, as you told,
âit works = itâs good and i donât have to think about it.â And I canât debate that
On the other hand, the overhead is anyway present, IMVHO, and as one designed in first instance, mono-firm distro, wasting CPU, hard drive space, memory, processes for multiple instances for any application distributed.
For devops, thirdy party service provider, multi service companies is perfect. Containers are bit less cpu and ram wasteful than VM on bare metal (less memory used due to not stacking Hypervisor AND OS on top. As GDPR, containers can deliver authentication separation and the manager of the container system can remotely operate to the container without accessing data via the container management tools.
But for a company?
In my (twisted?) perception, on bare metal iâd go with type hypervisors, which allows me to have multiple distros, operating sistems and duplicated hosts in few steps. Going container into virtualized system stacks resources of Hypervisor, OS, and container, with related higher disk consumption and resourced used for manage the stack instead manage informations.
And going bare metal for big enough companies is call themselves for issues. A server class hardware can be guarded via manteinance contracts of good enough scheduled buys of quality and reliable hardware. When the metal is not enough, you change the box and after 4-6 hours top youâre ready to roll. Ok, maybe itâs a bit longer list of steps, but anyway when first guest is up, can be powered on if the design is good enough (and I totally go for virtual firewall if i can, against IpFire project suggestions).
Container? Host has to be raised, updated, installed the container management. Then restore the whole container lot requested for single applications, then restored the content of the container, untangle network paths and rules. Same 4-6 hours? Maybe itâs all due to ignornance, but still donât seem to be realistic. At least 2h for have the container lot arranged, then start the single container restore.
Again⊠context. Container context donât seem to fit the Small company goal than Nethesis during years suggested.
But I canât blame them.
First of all, containers are requested from market and being outside that approach is quite a âyou canât miss itâ.
Also, containers are a viable path for Nethesis to add features to the product without tinker it from scratch the distro underlying for any module. If the projects delivers a container recipe, this can be tested, tweaked, personalized via the configuration db approach, then deliver it. They go from source tinkering to recipe tinkering, crushing the load on mirrors for packages (that can be retrieved by mirrors of the single project and not from Neth) and delivering only the recipesâŠ
Any customer tomorrow can receive faster a new webapp, in few days, without having to ask themselves âAnd with this new toy, how will sing the other WHOLE LOT of packages to the flush?â
Untangling networks and firewall rules among containers is⊠IMVHO the biggest riddle.
