Quel est l'impact du PaaS sur l'APM ?

En théorie, étant donné que les applications PaaS peuvent être créées à l'aide de normes et d'outils communs, il devrait en être de même pour la création de capacités de surveillance de ces applications. Avec moins de personnalisation, la surveillance devrait être plus facile, n'est-ce pas ? Eh bien, si le contenu de l'article, « Étude : le marché PaaS atteint le sommet de 6,94 milliards de dollars d'ici 2018 », écrit par Chris Talbot dans Talkin' Cloud est vrai, les entreprises voudraient en fait évaluer de près si leurs outils APM réussiront dans un environnement PaaS. Voici pourquoi :

1. Les plates-formes PaaS ont tendance à se spécialiser dans un certain langage de programmation, donc si une solution APM ne surveille pas ce langage, elle ne peut aider personne à l'intérieur de cet environnement PaaS. Si le support n'est pas aussi bon que celui d'un concurrent là-bas, ils ne seront vraiment pas en mesure de rivaliser dans cet environnement, même s'ils font le travail d'intégration. Cependant, si une solution APM prend en charge ce langage, et le prend bien en charge, toute information ajoutée spécifique à cet environnement PaaS sera extrêmement utile.

2. Les plates-formes PaaS ont beaucoup d'abstractions et de couches cachées, il y a donc des zones dans ces environnements dans lesquelles une solution de surveillance ne sera pas en mesure de capturer des informations :

• Routage : Le système de routage d'Heroku est l'un de ces domaines, mais il est très important de surveiller ses performances, comme illustré dans l'article Apprivoiser la file d'attente.

• Configuration de la machine : Un autre domaine qu'une solution APM peut ne pas être en mesure de surveiller est la configuration de la synchronisation des fichiers, car elle ne peut pas obtenir un accès complet à la machine. Il peut avoir accès au langage de programmation qui s'exécute à l'intérieur, mais il n'a pas accès à tout ce qui se passe sur les serveurs.

• Extensions propriétaires : Un environnement PaaS peut avoir des composants propriétaires — des versions personnalisées du serveur et des extensions personnalisées d'une langue. Il existe un certain secret avec les fournisseurs de PaaS concernant leurs composants, car c'est ainsi qu'ils peuvent faire évoluer cet environnement sans se soucier des concurrents. Par conséquent, un fournisseur APM ne sera pas en mesure de surveiller ces composants à moins qu'il ne puisse fonctionner avec le fournisseur PaaS.

• Services multi-locataires : De nombreux environnements PaaS contiennent des services partagés, ce qui peut poser problème pour certains types d'outils de surveillance. Les instances de base de données multi-locataires sont assez courantes. Si l'agent de l'outil de surveillance a besoin de parler à la base de données pour en extraire des données et qu'elle est multi-locataire, l'outil peut ne pas avoir l'accès pour le faire. S'il n'a pas d'autre moyen d'obtenir ces informations de base de données dans cet environnement PaaS, il ne sera jamais en mesure de fournir des métriques de base de données.

• Services externes : Un environnement PaaS a également tendance à utiliser un certain nombre d'API externes, un autre domaine dans lequel un outil de surveillance pourrait manquer des données. Les développeurs choisissent PaaS parce que c'est pratique, et ils se tournent vers une API parce que les serveurs et le PaaS ont tendance à être plus petits et moins puissants - c'est un bon moyen de leur décharger le travail. Si une solution APM n'a pas la capacité de surveiller les API, ou si sa capacité n'est pas très forte, alors cela va être un point faible dans un environnement PaaS.

Le cas du suivi de votre PaaS

Il existe des arguments convaincants en faveur d'une surveillance interne si vous utilisez un PaaS. Chacun des services individuels sur le PaaS est construit et mis à l'échelle par la plate-forme, mais l'application elle-même n'est pas de leur responsabilité. Peu importe à quel point vous standardisez, il y aura toujours des problèmes de performances que vous devrez surveiller et vous avez besoin d'un outil pour le faire.

Les fournisseurs de PaaS ont également leur propre complexité, en interne. Ils auront plusieurs services :un système de compte et une interface graphique Web pour la facturation du PaaS, un autre système d'interface graphique Web pour gérer les modules complémentaires configurés et un service pour gérer la configuration sur les serveurs PaaS. Même si les serveurs sont en cours d'exécution, si les nouveaux paramètres de configuration ne peuvent pas leur être transmis, il y aura une dégradation du service. L'entreprise peut même utiliser un service pour accéder à ses données de performance. Il y a beaucoup de services dans l'écosystème PaaS qu'il est logique de surveiller, donc il y a le cas d'utilisation interne de garder tous les serveurs en fonctionnement mais aussi d'optimiser toutes les pièces d'infrastructure qui rendent le PaaS si facile à utiliser.

Nouvelle génération de PaaS

Pour l'avenir, la tendance est que les serveurs PaaS deviennent de plus en plus petits, mais vous devez surveiller tous ces serveurs. Si l'outil de surveillance de votre entreprise n'est pas conçu pour prendre en charge de nombreux petits environnements, il peut être moins rentable ou présenter des problèmes de mise à l'échelle. De plus, les serveurs individuels sont beaucoup plus éphémères qu'auparavant. Ils peuvent n'exister que pendant des heures ou même moins d'une heure au lieu de jours comme autrefois. Par conséquent, si votre outil de surveillance est orienté autour de l'idée d'un serveur existant depuis longtemps, vous ne pourrez peut-être pas très bien gérer un environnement où les serveurs disparaissent et réapparaissent sans que personne ne le dise jamais explicitement.

Quelle que soit la façon dont vous la découpez, chaque application évolue constamment, ce qui nécessite une planification minutieuse pour une mise à l'échelle efficace. Les fournisseurs de PaaS peuvent vous aider, mais cela ne signifie pas que la surveillance n'a pas sa place.