Rancher pour réduire les coûts d'orchestration de vos environnements Kubernetes
David Raimboux
Secure, deliver and optimize every app and API for Insurance, Industrial, Automotive, Aeronautics & Media Companies
Le choix d'une solution d'orchestration de containers engage une entreprise à long terme, avec la nécessité de se projeter et de se protéger financièrement. Entre la modernisation d'applications, la fourniture de micro-services et le développement d'applications dites "cloud-native", la production de cluster Kubernetes va croître à un rythme très soutenu.
Plusieurs philosophies s'affrontent sur ce marché :
Node ou CPU, quelle différence ? Le budget !
Exemple ici avec un cas pratique constaté récemment par un client SUSE RANCHER.
Pour une centaines de nodes déployés, cette entreprise a estimé le nombre de CPUs à 768 coeurs (l'équivalent de 4 serveurs pour démarrer une production, et une vingtaine de serveurs pour les premiers déploiements, soit une moyenne arrondie à 8 CPUs par node).
Il en résulte un écart budgétaire allant pratiquement du simple au double, en considérant notamment des remises commerciales de 50% sur les solutions concurrentes, à comparer aux prix moyens constatés sur la partie Rancher.
Réduire le prix au node pour réduire le coût des déploiements applicatifs
Statistiquement, plus le nombre de clusters et de nodes augmentent, plus le nombre de CPUs par cluster et par node augmentent. Nous avons ainsi constaté qu'à partir d'une production Kubernetes supérieure à 100 nodes, la taille moyenne d'un node oscille entre 8 et 10 CPUs, avec de fortes disparités selon les applications déployées. Chacun peut faire l'exercice au niveau de sa production informatique.
Déployer des applications consiste à déployer des nodes. Une fois déployées, il n'y a plus de nodes à ajouter, ou bien à la marge. Le prix du node appliqué par Rancher baisse drastiquement au fur et à mesure de la montée en production des clusters Kubernetes.
Recommandé par LinkedIn
Estimer une production à 3 ou 5 ans pour comprendre l'enjeu budgétaire
Lorsqu'une entreprise adopte Kubernetes, nous constatons généralement une multiplication par 10 ou par 15 du nombre de nodes déployés en l'espace de 2 ans, durée moyenne d'une première montée en charge, le nombre de CPUs consommés suivant aussi cette tendance.
Déployer des applications consiste aussi à consommer un premier niveau de CPUs. Ensuite, le taux d'usage d'une application étant par exemple un indicateur de son succès, plus l'usage augmente, plus la consommation CPU augmente.
Il devient dès lors difficile d'anticiper des budgets, et d'éviter des échanges "chaleureux" lors du renouvellement de ce genre de contrats, autant avec les équipes internes qu'avec les éditeurs. Un tarif avantageux offert la première année du projet ne traduit pas le budget final supporté durant le voyage amenant votre équipe à la fin de la montée en charge de de votre infrastructure Kubernetes.
Un exemple ici avec un questionnement sur la façon d'affecter en interne les budgets de déploiement aux différentes entités concernées :
L'augmentation de la consommation CPU n'a aucune incidence sur le budget alloué au support de Rancher.
Evaluer les coûts collatéraux, rarement anodins
Certains autres aspects, à priori collatéraux, peuvent s'avérer très impactants, à évaluer financièrement dans le cadre d'un TCO. En voici une liste non exhaustive, souvent applicable à d'autres types de projets :
Chaque situation étant différente d'une entreprise à une autre, et les réponses standardisées n'existant pas, nous vous proposons d'appliquer cet exercice "au node" à votre cas d'usage.
Nous sommes à votre disposition pour vous accompagner dans cette comparaison.