En se basant sur son expérience d'administrateur système testant Docker, Matt Jaynes a écrit un billet sur le site de DevOps University à propos des principales fausses croyances sur Docker, levant un avertissement sur l'adoption de Docker à petite échelle et sans infrastructure solide, et propose des alternatives pour améliorer son processus de déploiement.
Benjamin Wootton, CTO de Contino, a déjà averti du surcoût important d'administration dans les architectures à base de micro-service dans cet article. En se basant sur son expérience d'administration de serveurs fournissant des applications web, Matt l'affirme également, ainsi que la nécessité d'être un expert en administration systèmes pour l'utiliser sereinement en production :
Actuellement, vous avez besoin d'une très bonne expertise système pour utiliser Docker. Pratiquement chaque article que vous allez lire sur Docker va vous présenter des cas simples et va ignorer la complexité d'utiliser Docker sur un système de production multi-plateforme. Cela vous donne une fausse impression sur ce qu'il en coûte d'utiliser Docker en production.
Si vous ne voulez pas apprendre comment administrer des serveurs, vous devez utiliser une Platform-as-a-Service (PaaS) comme Heroku. Docker n'est pas la solution.
Matt conseille de commencer avec des conteneurs par rôles (applications, base de données, caches ...) et seulement pour les rôles qui ont un sens, mais seulement si le projet à des solides fondations :
Si vous avez des trous dans votre infrastructure, vous ne devriez probablement pas utiliser Docker. Ça serait comme garer une Ferrari au bord d'un précipice instable.
D'autres améliorations peuvent être faites à la place d'adopter Docker en vue d'améliorer les performances et la cohérence de votre processus de déploiement :
Utiliser des outils de gestion de configuration (Ansible, Puppet, ...) pour facilement créer et gérer des serveurs, en particulier dans le cloud.
Créer des images pour le cloud au lieu de provisionner à partir de zéro afin de créer de nouveaux serveurs plus rapidement. Les images de base et les serveurs déjà en fonctionnement peuvent toujours être provisionnés avec des outils de gestion de configuration.
Geler les versions. Utiliser une version explicite d'un logiciel garantie qu'un logiciel ne change pas entre deux environnements ou à travers le temps.
Déployer les applications en utilisant git ou rsync afin que les serveurs puissent être mis à jour avec un minimum de téléchargement à effectuer, de manière similaire à Docker et ses différentes couches.
Déployer les applications en utilisant des packages si le temps de compilation ou de préparation de l'application est trop long. Utiliser un package préconstruit comme un zip, un rpm ou un deb va accélérer le déploiement sur les serveurs.
Pour une production multiplateforme, Matt recommande d'utiliser ces différentes méthodes d'optimisation aussi longtemps que possible, jusqu'à ce que les bénéfices additionnels apportés par Docker soient nécessaires. Actuellement, des besoins à grandes échelles sont nécessaires pour que les avantages de Docker surpasse sa complexité. Cependant, à la vitesse à laquelle évolue le projet, cela pourra rapidement ne plus être le cas.