Crossplane VS Terraform

Dans l'article précédent, on a parlé de Crossplane et du fait qu'il est capable de créer des ressources dans le cloud. Est-ce que ça doit remplacer Terraform? Dans quels cas l'un est mieux que l'autre à utiliser?

Automatisation

L'énorme point fort de Crossplane est que c'est un service déployé sur un cluster Kubernetes, du coup il est toujours actif et surveillle en permanence ses ressources.

Par exemple, si vous modifiez les paramètres d'une ressource dans AWS qui a été créée par Crossplane, ce dernier va aller remettre les configurations qu'il a défini. Si jamais vous la supprimez, il va la recréer.

Le fait qu'il soit toujours conscient de ce qu'il se passe est grandement utile pour vous assurer de la présence de certaines ressources.

Mais le point fort est surtout si vous devez créer des ressources dynamiquement. Le cas évoqué à plusieurs reprises de gérer toute une stack avec Grafana et une BD pour chacun des clients est un excellent exemple. Vous pouvez créer votre opérateur qui va gérer ces ressources via Crossplane. Par conséquent vous pouvez créer une stack complète en ajoutant une seule ressource!

Excès d'automatisation

En effet le fait de créer tout ça est bien beau, mais il faut faire attention à ne pas rendre votre système complèxe pour rien!

Utiliser Crossplane vous oblige à avoir un cluster Kubernetes, donc si vous en n'avez pas, il faut quand même se demander si c'est réellement utile! Maintenir un cluster Kubernetes peut être long et compliqué, surtout quand on sait qu'on peut effectuer beaucoup de traitements similaire par Ansible.

De plus, si vous voulez créer juste une fois un type de ressource, c'est clairement overkill. Surtout que le projet est toujours en cours de développement, donc tout n'est pas encore disponible si vous voulez avoir une base de données avec haute disponibilité et un système de disaster recovery.

Configurations qui elles sont disponibles via Terraform.

Quand utiliser quoi?

Il est conseiller d'utiliser Terraform pour générer les ressources qui sont là pour rester un moment ou si vous n'avez pas de cluster Kubernetes.

Avoir un cluster Kubernetes dans le cloud coûte cher, par conséquent ne l'avoir que pour ça ne sera pas très optimal au niveau des coûts.

Pour Crossplane, il faut l'utiliser pour gérer les ressources temporaires ou celles qui doivent être dupliquées un nombre de fois indéterminé. (Si vous avez déjà un cluster Kubernetes)

Bien évidemment, dépendemment du contexte et du cas par cas, il peut être préférable d'utiliser une solution plutôt qu'une autre. Mais j'espère que cet article vous aidera à vous poser les bonnes questions et à y voir plus clair.

Conclusion

Jusqu'à présent dans cette série on aura fait le tour d'un grand nombre d'éléments, partant de la définition d'un opérateur pour arriver sur des cas d'utilisations plus complexes.

Comme vous avez pu le voir, les opérateurs Kubernetes sont un vaste sujet qui mérite d'être ne serait-ce que connu car il peut faciliter pas mal de choses.

J'espère que ça vous aidera et si jamais vous avez des questions, quelles qu'elles soient (Il n'y a jamais de questions bêtes!) ou des points qui ne sont pas clairs pour vous, n'hésitez pas à laisser un message dans les commentaires ou à me joindre directement sur LinkedIn (même pour parler d'autres sujets!).