Jól látszik ezeken az ábrákon, hogy ha a függőség-kezelés tisztességesen meg volna csinálva, akkor az egész konténerizálás felesleges volna.
Nem a függőség kezelés a container deployment lényege, ha pont ugyanaz a függősége mindegyik deployment-nek, akkor is lényeges a container abban, hogy egymástól teljesen függetlenné teszi az alkalmazásokat jelentős overhead nélkül, mintha külön VM-ben futnának egyenként, korlátozott erőforrásokkal. De például lehetővé válik az is, hogy egyesével frissítsd őket, anélkül, hogy egy nagy élesítésbe kelljen összevárnod az összes alkalmazást, amíg mindegyik függősége ugyanaz nem lesz. Arra is könnyen lehetőséget ad, hogy A/B tesztként vagy canary release formájában ugyanabból az alkalmazásból kipróbálj egy újabb vagy frissített függőségű alkalmazást is, olyan kockázat nélkül, hogy egy komplett rendszert kelljen visszaállítanod, ha hiba derül ki. Amíg nem érted meg a container deployment jelentőségét, addig azt fogod gondolni, hogy faszság. Ha megérted, akkor viszont rá fogsz jönni, hogy mennyi előnye van a korábbi megoldásokhoz képest.
Ez egy nagyon komplex és nagyon drága workaround arra a problémára, hogy egy program egzaktul meg tudja mondani, hogy ő milyen könyvtárakat használva szeretne futni, illetve hogy ezek a könyvtárak egymás mellett tudjanak élni anélkül, hogy az egyik frissítése bolygatná a másikat.
Tulajdonképpen feltaláltad a konténert, mert ezzel egy program egzaktul meg tudja mondani, hogy ő milyen könyvtárakat használva szeretne futni és ezek egymás mellett tudjanak élni anélkül, hogy az egyik frissítése bolygatná a másikat.