BLOG

Le contexte est roi

Miniature de Lori MacVittie
Lori MacVittie
Publié le 07 février 2016

Objets de consommation. Choses d'affaires. Fabriquer des choses.

Téléphones. Comprimés. Phablettes. Ordinateurs portables. Ordinateurs de bureau.

Calculer intensément. Réseau intense. Stockage intense.

Maison. Travail. Restaurant. Voiture. Parc. Hôtel.

Le paysage évolue des deux côtés de l’entreprise : du côté des applications et des clients. Le terme « utilisateur » ne désigne plus seulement un être humain. Il comprend également des systèmes et des éléments qui sont pilotés automatiquement pour se connecter, partager et interagir avec des applications dans l'ensemble du centre de données.

 

Considérez, par exemple, la tendance émergente en matière d’architecture de microservices, qui divise les applications monolithiques en parties composites. Chaque partie est son propre service et présente une API (interface) à travers laquelle d’autres parties (services) et « utilisateurs » peuvent communiquer.

 

Vous ne faites pas partie des 36 % qui s’intéressent aux microservices ? ( Typesafe, 2015 ) S'en tenir à des architectures d'applications bien connues ne vous protégera pas de l'impact de la diversité croissante des « utilisateurs », surtout si vous vous lancez dans l'Internet des objets. Nos données indiquent que certains d'entre vous le sont, avec 22 % de tous les répondants pensant que cela sera d'une importance stratégique pour les 2 à 5 prochaines années et 15 % ayant une longueur d'avance avec des projets d'achat de technologie pour soutenir l'IoT dans les 12 prochains mois.

Cela signifie que les « objets » devront être considérés comme des « utilisateurs », ayant leur propre ensemble unique de besoins et d’exigences en matière de sécurité et de performances, sans parler de la disponibilité. 

Cela signifie que les services réseau et applicatifs chargés de fournir un ensemble d’applications de plus en plus diversifié à un nombre croissant de clients dans un nombre toujours plus grand d’endroits doivent être capables de faire la différence entre un utilisateur humain et un utilisateur d’objet. Pour optimiser les performances et garantir la sécurité, il est impératif que les services responsables des performances et de la sécurité soient en mesure d'appliquer la bonne politique au bon moment, compte tenu de l'ensemble de variables actuel.

Cela signifie qu'ils doivent gérer le trafic (données et communications, en termes d'application) dans le contexte de la transaction dans son ensemble : l'utilisateur, l'application et le but pour lequel une telle communication est tentée.

 

Vous pouvez penser au contexte de la même manière qu’on vous a peut-être appris (si vous êtes assez vieux, et non, vous n’êtes pas obligé de l’admettre si vous préférez ne pas le faire) les cinq « W » que vous devez demander lorsque vous recueillez des informations de base : qui, quoi, où, quand et pourquoi. En interrogeant le trafic et en extrayant une réponse à chacune de ces questions, vous pouvez rassembler suffisamment de contexte pour pouvoir prendre une décision appropriée sur la manière de traiter l'échange. Nie-le. Permettez-le. Scannez-le. Frottez-le. Optimisez-le. Acheminez-le. C’est le type de choses que les services d’application font « dans le réseau » et ils le font mieux et avec plus d’efficacité s’ils le font dans le contexte de l’échange.

  • OMS
    Identifie l'utilisateur. Est-ce un être humain ? Si oui, entreprise ou consommateur ? Est-ce une chose ou une autre application ? Si oui, quelle chose et quelle application ? Même si mon ampoule intelligente a accès à une application de reporting de données, elle n’a pas accès aux systèmes de comptabilité.
  • Quoi
    Que font-ils ? Envoi de données ? Vous demandez des données ? Recherche? HTTP contient une multitude de données qui peuvent aider à déterminer cela sans creuser très profondément. S'agit-il d'un HTTP POST ou d'un GET ? Une MISE À JOUR ou une SUPPRESSION ? Le statut seul peut nous donner des indices sur le but de cet échange.

  • D'où le font-ils ? Sont-ils à la maison ? Au siège ? De l'autre côté de la rue, chez Starbucks, ou à l'autre bout du monde ? Sur un réseau local ou sur Internet ? La géolocalisation est un moyen populaire de restreindre l'accès aux applications, aux ressources et aux données. Lors de la fourniture d'applications aux utilisateurs, quel que soit leur type, l'emplacement est important, en particulier s'il existe des politiques d'entreprise interdisant l'accès à certains types de données ou d'applications à partir de lieux publics comme l'aéroport ou le Starbucks local.
  • Quand
    Quelle heure est-il de la journée ? Et plus important encore, quelle heure de la journée est-il ici ainsi que où se trouve l'utilisateur ? Essayent-ils d'accéder à un système à 3 heures du matin depuis un endroit où il est 8 heures du matin ? Par exemple, nous savons grâce à des recherches que le trafic de robots augmente considérablement après les heures de bureau, entre 18 heures et 21 heures. Et nous pourrions mettre ces données en relation avec « qui » et être en mesure de déterminer instantanément qu’Alice devrait travailler à 3 heures du matin lorsqu’elle travaille au siège social.
  • Pourquoi
    Pourquoi est-ce que c'est comme la couche 8 inexistante ? On ne peut le déduire que de quoi, et cela nécessite que vous soyez capable de rassembler des indices à partir de données qui sont par ailleurs assez basiques, comme l'URI (en supposant qu'il soit basé sur HTTP, ce qui, de nos jours, est une hypothèse raisonnable). Une fois que nous savons ce qu’ils font, comme envoyer des données, nous voudrons peut-être savoir pourquoi ils les envoient. S'agit-il d'une mise à jour de profil ou envoient-ils des données de capteur ? Est-ce qu’ils font une recherche ou passent une commande ?

C'est ce qui constitue le contexte. Il n’est pas forcément nécessaire de collecter les cinq (ce n’est pas un Pokémon, après tout) pour pouvoir prendre une décision concernant la marche à suivre. Mais vous devez avoir une visibilité (accès) sur les cinq, au cas où vous le feriez. C'est pourquoi la visibilité sur l'ensemble de la pile réseau, des couches 2 à 7, est si importante pour les services d'application. Parce que chacun peut avoir besoin d'évaluer une demande ou une réponse dans le contexte dans lequel elle a été formulée, et ce n'est qu'en ayant une visibilité sur l'ensemble de la pile que vous pouvez accéder et récupérer ces informations lorsqu'elles sont nécessaires.

C’est l’un des avantages d’un proxy intelligent : la visibilité nécessaire pour garantir que les architectes (et les ingénieurs) du réseau, de la sécurité et de l’infrastructure peuvent mettre en œuvre des politiques qui nécessitent un contexte pour garantir la sécurité, la vitesse et la fiabilité dont chaque utilisateur, qu’il s’agisse d’un humain, d’un capteur ou d’un logiciel, a ultimement besoin.