La création d'un stack technologique qui répond à vos besoins commerciaux est difficile. Lorsque deux entreprises fusionnent, la consolidation des stacks technologiques présente un très gros défi. En 2021, Dustin, un partenaire IT en ligne, a acquis Centralpoint. En tant que responsable du développement web chez Centralpoint, mon équipe avait pour tâche de consolider les stacks, chacun avec des architectures et outils différents.
La fusion de deux stacks technologiques : New Relic ou Datadog ?
Lors de la fusion de deux stacks technologiques, la sélection des outils à utiliser et des approches à suivre n'est pas une simple question de savoir quelle technologie remporte le premier prix. Les équipes ont souvent de fortes préférences et des expériences différentes que nous avons dû prendre en considération et mesurer au rapport coût/efficacité et à la scalabilité. Nous avons également dû tenir compte des facteurs culturels qui influençaient la prise de décision de chaque entreprise.
Avant l'acquisition, Centralpoint maintenait un stack cloud natif monitoré par New Relic. En 2019, l'entreprise était déjà passée du cloud privé au cloud public avec AWS (Amazon Web Services) et avait boosté le monitoring d'infrastructure et des logs. De son côté, Dustin maintenait un stack d'applications très modernes, mais l'infrastructure était basée sur une technologie de data centers sur site. L'entreprise hébergeait les données elle-même et comptait sur l'équipe d'infrastructure pour maintenir les clusters Kubernetes à jour. Le stack de Dustin était encore sur un cloud privé et leurs ingénieurs étaient déterminés à utiliser Datadog.
Nous avons dû trouver les technologies de chaque stack que nous pouvions combiner pour bénéficier de la meilleure solution à l'avenir. Finalement, nous avons décidé d'associer le stack d'applications de Dustin avec l'architecture d'infrastructure en tant que code de Centralpoint, ce qui ne laissait plus que la question de la meilleure solution d'observabilité à utiliser pour l'organisation recomposée.
La décision entre Datadog et New Relic a été réduite à une simple question de coût et de fonctionnalité. Chez Dustin, les développeurs utilisaient Datadog en tant qu'agrégateur de logs quasi enrichis pour analyser les logs. Chez Centralpoint, notre utilisation de New Relic était beaucoup plus approfondie. Nous utilisions New Relic pour le monitoring et les alertes depuis près de huit ans et nous avions élargi encore plus cette utilisation lorsque nous sommes passés du cloud privé à AWS. Au moment de l'acquisition de notre entreprise par Dustin, nous avions une pratique mature du monitoring des performances des applications (APM) et des logs.
Au bout du compte, nous avons décidé de transférer tout le nouveau stack technologique vers New Relic en raison des coûts et de la maturité. L'autre facteur important de notre décision était la proche relation que nous avions avec New Relic au niveau des ingénieurs, nous avions des rétroactions et des demandes de fonctionnalités en continu. Le démarrage avec New Relic était simple, la documentation est bien fournie et il y a une grande communauté qui soutient cette solution. Le plus gros défi était l'activation technique. Il fallait montrer les capacités disponibles aux développeurs et leur indiquer ce qu'ils pouvaient accomplir avec la plateforme. Une fois la décision prise, nous avons pu nous concentrer sur la phase suivante de notre évolution technologique.
Le moteur de la transition DevOps
Nous savions que le stack technologique post-acquisition aurait une architecture cloud public. Lorsque nous avons fait la transition, nous avons décidé d'adopter un modèle DevOps complètement interne et de nous éloigner du concept de l'infrastructure en tant que service. Pour que toute l'équipe assume les responsabilités nécessaires pour atteindre le niveau DevOps, nous avions besoin d'informations de plus grande qualité et en plus grand nombre qu'auparavant.
Une acquisition est une excellente occasion d'identifier les endroits où les ressources sont gaspillées ou mal utilisées. Nous nous sommes rendu compte que les deux entreprises étaient susceptibles d'inclure trop de données ou des données inutiles dans les logs et outils de monitoring. Cette accumulation est facile dans le temps, lorsque plusieurs collaborateurs se servent d'un outil. Une fois que vous évoluez, vous devez commencer à réfléchir aux données que vous voulez présenter et aux messages d'informations que vous voulez inclure dans votre environnement de production. La consolidation nous a aidés à déterminer les informations détaillées qui étaient importantes pour nous. Nous travaillons maintenant à l'optimisation de New Relic pour répondre à nos besoins en utilisant le volume de données correspondant à nos ressources.
Nous nous sommes engagés à utiliser New Relic pour l'APM, les navigateurs, les logs et l'infrastructure pour soutenir notre modèle DevOps. Le tracing distribué suit les demandes de service qui traversent toute l'organisation et cette visibilité est essentielle pour modeler nos nouvelles opérations rationalisées. La connexion à AWS et l'envoi des logs de là à New Relic était une étape évidente pour nous. En tant qu'équipe, notre objectif est de nous écarter d'une approche rétrospective de l'ingénierie et des réponses aux incidents et d'adopter plutôt une démarche proactive.
Intégration de la sécurité dans les applications avec la gestion des vulnérabilités
Nous utilisons plusieurs outils pour scruter les risques de sécurité dans nos applications. Un outil nous donnait des résultats au format PDF, que nous devions comparer avec les fichiers PDF de résultats précédents pour voir s'il y avait eu une augmentation ou une baisse. Ce n'était pas convivial du tout. Nous utilisons aussi l'analyse (scanning) des conteneurs dans Gitlab en tant que partie intégrante de nos pipelines pour le déploiement. Nous analysons les conteneurs que nous déployons. Ces conteneurs contiennent l'application, mais aussi la plupart des packages d'entreprise liés au noyau (kernel) que nous possédons.
Il n'est pas suffisant de savoir quelles sont les vulnérabilités qui se trouvent dans l'application, il faut aussi les résoudre en sachant ce qui doit être éliminé ou corriger. Nous voulons développer notre stratégie de monitoring de sécurité pour qu'elle inclut des éléments comme les alertes et les rapports afin que nos développeurs disposent de données qui leur permettent d'agir. Nous voulons que tout cela se trouve dans le même outil de monitoring afin que tout le monde ait les mêmes données de référence.
La gestion des vulnérabilités de New Relic fournit des informations détaillées sur la sécurité sans qu'aucune configuration ne soit nécessaire, ce qui est une énorme aubaine pour nous. La fatigue liée au trop-plein d'alertes est une autre raison pour laquelle nous voulons que la sécurité soit prise en compte dans un outil de monitoring, afin de nous assurer que lorsque nous recevons une alerte, elle est précise et précieuse.
La gestion des vulnérabilités nous aidera à intégrer la sécurité dès le début du cycle de développement afin que les équipes se chargent d'intégrer les soucis de sécurité dans leurs microsites. La gestion des vulnérabilités aide les développeurs à voir et à posséder l'état de sécurité de leurs applications, plutôt que de simplement le céder à l'équipe de sécurité. Lorsqu'une demande de fonctionnalité est satisfaite, nous obtenons le diagramme de dispersion réelle. Les développeurs peuvent observer les dashboards pour voir si des problèmes de sécurité sont signalés, en plus des packages mis à jour qui ont besoin d'être corrigés. Lors du nettoyage (grooming), tout le monde peut voir les données et les mesures à prendre.
Des DevOps aux DevSecOps
Lors de l'analyse d'un pipeline avec un scanneur de conteneur, vous obtenez généralement un écran noir avec du texte blanc. En permettant à New Relic Vulnerability Management de scanner votre application sans configuration supplémentaire, vous obtenez un aperçu convivial à envoyer en production ou à exécuter pour voir les résultats, mais ensuite vous devez faire quelque chose avec cette information. Vous avez aussi besoin d'un changement culturel. Auparavant, un membre de l'équipe de sécurité créait des tickets à partir des données. Nous voulions nous éloigner de cette méthode, travailler de manière plus agile et charger les équipes développant des applications de résoudre leurs propres problèmes. Cette méthode dépend de la maturité et de l'agilité de la façon de penser de l'équipe, et pas seulement des outils qu'elle utilise. Nous travaillons là-dessus actuellement.
Prochaines étapes
La création de dashboards personnalisés est l'une des prochaines étapes pour nos équipes. Le fait de montrer des informations ou des aspects importants est plus efficace que la simple fouille des logs. Les événements personnalisés de New Relic sont émis par nos applications et visualisés sur des dashboards en utilisant le langage NRQL, ce qui nous aide à vérifier et valider plus rapidement que jamais le flux de l'application. New Relic Groundskeeper nous aide à rester à jour avec les dépendances et les packages des applications.
L'aperçu Kubernetes est le moyen le plus efficace d'évaluer en un clin d'œil la santé du cluster et de nos déploiements.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.
