Dois-je exécuter Sitecore sur Kubernetes ou App Services ?

Pendant un certain temps, il a semblé que Kubernetes et les conteneurs étaient l'avenir de Sitecore Infrastructure. À un moment donné, il était largement admis que Sitecore déconseillerait la prise en charge des App Services. La pensée actuelle est que les services d'application seront pris en charge par Sitecore dans le futur, donc une question courante lors de la création ou de la mise à niveau d'un environnement Sitecore est de savoir s'il faut choisir Kubernetes ou App Services. Je pense que la réponse à la question dépend en grande partie de vous. Voici quelques questions à prendre en compte lors de l'évaluation de votre future architecture d'infrastructure.

Prévoyez-vous XP ou XM ?

Les exigences d'infrastructure pour Sitecore XP et xDB sont beaucoup plus complexes que les exigences pour XM. XP requiert des rôles pour la diffusion de contenu, la gestion de contenu, l'identité, le traitement, la création de rapports, la recherche, la collecte, les données de référence, l'automatisation du marketing et les rapports d'automatisation du marketing. Sitecore XM nécessite uniquement la livraison de contenu, la gestion de contenu et l'identité. Et si vous envisagez davantage d'architectures sans tête qui déchargent la diffusion de contenu sur des CDN (comme Experience Edge), vous n'aurez peut-être même pas besoin du rôle de diffusion de contenu.

Là où Kubernetes brille vraiment, c'est dans la gestion du déploiement et des dépendances entre les rôles. Avec Sitecore XP, la proposition de valeur est très élevée. Il existe une tonne de services, et la gestion de la façon dont ils sont déployés ensemble offre des avantages tangibles. Avec Sitecore XM, la gestion de la configuration de l'environnement n'est tout simplement pas aussi complexe. Il y a toujours un avantage, mais il est moins convaincant.

Êtes-vous attaché à Azure ?

Comme vous vous en doutez, Azure App Services n'est disponible que si vous hébergez sur Azure. Kubernetes offre une meilleure prise en charge multiplateforme. Azure a sa propre implémentation de Kubernetes, mais vous pouvez exécuter Sitecore sur des conteneurs sur n'importe quel cloud prenant en charge les conteneurs Windows. Ce courant comprend à la foisAWSetGKE.

Cela étant dit, Sitecore entretient toujours une relation très étroite avec Microsoft et Azure, et la plupart des clients cibleront Azure Kubernetes Services, de sorte qu'une grande partie de la documentation et de l'assistance est adaptée à Azure. Malgré cela, l'adoption de Kubernetes vous donnera une certaine confiance dans le fait que vous pourrez passer à un autre fournisseur si nécessaire. L'adoption dans l'écosystème autour de Kubernetes avec des outils agnostiques cloud pour la gestion CI/CD (helm, Kudo), la journalisation et la surveillance (Prometheus) limite les dépendances directes sur les services Azure, bien que vous puissiez généralement les configurer pour tirer parti d'outils Azure comme App Insights pour fournir des informations supplémentaires. avantages.

Mais si vous n'êtes pas préoccupé par le besoin de passer à un autre fournisseur de cloud, l'utilisation des services d'application Azure peut très bien répondre à vos besoins.

Avez-vous d'autres applications qui peuvent ou vont s'exécuter dans des conteneurs ?

L'exécution de SOLR sur Kubernetes peut être une passerelle vers l'adoption de Kubernetes. SOLR en général est difficile à gérer et exécuter un cluster SOLR avec Zookeeper sur des machines virtuelles n'est pas amusant si vous ne savez pas ce que vous faites. Kubernetes facilite un peu les choses avec leOpérateur SOLR et des graphiques Helm qui en font une affaire davantage axée sur la configuration. Je recommanderais toujours des solutions commeRecherche Staxsi vous ne disposez pas de l'expertise interne pour gérer un environnement SOLR, sans parler d'un cluster Kubernetes.

Mais il y a de fortes chances que SOLR ne soit pas la seule dépendance de votre solution Sitecore. Les architectures de microservices ont gagné en popularité ces dernières années et Kubernetes est devenu le moyen privilégié de les déployer et de les gérer. Si votre solution dépend fortement des services, alors avoir une approche de déploiement et de configuration cohérente pour votre solution et vos services apporte de nombreux avantages.

Avez-vous une expertise dans la gestion des environnements Kubernetes ?

Si vous n'utilisez pas Kubernetes en production, vous devez être prêt à faire en sorte que votre équipe d'ingénieurs accélère ce qu'il faut pour prendre en charge une implémentation de Kubernetes. Même avec Azure, où AKS fournit des intégrations spécifiques à Kubernetes pour des éléments tels que Application Insights et Web Application Firewall, ils ont tendance à fonctionner dans un contexte Kubernetes, vous devez donc vraiment comprendre comment ils s'intègrent dans votre pile.

Pour être prêt à gérer un environnement Kubernetes en production, assurez-vous que votre équipe comprend parfaitement :

• Déploiements – Alors que les services d'application prenaient en charge les emplacements pour réaliser un déploiement bleu-vert, Kubernetes est beaucoup plus robuste et prend en charge les tests bleu-vert, canari, en rampe et même AB.
• Options de mise en réseau, de sécurité et d'entrée – Kubernetes permet de masquer facilement votre application du reste de l'environnement. Exposer les bonnes pièces, travailler avec les contrôleurs d'entrée, Key Vault, Web Application Gateway et Front Door vous offre une grande flexibilité mais une courbe d'apprentissage décente.
• Journalisation et surveillance – Les outils natifs de Kubernetes tels que Grafana et Prometheus fournissent une journalisation, des visualisations et une surveillance centralisées. Azure fournit des crochets pour les connecter à Log Analytics et Application Insights. S'assurer que vous comprenez vos options et configurez les choses correctement est essentiel pour pouvoir gérer les environnements.
• Reprise après sinistre – Assurez-vous de bien comprendre le fonctionnement d'un basculement en cas de sinistre. La façon dont vous concevez les architectures DR chaud chaud, chaud chaud et chaud froid aura ses propres nuances (et implications en termes de coûts) lors de l'utilisation de Kubernetes par rapport à App Services.

Vos développeurs sont-ils prêts à adopter les conteneurs ?

La courbe d'apprentissage de Kubernetes est probablement le plus grand obstacle à l'adoption. C'est comme apprendre un tout nouveau langage : Docker, Compose, KubeCtl, Kudo, Prometheus, Grafana, Operators, Helm, Charts, ne sont que quelques-unes des nouvelles terminologies dont vous aurez besoin pour maîtriser.

Il y a de nombreux avantages à dépasser cette courbe d'apprentissage, notamment :

• Configurations d'environnement local plus rapides – avec des conteneurs, la mise en place et l'exécution de votre solution et de votre environnement ne nécessitent généralement que l'exécution de quelques scripts.
• Vous pouvez exécuter plusieurs projets plus facilement – Si vous avez besoin de prendre en charge plusieurs instances et solutions Sitecore, le fait de pouvoir exécuter une solution, de l'arrêter puis d'en exécuter une autre facilite la tâche.
• Répliquer les environnements supérieurs – Si vos environnements supérieurs utilisent des conteneurs, vous pouvez exécuter ces images localement pour déboguer et dépanner plus rapidement.
• Capacité à composer des fonctionnalités supplémentaires – Au lieu de procéder à l'ingénierie inverse des packages Sitecore et de déterminer comment les déployer correctement, vous pouvez simplement utiliser des versions en plusieurs étapes pour extraire les artefacts nécessaires lors de la création d'une image. De nombreux modules open source offrent cette option, et vous pouvez utiliser cette stratégie pour améliorer la réutilisation.

Pour ces seules raisons, vous voudrez peut-être envisager une configuration d'environnement local et même utiliser Kubernetes pour exécuter des conteneurs dans Dev ou QA. Cela pourrait vous donner un moyen de vous familiariser avec les conteneurs et Kubernetes avant d'aller plus loin en essayant de l'exécuter en production.

Besoin d'aide pour décider ?

Chez Perficient, nous avons affiné notre approche pour aider nos clients à prendre cette décision. Avec des ateliers de découverte pour comprendre vos besoins et des ateliers d'architecture pour affiner l'architecture cible, nous pouvons nous assurer que vous prenez la bonne décision et comprendre les implications en aval, y compris les différenciateurs de coûts pour l'hébergement et la maintenance.

Si c'est une voie que vous envisagez d'emprunter, nous serions ravis de vous aider. Contactez-moi surLinkedIn,Twitterou remplissez notreformulaire de contact.

A propos de l'auteurDirecteur de la mission–>

David est directeur de l'engagement chez Perficient, David estime, conçoit et fournit des solutions de marketing numérique à grande échelle sur la plate-forme Sitecore. MVP 3X Sitecore Technology, David a écrit des articles pour MSDN Magazine et le Microsoft Architecture Journal. Il a pris la parole lors du Symposium Sitecore, du Sitecore Virtual Developer Day, de réunions de groupes d'utilisateurs et de camps de code.

Plus de cet auteur