Nie ulega jednak wątpliwości, że kontenery to przyszłość, której nie unikniemy. Pozwalają nam zajmować się tylko tym, co potrzebujemy, a nie całym systemem. To tańsze (organizacyjne). By skorzystać z przyspieszających zalet kontenerów, należy zadbać o ich poprawne sprzężenie ze środowiskiem ciągłego dostarczania. Tajniki optymalizacji wdrożeń przedstawia Vladimir Mitiouchev.
Kontenery mają jednak pewną zaskakującą cechę poboczną. O ile stosowanie maszyn wirtualnych z kompletnym systemem prowadziło często do zwiększenia bezpieczeństwa, ekspresowe przepisy na kontener oraz polityka niszczenia ich i zastępowania zaktualizowaną kopią prowadzą czasem do zaniedbań, właśnie w bezpieczeństwie. Należy tu przestać uważać (nierzadko nieświadomie), że izolacja dostarcza je „za gratis”. W opinii wielu, Docker to metoda bezkarne uruchamianie niezaufanego kodu jako root. To myślenie na skróty jest często proszeniem się o kłopoty. Jest to lekcja podobna do tej, którą muszą odrobić użytkownicy instalatora npm.
Jest też coś dla fanów systemd (takowi istnieją, jestem jednym z nich!): semi-konteneryzacja z wykorzystaniem systemd-nspawn. Nie zawsze koniecznie jest stosowanie całego stosu Dockera, zwłaszcza że rozwiązania pokrywające funkcjonalnie pewne jego obszary istnieją od dawna. Rzecz jasna trudno porównywać uniksowy chroot lub solarisowy jail z tym, co oferuje Docker, lecz być może dla pewnych konkretnych zastosowań, mniej wymagająca postać izolacji jest wystarczająca. Niestety, w przeciwieństwie do Dockera, co słusznie zauważył Maciej Lasyk, jest rozwiązaniem dedykowanym czysto pod Linuksy. O systemd-nspawn wkrótce napiszemy.
