Why containers

Editor's Notes

• #6: Docker effectively has defined a the de-facto standard of the artefact & runtime of an application
• #13: We have the code in a source control repo –if we are lucky (in 80% of the cases it’s in a CACHE.DAT and we have the issue of creating the project that identifies the new app feature or just apply the ”move it all” approach) One we have identified the code for the new release how do we make sure it gets integrated for the new version? 1 single XML file output? Wat if I have some pseudo-static data that I need to import AND we said we’ll try to separate Code & Data? Then I would need a second file… maybe just a data.gbl file to be imported. If we have the above scenario I should then develop a script that handles the installation. Would bash be sufficient or do I need to develop one in PowerShell because we have MS-Windows based customers? We use ECP and I’d like some particular settings in my CPF file... etc. An alternative would be to ship our code in a CACHE.DAT. Obvioulsy we’d have to syncrnonize with the installed DB version, the configuration params, the system dependencies, etc. As we can apprecaite we do NOT have a BUILD phase in a scenario like the above. Q: What does our QA department do then? It appears that firstly it tests the assembly of components, THEN the actuall functional aspects of the application. In general it appears to be the best suited team to deliver the marching ORDERS on how to run a successful installation. The list is long and the dependencies many. Although it’s true that we could build a VMware image, the format is not portable, driven by a standard nor free. The other point is that with all those “Marching Orders”, No developer in his or her right mind would go through that Specialistic sys-admin process to have it setup on his or her workstation. They could however have the Vmware image but it comes at a license cost, size cost, time cost and resources cost (a VM machine is much heavier on a laptop/workstation in resources than a container where I could have more than a dozen without any problem) We could argue that Cm (confuguration Management) tools can help us. Indeed, born at the end of the 1° decade of year 2000, they can help. However, they do not help us in separating and distinguishing between the BUILD phase and the RUN phase of an app. On the contrary, they run the same process; they incur in system drifet as we move between environemnts AND over time and we cannot guarantee that the whole solution we are running is exactly the same. On the other hand if I build my image in my CI/CD process, then I have an artefact (container if you prefer) that is portable, can run on any cloud and is guranteed to work because all dependencies were satisdied at BUILD time. IOW we do NOT build our solution on the Production environment. We build it where we have time to fine-tune our build process, verify our dependencies etc. Once it’d built, the whole organization can quickly use it + test it etc. Once it is promoted for Production use, the solution has been well tested but –more to the point, we all know EXACTLY what is contains. There cannot be system drifts by definition. It’s a reproduceable EXACT process. There are no CMs tools or humans involved. That guarantee (together with many other aspects fo it like its lightness, a standard API that is ubiquotous) is what makes people look at it (and use it) with much interest.
• #16: Bottom line, using containers allows us to satisfy all dependencies needed by our service or application within that package. No more shell scripts, Ansible YML definitions, Chef’s recipes or my best system administrator to save the day in production. No, now we know exactly WHAT is running (software packages, libraries, versions…) & HOW it is configured Containers have been replacing CM (configuration management tools steadily). From the slide and from what we are saying it should be clear that there are at least 2 important phases in provisioning software: (a) BUILD and (b) RUN phase and this allow our customer to look at IaC (infrastructure as code) and immutable infrastructure with all their merits.